Kelsey Hightower

Monoliths are the future

What you’re about to read is an excerpt from Go Time #114. You should read the original transcript or listen to the entire conversation for more context. To set the stage, this is the 2nd of Kelsey Hightower’s unpopular opinions (our new segment which people seem to be enjoying.)

Monoliths are the future because the problem people are trying to solve with microservices doesn’t really line up with reality. Just to be honest - and I’ve done this before, gone from microservices to monoliths and back again. Both directions.

Most people say,

“Look, we lost all of our discipline in the monolith. We just started creating classes, this person went and bought the Gang of Four book, came back and started doing design patterns and then QUIT, so half our codebase is doing this thing over here…”

So now it’s a nightmare. Now the codebase is so bad, and you say,

“You know what we should do? We should break it up. We’re gonna break it up and somehow find the engineering discipline we never had in the first place.”

And then what they end up doing is creating 50 deployables, but it’s really a distributed monolith. So it’s actually the same thing, but instead of function calls and class instantiation, they’re initiating things and throwing it over a network and hoping that it comes back. And since they can’t reliably make it come back, they introduce things like Prometheus, OpenTracing, all of this stuff. I’m like, “What are you doing?!”

Now you went from writing bad code to building bad infrastructure that you deploy the bad code on top of. There are reasons that you do a microservice. So, to me a microservice makes sense in the context of…

You’re a bank, and you have this big monolith that does everything. Then mobile comes out. You wanna do mobile banking, but it requires a different set of APIs. You don’t have to add that to the monolith. You can go create a new application that handles most of the mobile concerns, and then connect back to the existing infrastructure to do its work. That makes sense to me. But this idea of “microservices are a best practice” - it seems to be unpopular with most people’s initiatives.

They’re like,

“Oh, we’re bringing in Kubernetes, so we can do microservices. We are going to rearchitect everything.”

Because it drives a lot of new spend, it drives a lot of new hiring…

So a lot of people get addicted to all the flourishment of money, and marketing, and it’s just a lot of buzz that people are attaching their assignment to, when honestly it’s not gonna necessarily solve their problem.

Hear Kelsey’s expert opinion on where Kubernetes is headed (and more) 👇

If you enjoyed this excerpt, check out John Graham-Cumming’s How I convinced my government to apologise to Alan Turing


Sign in or Join to comment or subscribe

2020-01-30T19:51:35Z ago

“and I’ve done this before, gone from microservices to monoliths and back again. Both directions.”. The article makes it sound you’ve just gone from a distributed monolith to a monolith and back again.

Are microservices a viable substitute for code quality, standards, and discipline? Absolutely not. Do some organizations use/abuse microservices when they shouldn’t? absolutely. Both of those facts, however, are orthogonal to whether or not microservices can and do bring value to software architecture.

2020-01-30T20:55:01Z ago

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.

2020-01-31T03:27:01Z ago

One problem I see when you have a monolith and decide to start building microservices is that companies don’t change their organization structure. You end up with a team of 30 people managing a bunch of microservices instead of smaller teams managing a smaller amount of microservices.

2020-01-31T04:26:14Z ago

This. 1000% this. For a sufficiently complex system, it’s impossible for a single person or team to understand the whole thing. You need to find ways to draw neat boxes around certain parts of the system and say, “this team X is responsible for box X, this team Y is responsible for box Y”. Whether or not you do this within the context of a monolith or microservices is less the issue, it’s more about smart in drawing the right boxes. However, microservices can provide a nice abstraction for team X to release some internal enhancements to box X without team Y needing to care.

2020-01-31T04:24:47Z ago

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.

2020-01-31T09:43:46Z ago

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.

2020-01-31T18:16:53Z ago

Kelsey, thanks for writing this up. You have highlighted a few key risks when migrating to microservices.
I agree that too many teams build distributed monoliths and have more problems than they started with.
I agree, that microservices solve specific problems and need to be adopted with those problems in mind. I also agree that many teams have a hammer (microservices) and apply to all problems!

I posted a cartoon recently about this issue:

I would like to point out a few example problems that microservices do not solve, which you might have implied they could solve:

  • No clearly defined DDD bounded contexts between domains
  • Code coupling
  • Lack of well-designed abstraction layers

You can have those problems in any type of deployment architecture, be it monolith or microservices.

I would like to point out a few example problems that microservices solve well:

  • deployment decoupling: you can (re)deploy one part of the system without impacting others
  • vertical scaling of parts of the system: you can scale an individual microservice instead of the whole monolith
  • less coupling to specific technology decisions: you can replace a Java Spring MVC microservice with RubyOnRails when needed without rearchitecting your whole monolith

Let me know your thoughts!

2020-02-01T23:10:03Z ago

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.

2020-02-03T04:19:46Z ago

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.

2020-02-03T10:10:00Z ago

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.

2020-02-03T15:00:15Z ago

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.

0:00 / 0:00