Tech Talk: "Why you shouldn't build a microservice architecture" mit Michael Eisenbart von Bosch

Tech Talk: "Why you shouldn't build a microservice architecture" mit Michael Eisenbart von Bosch

Hello everyone, my name is Michael Eisenbart and today’s topic is going to be: “Why you shouldn't build a microservice architecture”.

But before I start with that, maybe a little bit about me and where I’m coming from, before I give bad advice about architecture. So I’m working for Bosch and I’ve been working for Bosch for about 8 years now, in the field of software development, currently I’m working in the XELERATOR. We are the digitalization organization for our power train business and in that capacity we want a global infrastructure together with our partners, connecting more than 1000 manufacturing lines worldwide and a lot of other data sources into a big data ecosystem. To that end we build and run seven software products. That’s all actually built and run. So those are DevOps teams that are also in charge of operations and to that end we are 40 developers currently, which are located in 7 countries and one of the teams is actually located in the beautiful city of Linz, where I am today.

Personally I’m responsible to this development arm of our organization and that’s why I feel that I can talk to you about this topic.

So when preparing this talk I was actually thinking a lot about what I can do to provide value to you as a listener because there is, you know, very good material on microservice architectures, there are very good books on the topics. So I rather want to talk a little bit about questions that go into architectural decisions and talk a little bit about the process that we apply when making those decisions and hopefully that can apply to something you are going to do in the future. So before I start, a little bit of a disclaimer: so of course this talk mainly will represent my opinions on this topic, my experiences, and I do not have a lot of facts and figures on that and of course you can disagree to many of these points and also many of colleagues of Bosh do disagree which is great because obviously that drives forward how we learn. And also I’m going to make some strong statements during the talk, including the title. Of course that’s very black and white, while reality is much more greyscale in most cases. Also if you disagree with some or all of my points, also great, as I said before, I’m very happy to hear about that, so leave a comment or reach out to me. And the final and last point here is a lot of what I’m going to talk about is essentially common sense, which I believe is probably the most important tool in the toolbelt of a software architect.

So the first question I want 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, 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 of 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 has to speed us up at some point. Of course it’s a bit of a simplification, but one that works, so just stay with me.

So before I get into microservice architecture I want to actually 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 little bit more difficult, so 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. So if you set out with the chainsaw try to cut on this tree, it probably looks like what this guy is doing, well I’m not an expert at cutting down trees but for me that doesn’t look easy anymore, it looks kind of risky and a little bit difficult. So again, not an expert on cutting on trees, but 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 do the work on a specific day, you have to align with the neighbors. So suddenly cutting down the tree gets from, you know „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 have to be aware that you are bringing in the heavy guns. That can make sense in a lot of cases but if you think again on the trees, if you would do that for the small tree in the first scenario 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.

So let´s try to apply this reasoning towards microservice architecture. So there’s a lot of good material on that kind of architecture, so I’m not going to go over all of the pros, all of the cons, I just pick the main ones from my perspective to illustrate my point, but definitely go on and read more about it if you’re interested in the architecture pattern.

So 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 have to 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 whats 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, 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 complexity.

Also if you look at 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 being worth it in the long run, we have to make sure that, you know, the benefits actually apply to our software product.

So lets go about the benefits one by one. So good scaling. Well, first question will be do we even need to scale? So for us, we are building a lot of applications for internal customers. Bosch has a lot of employees all around the world, but at the end of the day only roughly a third of the employees is awake and working at the same time. Not everybody is going to use the application, so a count of concurrent users is actually maybe a few hundred to a few thousand, but we are never going to go to millions of users so why bother scaling to millions of users? That’s not going to happen. And also if you need to scale, well ok, you can just deploy two servers and a load balancer and you’re going to be perfectly fine. So that works also with more classical architecture approaches. So the question here would be: ok do I actually need to scale and if so, does it actually make sense for me to only scale a component? If not, well, than the benefit does not apply. It’s good for multiple teams. Well, do we actually need to build the product in multiple teams. So for me we always try to build – ideally – a product only in one team because it’s essentially the most efficiant way to work because once you have multiple teams, you get overhead in coordination – and remember, we want to get from A to B as fast as possible – and multiple teams can make us slower in that actually, because you know, we get coordination overhead. So ideally we want to work with one team and then of course the benefit will not apply. Last one, easy to reason about. Well, do we need to reason about architecture? If your application is completely insular and you do not have any interfaces to other applications, you’re not going to talk to other architects, you’re not going to reason about it, then that’s just much less necessary.

So this brings us to a simple decision. You’re going over these questions and maybe you’ve said ok, none of the benefits would actually apply to me, well then you shouldn’t go with microservice architecture. If you say, well, most of the benefits do apply – great! So you should definitely keep asking questions and go to the fullest of benefits and see if it’s actually worth it. Because in this case I’m focusing on the benefits because for the cons, the additional complexity, that one is guaranteed. So if you go for that kind of architecture pattern you will have the additional complexity, so you have to really make sure that the pros apply to make it worth on the long run. Again, you’re bringing in the big guns and you should make sure that you’re actually falling the big tree and not the small tree. So that’s my general gist around this architectural process that we go through.

And also a little bit of a surprise fact, actually most of our products are running in a microservice architecture! So I am a big fan of this architecture in general, but you should be definitely careful in considering if it’s the right job for the tool. So one last point – let’s say you go as an architect and you’ve put in a lot of work and you ask all of the questions and you have a really good feeling about this and you’re getting ready to deploy to production and then the production deployment looks like this – it’s a complete disaster. This is going to happen and there is nothing that you can do about it at the end of the day. So there is no such a thing as a correct architecture, there’s only different degrees of wrong at the end of the day. And the idea here is, what I want to encourage you is, you know, you should inform yourself, you should read the book, you should listen to the talks, but don’t overdo it! If you sit down for six months working on an architecture, essentially you’ve already lost six months getting from A to B and you’re never going to get the time back and for us it’s actually a no go for an architect to not work on the implementation of the product because that’s where you actually learn what your architecture does in production and that’s how you learn how to improve it. And so it’s really important to get into the production fast even if the architecture is not perfect because you cannot get it perfect anyway. So really I want to encourage you to try things out and be also courageous in terms of deploying the architecture. And also don’t fall in love with the architecture and don’t be afraid to change it down the line.

So that’s all I’ve got for today. Again, my name is Michael Eisenbart, if you want to reach out to me, you can connect on LinkedIn or Xing and whenever or wherever you’re listening to the video I wish you a very nice day, goodbye!