I like watching YouTube videos to learn things. I am looking up Microservices, trying to figure out if this is good fit for a friend who asked me what are my thoughts about it, see if it’s going to help him and his team. Okay, let’s see what Youtube got about this.
I searched for videos on Microservices and found this one by Martin Fowler:
First, I’ll write down his talking points. Then, my thoughts….
In monolithic apps, every feature is in a single process. In microservices, every single capability get its own process.
When we deploy the monolithic apps, we have to deploy it to all servers. When we deploy microservices, we have some flexibility on how we deploy the updates.
Fowler wants a proper definition for microservices. You can’t come up with a standard definition, because there is no such governing body to come up with that. So, instead, Fowler brings up common characteristics of microservices:
- Componentization via Services
- For a long time in the industry, we’ve always talk about components. You can replace components independently. Corollary for this is that we can upgrade components independently
- We can bring in libraries, we can bring that into our software
- Services are very similar, but instead of making in-process calls, we make RPC-style calls
- Organization around Business Capabilities
- In many organizations, people organize around technology – like UI, DB, Web.
- Instead, you want “pizza-sized teams” owning complete business areas. Examples: Orders, Shipping, Catalog
- Each of these pizza teams have direct communication to the customers (and this is often missed). This is a must
- In many ways, microservices is an organizational attitude in as much as it is technological attitude
- It’s as much a team organizational thing as it is a software architectural thing because software architecture and organizations are always heavily coupled together. Per Fowler, anybody who denies that is leading themselves into trouble. If there’s one universal law in software development/software architecture, Fowler says, isConway’s Law.If you try to break it, it will bite you back much harder than you can try, and force it so focus around business capabilities
- Products not projects
- Traditional application development typically starts with the initially design, development, and implementation of the software, which is then handed over to an “operations team”
- Microservices advocates promote the idea that the team should own a product over its full lifetime. This is the Amazon’s way of “You build it, you run it”
- Smart endpoints and dumb pipes
- Traditionally, Enterprise Service Bus (ESB) is used to orchestrate different services
- ESBs typically have transformations, business logics — “smarts”
- For microservices, use “dumb pipes”. Use them for message routing only, to get data from one point to another.
- Keep the logic (the “smarts”) within the microservices
- In microservices, there is no room for complex middleware
- Decentralized Governance
- Each product team responsible for technology stack
- Decentralized Data Management
- Monolithic applications, typically one database (worse, one database for multiple monoliths)
- In microservices, each service gets its own data storage and it does not share its data directly with anybody else
- All data sharing has to happen around the services that wrap around the data
- Team also decides what kind of database to use
- You don’t have a central group laying out standards and deciding how things should be done
- Infrastructure Automation
- Continuous delivery
- Blue/green deployment(deploy without any downtime)
- Design for failure
- Microservices are going to break, frequently
- Netflix has a “Chaos Monkey”, takes down services during daytime, force the breakage to occur, and make sure the ops team is monitoring it, and that they can deal with it
Finally, Fowler talks about the “micro bit” about microservices, implying size. “Size is not an important part in microservices”, many say, but microbeing part of it, it implies it, doesn’t it?
How big should microservices be? Big range:
- 15 people, 10 services
- 4 people, 200 services
- It’s not clear yet how it maps out (video is 3 years old perhaps it’s more clear now what the “correct size” for a microservice should be)
When should you use Monolith and when should you use Microservice?
If you’re not sure, when you’re not sure to use microservice, stick with a monolith.
| Monolith | Microservices | |
| Complexity | Simple. Monoliths allow you much more easily to change the shape of the code because if you need to refactor and move some behavior from over here to over here, and you’re within the same code base, it’s easy to do | More complicated.Often, in order to get performance good on a microservice system you’ve got to use asynchronous messaging. Asynchrony is a huge complexity booster. Whenever you want to play the distribution card or the asynchrony card, you know you’re increasing the complexity of what you’re doing |
| Deployments | Deploy/redeploy entire thing. Yes, deploy the entire monolith, but organizations can successfully do deployments of even very large monoliths so it doesn’t force them to go microservices | Allows partial deployments. That that was a driver for Netflix. They had difficulty deploying new versions of their software. That was one of the things that pushed them towards a micro service approach |
| Availability | If something breaks, the entire thing is broken | Better degree of availability if failures are managed |
Fowler points out that many of the examples of successful microservices that he’s come across started with a monolith and then went microservices when they ran into trouble.
My thoughts
Whenever there is something new, fashionable approach to adopt, I first ask myself, what problem am I trying to solve? And then follow it up with, is this new shiny thing going to help me what I’m trying to solve?
Pass the first question, I then proceed to my second question. If question 2 passes as well, then and only then would I consider the approach.
It has to pass the first question because if it does not pass my first question, there is no motivation for whatever this thing is.
Now, to answer question 2, I typically have to ponder and think deep, and analyze whether the approach is sound or compatible with the problem at hand.
Anything that increases complexity, without value-add, is a disqualifier. I don’t like recommending (and never have in my 20+ years in the industry) complex solutions that require only the truly most advanced and experienced developers to maintain. If an approach gets it more complicated and leave the ops team dazed confused, pass on it – if you have a simpler option.
I say “complexity may disqualify a candidate approach”, because there can be instances where your best option is the more complex approach. If it’s the best approach for the situation, do that.
I did an inventory of all the systems I currently support (clients, current projects) and the “Netflix Problem”, where we deploy something and it breaks something else, has not been an issue. I’m proud to say, that in the current apps I support, we’ve been successfully deploying upgrades and new features. Successful deployments perhaps due to sufficient testing, automated and otherwise (topic for another day), and adequate DevOps automation. For current clients/projects, it would be hard for me to recommend microservices because deployments have been fairly quick, non-disruptive (no 503 and “under maintenance” pages), and quite successful.
Now, I did go back to past projects, and yes, having been in the industry too long, I had my share of deploy-something-break-something-else. Yes, if I faced situations like those in the past, where things are just so “brittle” when you deploy and change something, I definitely would seriously consider microservices approach if I could go back in time.
But even if I find myself wanting to recommend microservices for a (new) situation, it might not be easy due to the organizational characteristics required as described by Fowler.
You build it, you run it
That’s the way my projects/teams have been operating in recent years. True DevOps. But not all organizations are like that, especially in organizations (think very large organizations) that have Enterprise IT. In Big IT, you can still commonly find “project teams” (CAPEX) versus “operations team” (OPEX). That’s not going to change overnight. This is going to be a challenge. I’ll need to research if there are others that have “evangelized” to transition those types of IT organizations to a more DevOps type.
Decentralized Governance and Data Management.
Again, this is a challenge to propose microservices way of software at places with enterprise IT. Places with huge enterprise IT departments typically have governance here, governance there – standardize everything, etc. Which means, you can talk all day about breaking up the monolithic app into modularized microservices, the database has some sort of steering committee over watching it probably, so, what’s the point breaking the monolith when you got one gigantic consolidated database (some “database central”)???
I need to ponder how to solve this in big organizations because this is still the norm where enterprise IT is present. Or perhaps, just comment below on how you already solve this.
To end, I’ll repeat what Fowler said: if you’re not sure whether to use Microservices, stick with Monolith software.
Leave a Reply