Welcome to this issue of the WeAreDevelopers Live Talk series. This article recaps an interesting talk by Michael Eisenbart who talks about the pros and cons of microservice architecture.‍

About the speaker:‍

Michael has been working for Bosch as a software developer for the past eight years now and is currently working in the XELERATOR. He is responsible for the development arm of the company which is why he feels able to talk about this topic.

‍Intro‍

When preparing for this talk, Michael thought a lot about what he could do to provide value to the audience as there is already very good material on microservice architectures. So, he rather wants to talk about questions that go into architectural decisions and the process applied when making those decisions. Before he starts a little disclaimer: this talk will mainly represent Michaels’s opinion on the topic and is based on his experiences in the field. Everyone is free to disagree with him as some of his colleagues at Bosch do which he thinks is great because disagreeing is what drives us forward in learning. Looking at the title Michael also warns the audience that he will make some strong statements during the talk. This will seem very black and white although the reality is much more greyscale in most cases.

‍Why microservice architecture?

The first question Michael wants to talk about is: why should we care about architecture in the first place, why are we even doing that? So, there is a lot of good practices, and best practice in software development like CI/CD, testing strategies, deployment automation, version control Git and of course architecture. But at the end of the day all the tools serve one purpose, and one main purpose, which is to save time. Because at the end of the day we want to get from A to B as fast as possible, so essentially the question we should ask about any architectural decision is: Does this help us to get from A to B faster – in the short run or at least in the long run, because for many architectural decisions that actually makes us slower right now but it speeds us up in the long run. And that’s of course fine but it must speed us up at some point. Of course, it’s a bit of a simplification, but one that works.

Before we get into microservices, Michael wants to talk about trees. So let’s imagine you have this wonderful beautiful tree in your garden on the lawn. However, your children just decided that the lawn is now their soccer field, and the tree is in the way, so of course, it’s your job to get rid of this tree. So, what do you do? Well, you are going to go to your garage, you’re pick up your chainsaw, it’s a beautiful day, you cut down the tree, it’s fun, it’s easy, it goes smoothly, end of the day the tree is gone and you’re very happy! That’s how this should go.

However, let´s say the topic is a little bit more difficult, maybe it’s more than one tree, maybe the trees are a lot bigger, maybe they’re just next to your neighbor’s house, you have to work really carefully. If you set out with the chainsaw and try to cut on this tree, it probably looks like what this guy is doing, well Michael is not an expert at cutting down trees but for him that doesn’t look easy anymore, it looks kind of risky and a little bit difficult. Maybe it would have made sense in this scenario to bring heavier tools to the job, heavier equipment, maybe, you know, a lift so that you can reach the branches easier, or even one of these big trucks that can just immediately cut down the tree. However, if you bring in the heavy tools, if you bring in the heavy equipment – well, you probably don’t have that at hand, you maybe have to rent it, you have to handle the logistics, you have probably done the work on a specific day, you have to align with the neighbors. So suddenly cutting down the tree gets from „we just do it quickly“ to a really big overhead that you have to do before you can even start cutting down trees. And that’s actually what microservice architecture is. So, if you apply this architectural pattern you must be aware that you are bringing in the heavy guns. That can make sense in a lot of cases but if you think again about the trees if you would do that for the small tree in the first scene that would be crazy, at the end of the day that does not help us to get faster from A to B, which is essentially what we want to be doing.‍

The pros and cons 

Let´s try to apply this reasoning to microservice architecture. Michael will go over some pros and cons from his perspective.

For the pros, microservice architecture does enable easy scaling, especially if you only have to scale single components of the architecture. It’s good for working in multiple teams on the same product and it’s easy to reason about and the sense if you have for example a lot of interfaces to other products and you must talk to other architects, it makes it much easier to exchange with other architects, to see what goes where, which also helps a lot in troubleshooting down the line.

And it has cons, it’s a more complex architecture in general, you know, you have more moving parts, which makes it often more expensive, it’s often more difficult to run because you know, you have to monitor all of the microservices, you have to handle deployment, you have to know what’s running where, and it requires more discipline to maintain in the long run. Because also if you’re doing changes you have to go back to architecture, and see what goes into which microservice, you have a risk of functionality being built two times in a different way, in different microservices. So just overall more complex.

Also, if you look at the literature on the topic, there’s usually a long list of pros for the microservice architecture and a very few cons. However, that’s actually just one con which is additional complexity. The essence here is we want to get from A to B much faster and in that scenario, complexity is the enemy. That’s why we have to be really careful about this con and not default to microservice architecture in every case. So for actually a microservice architecture to be worth it in the long run, we have to make sure that the benefits actually apply to our software product.

Thank you for reading this article. If you are interested in hearing Michael himself you can do so by following this link: Free Developer Talks & Coding Tutorials | WeAreDevelopers.