Do we really need microservices in order to scale out an application horizontally?
Hey there,
Last several years I've been thinking about microservice architecture and all costs we have to pay in order to develop, test, deploy a service.
Let's pretend that we all write brilliant code and there is no entire problem with an architecture and our folks from business don't change their mind 5 times per week about how things should work.
But I still see a lot of issues with microservices:
If you have a feature and that feature is touching different services, congrats you need to write e2e tests. You need to somehow run e2e tests and sometimes you will not be able to do it from locally. You still can "mock" a service, but what if you need to mock one specific part of a service, not entire one and the developers have not designed it.
Of course we can try to setup CI/CD pipelines and spend some effort to make a good testing pipeline, but it will decrease individual performance dramatically. If you write a new feature for service A it is not enough to run unit tests and release the feature. You need to wait until your Testing pipeline will finish tests and etc.
And i'm not saying that "microservices are evil". I'm just trying to understand why this approach is so popular (even in dotnet world) if in most of scenarios there is only 1 thing we want to achieve: opportunity to scale an app horizontally.
As far as I know there is an Actor Model (aka.net or orleans) you can use for your application. You may write an monolith architecture, but because of actors model you can scale workers and etc.
But in the same time you have your whole system in one place, you can write functional tests instead of e2e and save hundred hours.
So guys, I'd like to understand if someone had an expirience of using Actors for their real projects. What problems did you face? What was your expirience?
Thank you
10 Replies
Microservices are not an architectural "solution" as much as they're an organizational one
You can scale a monolith horizontally, no problem
But you need the management to actually manage, so that the engineers can cooperate making it
With microservices, two teams working on antipodes, with zero communication, can still work on two separate microservices
As for the popularity...? In part, they're popular, because they... are
"Google uses X technology to scale to millions billions monthly users, so our company that has 267 monthly users should also use it"
"Google uses X technology to scale to millions billions monthly users, so our company that has 267 monthly users should also use it"You just described the company I work for
in general yes, you are right. we can scale a monolith as well, but usually we say monolith and mean that all things happen in "memory" and in this case in order to scale a monolith you need to deploy a whole new instance of you monolith and additional environment. it is not really flexible as microservices.
but in another hard we have actors which can be designed (from project / source code point of view) as a monolith, but behavior as microservices. and you can easily scale just a peace of your app, not entire one
yes, sometimes (maybe most of the time) people just copy solutions from big tech companies. but we can't blaim big tech companies for everything. I'm trying to understand maybe Actors also has some limitations and I don't just see it
I'm not blaming big companies, they need those solutions, and more
I'm blaming a local corner flower shop for jumping onto "our custom artificial intelligence will tell you which flowers to pick" bandwagon
yes, current days become more "artificial" and less "intelligence" 🙂
If you truly want to mimic large companies like google, then you don't start with microservices because they didn't either. They kept things simple until they found that they needed to scale and then they did what they thought would solve their problem. Sometimes that is breaking the monolith up into microservices, but more often than not, it means horizontally scaling the monolith first and only after you'd scaled so massively that you discover that scaling that way is so inefficient that you can save significant enough money to justify breaking the bottleneck piece into a microservice so that you can scale it separately from the rest to justify itself.
No. You don't.
You want microservices if you want to horizontally scale your application non uniformly
IE if you wanna scale up one part aggressively to x5 without scaling the whole app to x5 unnecessarily, then you use microservices.
You can have a mostly monolithic app with just 1 part broken out to a seperate microservice that you want to just scale that 1 part seperately from everything else if you please.
But it's 100% valid to just uniformly horizontally scale your entire app as a whole, especially if application traffic is fairly evenly spread across the whole thing.
Usually you resort to microservices when your apps domain has become broad enough that you can save a notable amount of money on being able to scale up <specific part> seperate from everything else.
that is exactly what I want to ask.
theoretically, actors can allow you to archive the same.
So why actors are not so popular?
Are you talking about just having all your microservice projects in the same solution so you can run em all together locally for testing?
Microservices isn't much of an archtectural decision but an organizational one, really. Non-microservices can scale the software the exact same ways.