Not a bad article, but he omits the huge cost of running everything as lots of cloud services (or worse still, functions) instead of putting a single monolith into a VPS for a few tens of dollars a month[1].
[1] Yes yes yes, assuming you're not running Google.
It definitely costs more, but "huge" is debatable. For the typical SaaS webapp product, the cost of running everything as cloud services is negligible compared to the cost of salaries of people who maintain it.
If you're a solo dev on a shoestring budget it's worth considering, but a funded startup shouldn't be distracted from finding product-market fit and growth in order to save $1000/month on cloud costs.
You don't need "cloud certified" people. The junior devs I work with can make a highly available database with automated and fully tested backups, with point-in-time-restore functionality, by clicking a few buttons in the RDS console in a few minutes. I can't say the same about manually installing postgres on a VPS.
You can start with a monolith and evolve it into microservices. Very broadly:
1. Start the monolithic app
2. Write internal classes and functions such that they mimic an independent API and schema
3. Write an API wrapper around unique functionality
4. Allow exposing APIs on unique service ports
5. Run independent copies of your app, running one API at a time
6. Separate the schema of each API into its own database and connect at runtime
7. Now you have a microservice
Hum... You don't get a choice on where you can stop. Most software requires #1 and #2 to be sustainable, but yes you can do a lot of it with #1 alone for some time. But there also exist software that needs all of those other options from the bare beginning, or they won't fulfill their job.
Build a functional core, isolated with values, and an imperative shell. Systems built this way can be pulled apart into microservices if you really need to.
Another misconception is that they somehow scale horizontally "better". They do let you scale components independently of each other, but this isn't as useful as a lot of people seem to think it is.
> “One of the most common misconceptions about microservices is that they solve a technology problem,” says Johnston. “But really they solve a business or organization scalability problem.”
I disagree. Service oriented architecture (note I don't say microservices, because I think that often goes too far) does solve technical problems. But they are problems that articles like this often ignore (maybe the authors have some misconceptions about microservices themselves).
For me the main benefit of seperate services isn't about organization of code or teams, it is about isolation.
The technical problems I think service seperation solves are:
How do I ensure that a security vulnerability in X doesn't compromise Y (least privilege)?
How do I minimize the blast radius if an unusual request or traffic patternconsumes an unexpected amount of resources (related to above, but doesn't necessarily need to be malicious)?
How do I deploy a change to X without having to rebuild and retest everything else?
How do I give a group of people access to manage X without giving them permissions for Y.
How do I optimize usage of some resources? (Note: multiple services have overhead, so for this to apply, you need to have enough scale that the benefits of fine-grained scaling and rightsizing of individual services outweighs the costs, but contrary to some comments you don't have to be quite as big as google for it to matter).
For some of these,"microservices" are not the only solution, and depending on your exact situation it may or may not be the best solution.
The important thing is to understand what specific problems you are trying to solve, why, and what the tradeoffs are.
14 comments
[ 3.0 ms ] story [ 39.5 ms ] thread[1] Yes yes yes, assuming you're not running Google.
If you're a solo dev on a shoestring budget it's worth considering, but a funded startup shouldn't be distracted from finding product-market fit and growth in order to save $1000/month on cloud costs.
Very quick talk on what it buys you: https://www.destroyallsoftware.com/talks/boundaries
PSA: Microservices architecture is a technique for scaling organizations, not systems.
I disagree. Service oriented architecture (note I don't say microservices, because I think that often goes too far) does solve technical problems. But they are problems that articles like this often ignore (maybe the authors have some misconceptions about microservices themselves).
For me the main benefit of seperate services isn't about organization of code or teams, it is about isolation.
The technical problems I think service seperation solves are:
How do I ensure that a security vulnerability in X doesn't compromise Y (least privilege)?
How do I minimize the blast radius if an unusual request or traffic patternconsumes an unexpected amount of resources (related to above, but doesn't necessarily need to be malicious)?
How do I deploy a change to X without having to rebuild and retest everything else?
How do I give a group of people access to manage X without giving them permissions for Y.
How do I optimize usage of some resources? (Note: multiple services have overhead, so for this to apply, you need to have enough scale that the benefits of fine-grained scaling and rightsizing of individual services outweighs the costs, but contrary to some comments you don't have to be quite as big as google for it to matter).
For some of these,"microservices" are not the only solution, and depending on your exact situation it may or may not be the best solution.
The important thing is to understand what specific problems you are trying to solve, why, and what the tradeoffs are.