Monoliths are the future

Definitely can relate to the pain of falling in the distributed monolith trap.

Kelsey did you ever get round to reading “Team Topologies - Organizing Business and Technology Teams for Fast Flow”

I think the issue with Monoliths is well explored there. Simply from the point of view of cognitive load, conways law, autonomy and ownership.

What did you think?

I call B.S.. You’re conflating two things. One is a deployment infrastructure, another is an application pattern. I can deploy a monolith in k8s and I can deploy micro-services on a single server or a fleet of on-prem servers using any of the legacy dev-ops deployment automation tools. Sure k8s makes doing micro-services easier because it’s got a lot of the raw building blocks necessary to handle the CD process but in no way are the two concepts related. They’re tackling different problems. You’re making the same mistake that you’re criticizing others for by equating the two. What you’re really describing is an organization doing a “big bang” refactor with poor planning and execution.

I disagree with the statement that Monoliths are the future. But I do agree that we should not do microservices just for the sake of doing it. If there’s no benefit at all to your business to do it this way, then don’t. Different situations call for different solutions. There is never a one-size fits all solution.

There are pros and cons to both approaches, and you simply have to apply it the the context of your business or tech product. As software engineers, we strive for perfection, but we should also be pragmatic.

It’s an aluring title and I think Kelsey is just driving the point home that you don’t need microservices for everything.

Microservices do not have huge value if you are only trying to solve a technical/architectural problem with it - especially if you have many individual projects, or similarly a small dev team.

Microservices however help scaling out teams, as it is like creating multiple autonomous “startups” within a company which allows a more faster/agile development approach.

Ethan Garofolo makes a point in his book “Practical Microservices” that it’s not code layout that makes a system monolithic, but data coupling.

I tend to agree with what you write and I would say that what you describe is caused by two problems. First, most people missed the main lesson from the pattern movement: every design problem involves a number of possibly competing forces which requires us to strike a reasonable balance; it is by recognising those forces that we may identify a pattern that could result in a reasonable balance for our specific problem. Second, microservices are more of a solution to an organization problem than to a technical one: they make it easier to evolve parts of a system independently rather than requiring everybody to be in the same place at the right time, over and over.

I think you need to first figure out why you have a monolith. Startups have their reasons, then there is lack of experience or leadership, technologies chosen, organization, etc. Create the right team to reengineer the system and reap the benefits.

Isn’t this just https://www.martinfowler.com/bliki/MicroservicePremium.html again? Martin said:

So my primary guideline would be don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.

There isn’t a framework, methodology, language or any technology that suits every scenario.
We have large monolithic applications running on enterprise-class UNIX servers that are rock solid.
Microservices, serverless applications, and even containerized applications work in certain cases - but definitely not all. I’ve seen a critical monolithic financial application move from 2 large AIX LPARs to over 30 VM’s running microservices. I don’t believe in changing the application design to suit the technology stack, but rather providing the right technology stack that for a solution.
This reminds me of the NoSQL hype when RDBM’s were said to be legacy.

I think everything is right and wrong at the same time you’re writing.

Network based distributed services introduces a clear runtime complexity and today you have to take care for that on your own. So to intodruce such complexity, you need good arguments.

However: how big the complexity depdends on the architecture and interfaces you choose and how many services you create.

We saw developer teams, which use a tight coupling between services on one side and on another side they had a lot more complexity. In fact, it was a loose-loose.

But I know designs with a few bigger applications (mabye macro services), where the developers can in the next step decide, how to implement that macro service. Inside of these macro services you have tight coupling more often, because it doesn’t make so much sense to keep internal interfaces stable. And some developers split that macro service in more internal services, some not.

So if you write a mail service like postfix, it’s completly fine to have tight coupling between the internal services (and that are quite some) and it’s not ok, to break the SMTP interface, so the external interface of that application.

The macro service gave room, that 20 developers can work together in one big application (i.e. a webshop), what is quite hard with one big code repo. So from the organizational perspective, smaller services make sense. But the idea to make them as small as possible, just because you can (so maybe just 100-1000 LoC) is not really convincing and was never convincing.

While everyone comes up with a new system arch. term nowadays, here is my contribution, “Panopticonith”.
Basically there would be some services small or big but only one global database and cache to check the overall state of logic and volatile operations. That’s it ;_;
Setting up distributed db and cache is easy. The services to be run separately will be “pan’s” and “opticon” to manage all operations from installation/management to all pans from the center. Neither centralized nor distributed systems alone are efficient.