151–160 of 169 posts
Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?
Yea. IMO, microservices are usually more of an organizational solution than a technical solution
>Modularize Your Monolith It is true that probably any monolith can be break down into components, that won't prevent the full redeployment (and all the risks that it brings) though. I think in reality no one needs Microservices, or Monolith for that matter. You would pick the poison that adjust the best to your needs.
Or do the whole redeployment all the time and you'll see the "risk" of doing so was psychological or a few better tests away. I work in a 150+ yo company where change is ... well not welcome. When we said we could try to release without schedule, several times a week, whenever we want just because we finished one thing at a time, you should have seen their looks. We have 100 microservices doing low latency trading in…
While I agree that there are definitely some cautionary tales regarding microservices, consistent and autonomous delivery across many teams with a complex monolith is equally if not more difficult than some of the cons that come with microservices. I don't think the answer is as easy as "you don't need microservices". I think the answer is "you can effectively use both".
You do need microservices because when when parts of you system are badly written or the requirements change, etc, etc.. You can just shoot a couple of the offending microservices dead and replace them with better implemented versions. [Assuming there are at least 6 developers]
You are probably correct for small to medium sized tech teams building software. With that said, in 2022 I'd expect any company selling a SaaS product to be built with micro-services. Buying a SaaS I want all of the benefits, but no longer need to deal with the hard parts.
Isn't the devil in the details? Some problems are solved better as Microservices. Some problems are solved better as monoliths. Ultimately it is the lack of maintaining the solution we choose that leads to the "grass is greener" fad chase.
One of the benefits of being in this industry for a while is that you learn to spot and avoid fads. You even learn classes of fads. Microservices instantly looked like a fad. Two classes of fad apply. One is a "move stuff around and complexity will magically go away" fallacy fad. The other is a "way to promote vendor lock-in or higher cost" fad. Other major classes of fads are: consultant self promotion fads, re-inve…
Microservices are very much not a fad, and they aren't even that new of a concept. They have just gotten more attention recently, and have probably been over-adopted a little bit. In the right circumstances, a microservices architecture can absolutely boost developer velocity. You can reduce development/mental model complexity, reduce blocking internal dependencies, increase performance of tooling and deployment, and…
Was there historically so much resistance to other forms of loose coupling and high cohesion? Maybe from the anti-OOP crowd when OOP was first catching on?
As someone who has built a monolith, full-stack (literally everything from MySQL to PHP+Node.js to the Web to Cordova) platform at https://qbix.com/platform I can still tell you, that microservices are great. But the average person isn't going to fine-tune all those microservices. They need to install something that just works out of the box. An expert can be hired to fine-tune some parts of the stack (e.g. add a CDN…
Earlier quoted context omitted.
My 2c is that an experience architect would know that it would be ideal if they could do this and be right, but in practice they aren't likely to get those boundaries correct up-front and it takes time and experience working in the domain to see what those boundaries truly ought to be. Also, it's perfectly possible for monolithic applications to enforce boundaries as strict as microservices do via a "modular monolith…
100% agree. You can write bad code using both Monoliths and Microservices. However Microservices are inherently more complex and slower than Monoliths (because of the added encoding/decoding and network overhead).
My previous employer was a small engineering org of around 40 engineers with a monolith of below average quality, trying to go in a microservices direction and not really having that pan out a great deal due to being unable to spare the engineering bandwidth to invest enough in managing the complexity while still having to deal with the monolith.
My current employer is an engineering org of around 4000 engineers that one two headed monolith that makes up the original product (web app + api share some code and are monoliths in their own right) and also very successfully uses microservices for everything else and there is a lot of them.
At my previous employer dealing with the monolith was fine even though the code was rather horrid, and we would release twice a week. The "microservices" I wound up building/working on there were not worth the overhead / complexity added at all and we would have been far, far, far better off investing in cleaning up the monolith to make it safer/easier to work in.
At my current employer dealing with the monolith is not fine. You have to book releases in a calendar, it's scary, it's giant, and despite multiple releases of it per day, there are so many other teams that book releases for it that you have to queue up to get your turn and it's done that way for safety. Yes, we also use feature flagging too. It's also vastly more difficult to know/find who you have to communicate with about changes to the monoliths because unlike a tiny engineering org, that information simply doesn't fit in your head. Here, the microservices we own are awesome in comparison. They are small code bases that are easy to reason about, our organization invested a massive amount in the technical maturity needed to operate, maintain, and be able to handle the complexity, and we have continuous deployment pipelines that mean we can safely release multiple times per day and when PRs are merged they are shipped all the way through to production in around 15 minutes.
So, when you say "more complex and slower" you have to ask yourself "than what?" There is no "one is better than the other", there is only "every tool is the right tool for some job" and "every tool is also the wrong tool for almost any other job it was not designed for" and your job is to understand exactly what tool your specific situation actually calls for.
This is why I like modular monoliths as a starting point, as they're essentially a multi-tool. A half-way compromise which is not as easy to use as a full-blown dedicated tool, but is versatile enough that if it's the only tool you have and you have no idea what job you're going to need to do, then you've probably made an adequate choice regardless of what the situation calls for in the end. And if you outgrow your multi-tool, you can much more easily swap it out for a set of it's dedicated equivalents.