Change management becomes the bottleneck when organizations exceed Dunbar's Number, and a "reverse Conway maneuver" is needed to counter excessive cost of coordination.
https://cloud.google.com/architecture/devops/devops-tech-arc...
My question then is: is this type of growth the norm, or is it exceptional? If I am, say, Tesla... do I need 1 order of magnitude more sw engineers when I start selling 10 times the cars I was selling 2 years ago?
It shows that you can have a siloed monolith.
There are also huge maintenance burdens that come from the lack of stable interfaces for modules. There is a reason there is a lot of excitement around ebpf. It is providing the sort of scaling that people have been needing for a while.
It tends to fail less often than corporations too. And my impression is that it's more efficient for developer time.
My impression is that microservices is a solution to keep a hundred people HAPPY (solving auxiliary problems you create for yourself) while producing about the output for the company that the "tens" would provide.
If management INSISTS on scaling from tens to hundreds, you can't very well keep the tens occupied on irrelevant side project. So instead you can do microservices. Either way you get the speed for the company of "tens" though.
If you are one of those, then I have news for you.
1. You are not going to reach the size of Google. Certainly not if you are engineering for it in your 2 person startup. But in case you do, see number 2.
2. Reaching Google scale means you'll have funding to hire good people to scale your software.
If you produce spaghetti code with tightly coupled components, well, then you are going to have a problem.
If you only have funding for 2 months, you need to hack together whatever you can get away with.
This is not against modularisation. By all means designs your system well. But don't lose sight of the goal.
Everyone already has a service based architecture whether they want to admit it or not. The question is the efficiency and granularity of it.
If you interface with any external systems that have data records (ERP, CRM, etc), your database is already spread out. You need to deal with it and be sure you understand the data efficiency and reliability of it.
I don't know what a monolith is that people talk about. Please show me one that doesn't talk to anything else.
Microservices don't address any of the issues I ever faced or people on Hacker News talks about like mixing languages, building code around organizational structure, isolating faults, etc. Microservices are way to granular to address those issues well. The only time I ever wrote a microservice is when I had to wrap some stupid SiteMinder binary apache mod blob.
Also, almost nobody writes a monolith, if they say they have a monolith they are probably lying. Do they have a database? S3? ERP, CRM, blah blah blah. Nobody in their right mind would build microservices, that is nuts unless they have some really special architecture. So can we quit the endless debates about stuff and instead focus on the real issue: how to build robust and maintainable service architectures? How to partition systems properly so you can manage avoiding having conflicting data? Eventually consistent systems, etc.
This is as dumb as the CISC vs RISC debate I lived through in the 90s.
I am currently getting a hard intro into a microservice first architecture. Where customers are managed in one service, users are managed in a different one, user operations are in a third one. All have their own databases and much of the data is copied between them. There are microservices, that are used by only one other microservice.
That's where we are now - arguing about the validity of "microservices are the best/first" approach.
Microservices are defined as self contained, highly granular, separately developed and deployed horizontally scalable systems.
Think about the debates about Linux vs Hurd, that's where we are.
You do realise that most calls to block storage in AWS result in network traffic, right?
The point is, abstraction is your friend.
Yes, but the point they were making is that you don't have to abstract across a network boundary. A proper module system and package management can divide work and organization without introducing IPC overheads.
Micro services have a few advantages but unless you desperately need them it’s a huge hit to performance, productivity, and reliability unless it’s your only option. Netflix needed it because of their complicated network architecture with servers distributed inside various ISP’s, why do you?
public class MyClass {
private Dep myDep;
void MyClass(){
this.myDep = GetDep();
}
}
public class MyClass {
private Dep myDep;
void MyClass(Dep dep){
this.myDep = dep;
}
}
First, many orgs using, say, Kubernetes still run their database separately in a traditional way with replicas etc. Second, those who do run their DB inside Kubernetes, probably using an operator, gain scalability and additional resiliency (it also depends on the DB, but these days even PostgreSQL operator works quite reliably).
https://oprearocks.medium.com/blasphemy-multiple-microservic...
Insisting on always having a separate db for each service is not a pattern, it's pure madness.
At a (potentially much) bigger cost.
For big companies it might me a miniscule difference, but for smaller companies it can be a deal-breaker.
Sir this is HN, half of the people here will quit their team well before maintainability is even uttered.
Running costs.
> Having all the code in one place _can_ make things easier to figure out in the long term.
My experience is the exact opposite. A huge monolith makes it harder for developers - especially new ones - to get a grasp of how everything is connected. A separation of concern into micro services is sometimes a good solution.
If you refer to databases: Splitting one service into two services can at most give you a 2x scale-up potential (usually a lot less), and the effect diminishes for 3th, 4th service. Mathematically and logically. Splitting services = vertical scaling.
If you want 100x, 1000x scaling you need to invest in true horizontal scaling anyway, and that works pretty much the same way for monoliths as microservices.
Few extra?
Have you not considered applications where you need to spin up/down _extremely_ resource intensive instances?
A year++ ago I worked on a health-related application which used a system for processing X-ray images. During typical work hour (6 am-6 pm) it required a _huge_ amount of CPU and RAM instances. By shifting those specific services out to specialised instanced, we saw a $50K/month saving.
The rest of the application is a lot more lightweight, but of course has to run 24/7, but being able to spin up/down required instances, and just pay for what you use, is a huge benefit for a lot of companies and organisations.
I maintain a SaaS written as a monolith and I can absolutely spin instances that only load one part of the code and do a single thing, for example some instances only handle MQTT messages while others only serve HTTP endpoints. That does not make it microservices, it is all one code base sharing one database.
Regarding your point, most other disciplines gain knowledge over time, such as civil engineering, chemistry or biology and we don't discard results from the past with this kind of strawman argument of there supposedly not being anything to learn since. If things were like that, any progress would be impossible.
This attitude is extremely toxic to the development community.
"Its old" is NOT valid criticism.
"Its new" is NOT valid praise.
This "microservices are better" argument was made in the 90ies and top dog is still Linux kernel (the one that was on the monolith side of that debate).
So yeah - microservice advocates haven't learned anything since the 90ies, or from the SOA era, etc... (but I suspect they were in secondary/high school then)
An anecdote: When I joined my current company had more code to orchestrate services, than the actual business value generating code in the services. We still produce an inordinate amount of code that exists just to facilitate microservice architecture. (it's also untested code, because we just don't have the money to spend time on testing it)
> I can hardly understand folks running k8s for a 3-container setup.
Why can't you understand them? I understand them - It's cool, that's why they run it. It's not about rational use of resources, it's about being cool.
It has become more and more true each passing year.
Companies that repeatedly fail to detect and solve this type of problem using automated testing and QA are exactly the companies that lack the sophistication to do distributed microservice architecture.
Learn to do proper CI/CD, end-to-end testing, and logging/metrics on your monolith before you decide to transition to microservices.
Also in many cases work should not be performed synchronously in response to http requests but in a background queue to keep your service robust and responsive. When taking a new order you should just place it in some queue and respond ASAP so there is zero chance you miss a customer order because of some error. In that case there is no difference in scaling a monolith or microservice as you can indepedently deploy 25 consumers for module X events or 10 consumers for module Y events and so on.
Someone unfamiliar with the concept of cost and benefit shouldn’t be making architectural decisions in the first place.
you could have a monorepo. you just need to build each service independently, which you can do with bazel/gradle/make or other build tools.