They're also available to solve technical problems. For instance, it's hard to run some python3.5 and some python3.9 in a python monolith. A monolith must choose one python version and cut over en masse at some point. Microservices allow more gradual adoption (in production, not just in test suites!) of low level technology changes.
I'm a huge monolith proponent. But that doesn't mean I think every application should be one service. I just believe you shouldn't create a second service until you have a good reason to like "we need to run on two different tech stacks", or "our team is getting hard to manage let's split it into two teams that work on 2 services".
And it's simple to concede that monoliths need to be split sometimes. It's much harder in practice to do so. Most monoliths do not have standards, let alone enforcement mechanisms, to ensure that the design of the monoliths leave open splitting later. The things that can make that process difficult (or impossible) are many and subtle, such as global state, in process locks, interpreter protected consistency guarantees, disregard for ABI implications, etc. Having different processes (in production!) does guarantee that a snarl of those problems will not prevent splitting things up later.
If you need to share state or you need consistency/locking/transactions across bounded contexts on one service it's trivial to implement. But this can be incredibly difficult to do correctly across multiple servers. No one has implemented a multi-phase commit over multiple services and said "dang that was easy" afterwards.
Without a way to keep the system heterogeneous, people have to accept that they are on the same upgrade treadmill as the rest of the people in the organization, which means they have to constantly invest time and energy into keeping up with things.
Containers or microservices mean that the upgrade happens fifteen times, not once, and each group has their own little passion play about why they should do it later instead of now. And in the time it takes to argue about 15 upgrades, 2 more versions have come out.
Using dynamically linked libraries enforces to upgrade all dependencies in lock-step. But you need to fix bugs or security issues only once for your whole software distribution.
You can do all these things either way. The question is which way suits your tools and organisational structure.
And there are worse scenarios than python upgrades. What happens if your processor or your OS reaches end of life? Do you keep running the whole stack on Windows XP without security patches until the last bit is ready?
No technique or tool will fix your organisation.
That sounds to me like you are complementing the downsides of running a monolith with the downsides of operating a distributed system, without any noticeable upside.
I wouldn’t run a system where the two servers call one another.
This is a technique for reducing risk via toggles at the load balancer. The reduction is achieved by making it possible to deploy smaller changes to users, and by reducing the latency of rollback.
These are only useful if you have the ability to introspect the system state in production and confirm whether a new version is working correctly.
It sounds like you're referring to blue/green deployments without using it's name, for some reason, and while failing to present any case of why a monolith provides an advantage. You're just showing downsides without any upside as a tradeoff.
I mean, with microservices you can also do blue/green deployments, and they are not all-in like monoliths. Each deployment only covers a subset of features that can gradually be rolled in and out with the only risk of causing partial failures.
I just saw a guy trying to argue that writing functional-style Java is the "new" way to write Java, and that not using functional interfaces means you're writing "old" style code.
Sounds right to me. (Of course not having first-class functions was just as bad 20 years ago, but fewer people had realised it back then).
If you take the time to look into it, you'll discover that the functional style is only a change in the "fashion sense" to those who are totally oblivious to their advantages.
I get how the pedantic take on monads turns people away from the functional side of programming, but you'd be hard pressed to find anything to criticize how returning either/result monads from promises is not a huge improvement over the boilerplate-rich/pure OO approach to Java.
C'mon, you've been around here long enough to know better than to be making such comments
https://insights.stackoverflow.com/survey/2020#most-popular-...
Sane language. Fantastic tooling. Huge ecosystem. Backwards and forwards compatible like few other things.
Yes, pretty much the whole world is using Java. Some FAANGs use it as basically their default software stack, and at most have introduced some Kotlin along the way.
The world doesn't revolve around flavor of the month tech stacks.
If you check GitHub JavaScript and typescript are outstripping Java.
Have you ever heard of search bubbles?
What I would say is that, from a 10km perspective, functional interfaces are just where the Interface Segregation Principle takes you when you really lean into it, and that dependency injection can be thought of as just a convenient way to do partial application in bulk, and that CQRS encourages you to create an ever-wider separation between your commands and your queries, and that, in general, once you get far along where clean object-oriented design wants to lead you, the whole functional vs OO debate often starts to feel like it's quibbling about syntax as much as anything else.
> Microservices Solve >Both< Technical and People Problems
I've mainly come across the occasional one-off where a different language is significantly better suited to the problem at hand, so that has been broken out as its own service, and there's another one here in the comments about migrating a python application between versions (I could argue the semantics of microservice here, but I'll roll with it), but I have not come across many where a microservice was the "right" solution to a purely technical problem.
This should speak for itself. If you ship a service which is well defined and only handles a reasonable amount of functionality, reasoning about its runtime behavior, memory, CPU usage, IO, etc, becomes much simpler.
Microservices are easier to test, either through unit testing, load-testing, integration testing etc. If you push a new version of a microservice and you see it's using more memory than the previous iteration, it's usually trivial to work out which line of code caused the change.
Microservices are mentally easier to grok for engineers working on them. I've worked on monoliths that required months for engineers to get up to speed on working with them because they did SO much stuff and if we had a memory issue with our monolith it could take weeks to diagnose the issue and we had to have our best engineers look at those problems because the service had grown so big and complex over many years.
I think an individual microservice is easier to grok and debug, but I also think a system made of microservices is harder to understand and debug. Depending on scale this is a bit of a wash to me, YMMV.
Basically it gave me the flexibility to work faster, and generating the code (e.g. the REST endpoint or the Svelte/Sapper front-end) is also a lot faster, and I get to host them on Vercel for free
Oh and it also helps me to separate business logic code and other not-so-public data to somewhere else (Heroku instead of Vercel) and it just runs completely separately. That way I don't have to worry about accidentally sharing data
As a solo designer/engineer this Vercel + microservices / tiny APIs + tiny frontends makes my life much easier
1) Long-living connections. One part of your application offers large file downloads, so that your users sometimes take significant amount of time to download, and the error rate shall be low. Think people doing `curl -L https://github.com/.../some-commit-hash.zip` in CI. I'd guess this is not served by github's ruby monolith. Or you use websockets. Redeployments typically stop all running tcp connections. Splitting this part off allows you to redeploy the main application frequently without disrupting websockets or downloads.
2) Reduce startup time. For some languages/ecosystems, startup time is significant and scales with the size of the codebase. For example, a typical java enterpise app like keycloak has half a million lines of code and takes about 1 minute only for startup. This is even more relevant when running things in AWS Lambda or google cloud run, and can also be relevant for integration tests. Having several deployables each handling a subset of the functionality may give you better cold start times than having one that contains all code.
3) Resiliency toward resource exhaustion. If two functionalities are served in the same process or VM, and one of them
* has a memory leak
* uses the connection pool to the database inefficiently and thereby clogs it up
* has an endpoint that is overloaded by a misbehaving client
then the other functionality is also affected, which can be avoided by putting them into separate processes/containers/VMs. Splitting services allows to reduce the effort spent on resource hygiene and rate limiting.
4) Binary size. It is often convenient to compile static info or asset-like things into the application, think geoinformation on timezones. This bloats the binary, splitting that part off into an independent deployable can give you a much smaller binary for the main application.
2) Agreed, for individual services. Maybe/maybe not for the entire system.
3) I think this is generally true, but if you have a service that others are dependent on, you can still have these problems. Auth services for example (that was a fun day at work).
4) Sure, but now you have two binaries.
However, microservices can also serve actual technical purposes too. But the nuances of accepting two viewpoints often placed in juxtaposition to one another is not internet friendly. Microservices, service oriented architecture, whatever you call it depends on your level of cynicism i suppose (or optimism?).
So I will keep commenting that it isn't just about technical issues and it isn't just about organizational ones, and you must look at both to really understand what is going on.
But I probably did get a little too excited that a technical post acknowledged and made it an important point in their article.
Microservices have been from the start an organizational tool, with reliability and the ability to scale horizontally to avoid constraints of vertical scaling trailing at second place.
The rationale is that the first bottleneck that is hit by a growing organization is developer's throughput (i.e., the ability to deploy bugfixes and features without hitting blockers due to multiple teams being affected by a changeset). After that point, a service has to grow a tad more until reaching a point where the requests bounded to a subset of features justifies peeling them out to independent services.