All those reasons are very fine ones - but it's still a dangerous move to go microservice style. You have to know what you are doing, and in our buzzword driven industry that's not the case usually.
Little insidious time wasters will creep into your work flow and they will lurk there eat away dollars and you won't even notice.
I constantly switch back and forth between working on monolithic and microservice apps and for the majority of companies sticking to a monolith until the pain points you mentioned become unbearable is the good call.
Even then, just break down your apps to bigger sized services, and stop when the pain goes away. Microservices is a catchy name but if anything micro is the poison there.
What do you consider as the most important things that people are do wrong?
Also, could you enumerate the time-wasters? Off hand, besides occasionally having to re-consolidate the architecture, I can’t think of many. It would be good to know how much the time-wasters cost in contrast to the alternatives.
You can do that by several different ways. Overall, if one wants a "one size fits all" answer to how to break code into teams, it is by breaking the code into libraries, not services. Services are a niche tech here, to be considered when the others won't suffice.
> if you need to scale the (monolith) service and it is too expensive to just scale it n times.
Again, nearly every time this happens, the correct answer is to refactor the monolith so replicating it scales. Services are only for those cases where this won't suffice.
I don't think I disagree with how you think. But I do think your comment is easily misunderstood and harmful without those qualifiers.
Most of the hatred towards microservices is probably better directed at REST, which is a good paradigm for serving documents to web browsers but is overcomplicated for microservices. RPC is a good alternative, and gRPC is a good implementation of it.
[1] My phone autocorrected this to “deplorable”, which is also a good adjective for a monolithic web application that contains lots of libraries and is only deployable as one artifact.
If you release a new version 1.1.0 of a library you have to update and redeploy all applications that use this library.
If you understand binary compatibility you can deploy a library without deploying its client applications/libraries (they would need to be restarted, however).
In fact, this is one of the very reasons people invented shared libraries! It's why, for example, Linux distros are based on shared libraries: one can update large swaths of the system by updating a single package.
If your languages don't support this then it would be very unfortunate indeed.
2) agreed ! thanks for adding the qualifiers !
It sounds like you're saying that a single micro service maps to a team. Do you think each team should manage many micro services and how many do you think each team should manage?
I'm generally interested but having been the guy on dev teams to handle most of the configuration management stuff I've not really been willing to listen to micro service advocates.
Depending on runtime environments/architectures the CM costs sound prohibitive at best.
This meant, for example, that my team, had our whale, an audio transcoding service, an automated transcription service, a post-phone-call messaging service, and several data integrations.
If you need a whole team to do nothing but maintain a service, it seems to me like you built it to do too much.
it also depends on your infrastructure to manage services. if setting up, managing, deploying and monitoring a service is cheap it can make sense.
The nature of software for managing humans is that it's very fuzzy, fashion/tend driven, diverse.
E.g a recent trend is for companies to try and reduce the number of undesirable applicants they get for jobs (since in a big e.g retailer, saying no to a candidate is likely also saying no to a customer).
So customer now needs to inject an e.g culture fit quiz into the candidate experience, which only unlocks the apply button once the candidate has "passed".
This kind of tweaking and evolvement is not possible within a monolith, so good APIs allowing vendors of the customer's choice to inject functionality are essential.
That functionality can then be injected in the form of a small app that does one thing and does it well, has it's own database, i.e has many of the characteristics of what people think of as microservices.
To Martin Fowler:
> In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
Assembling HR ecosystems from separate apps certainly meets all of the points above.
From what I'm seeing, the microservices style is commonly being used for much smaller services a la Unix, typically for reuse across an org. Introduces too many issues around SPOF, orchestration and queuing, versioning, discoverability. I think Lambda is the correct evolution for making that work (if nothing else let AWS figure out stuff like failover, deployment, and the standards for fabric between functions).
That's not the way the industry works.
Some exciting, specialised startup develops some kind of cool UI blended with some psych validated content, and manages to get it installed at a couple of large reference clients, and then finally manages to draw a link between the quiz results that candidates achieve, and their ultimate chances of successful employment (maybe just getting hired - maybe their on the job performance after X months).
The customer is buying into this package of leading edge stuff. They don't want their existing vendor to have some junior developer hack something up and put it behind a feature flag. They want the new shiny stuff, and they want it from the new shiny vendor.
The code behind such a quiz is usually trivial - the intellectual property not so much.
"Monolith First", Martin Fowler
- if you need to scale the number of teams working on the same product you need to introduce microservices to make the teams work independently from each other.
- if you need to scale the (monolith) service and it is too expensive to just scale it n times. microservices can help because you can scale each microservice independently.
- that's said the overhead is real. There have been quite a few publications and advocates (like Randy Shoup) that staying monolith is fine until you have pain that a microservice architecture can ease.