DOP 108: Why Do We Want to Use Microservices?

Transcript

Viktor: [00:00:00]
So when you say microservice, you do not know exactly everything about it. You do not know whether it's written in Python or it's written in Java. You don't know whether it's deployed in a container or directly on a VM or as a function in, let's say, Lambda. You don't know everything, but you know somethings already. You have a framework through which you can frame your next thoughts.

Darin:
This is DevOps Paradox episode number 108. Why Do We Want to Use Microservices?

Darin:
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can, and mix it with random buzzwords like Kubernetes, serverless, CI/CD, team productivity, islands of happiness, and other fancy expressions that make it sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often, since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. PS: it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farcic.

Darin: [00:01:23]
Microservices seem to be all the rage today. If not for the past three or four years. Why do we want to use microservices?

Viktor: [00:01:33]
If I would have to give a short answer, extremely short answer that's because we want to have small self-sufficient teams and for them to be small and to be self-sufficient, the code base needs to be small as well. You cannot have a small team that is working on a monolithic, huge application that realistically requires 100 people.

Darin: [00:01:54]
People do it all the time. Why can't we expect that?

Viktor: [00:01:57]
We can expect that and we have that, but it is very inefficient because then we spent just as much time waiting for something to happen. We employ a bunch of people coordinating the work of all those people and so on and so forth. We can have it, but it is very inefficient.

Darin: [00:02:15]
You gave a short answer of why we want to use it. Small teams, therefore should lead to small code, therefore should lead to maybe smaller hardware or different types of deployment strategies.

Viktor: [00:02:29]
Yes. There are a bunch of other reasons or to be more precise, a bunch of characteristics of microservices that are defined due to those initial premises I said, right? If you do have a small self-sufficient team that is autonomous in how they work with an application with the microservice, that means that that service needs to be deployable independently from others. Because if you need to coordinate the deployment of your service with a bunch of other services, then you are not autonomous anymore. They should be independently scalable and they should have their own pipelines. It all boils down that if you want to be autonomous, then you need to be autonomous. Which sounds almost like a philosophical statement, but it all goes down from there. Autonomy means that you're independent from others, in general, not even in the context of microservices or software engineering. If you're autonomous, you can operate, you can do something independently of others.

Darin: [00:03:36]
Going back to the question of why do we want to, do you think application developers really want to have microservices or is it just that middle management thinks they want to have microservices?

Viktor: [00:03:48]
I think that both parties wants to have microservices or they want the benefits behind microservices. The problem is that it is often underestimated how complicated that is and especially how much work is involved in transforming something that you have right now into microservices. Whenever something is underestimated, then you do what you can and what you can often ends up being suboptimal that doesn't give you the benefits you hope for and at the end of the day, many of the teams that I'm in contact with or working with, they end up having some strange mixture of something they call microservices, but it is not really independent. It is not deployed from the rest of the system and so on and so forth. Then they start wondering, Hey, why did I just spend half a year making this thing? This is almost the same as what I had before, which is absolutely true. It is almost the same as you had before. What I'm really trying to say is that just splitting your application into multiple applications does not give any benefits. It just increases the cost of operating those split applications, if they're still interdependent. If you still need coordination between the teams, if you still cannot deploy each of them separate from the others and so on and so forth.

Darin: [00:05:17]
That's the pattern that I see is I have this big monolith that's basically an API monolith and I'm going to slice it all up into microservices and everything will be able to be scaled separately, but then the work isn't done to actually decouple those services.

Viktor: [00:05:34]
Exactly. If you accomplish what you just said, Hey, I can scale this independently. I split it into 10 pieces and everything stays the same as before. I still need to deploy those 10 pieces, but I can scale each of them independently from others. That is an improvement. Scaling individual pieces, and everything else being the same, is an improvement. Now, whether that's improvement that you want and whether that improvement justifies the cost and more importantly, and this is linguistical thing, whether you should call it microservices, is a separate discussion or separate question. I'm a stickler for having it clear what a term means, because it helps us a lot in communication. If I tell you, Hey Darin, we're going to use containers, you know what that means. Now, if I say we're using containers, but realistically we are using VMs, then the rest of the communication is going to be completely off topic, because you're still thinking about containers because I said so, and realistically, that's not what I'm doing. I kind of dislike that people go to extremes and say, Hey, nobody should have a monolith. That's silly. Or people say, Hey, nobody should have a distributed monolith. That's silly as well. There is time and space for almost every architecture. The problem is when you say microservices, then in my head, I already passed an hour worth of conversation and we can communicate based on that assumption. Hey, you're having microservices. If you're not having microservices and you just say that you do, then we have a problem, then we cannot communicate effectively anymore.

Darin: [00:07:14]
Well, I'm going to use what just happened. You said containers. The first thing that I thought of wasn't Docker or Kubernetes. The first thing that popped in my mind was LXC and when you said VMs, I thought, Oh, Yeah, that's a container too. Container is a very bad word to use because it means so many different things and I believe the same thing is true of a microservice because that could be functions as a service. It could be whatever you consider a good microservice to be, or it could just be a hacked up distributed monolith.

Viktor: [00:07:46]
But that's the thing. I don't think it can be hacked up distributed monolith.

Darin: [00:07:51]
People will call it that.

Viktor: [00:07:53]
Exactly and then that's a problem. Now, I think you're right in what you mentioned before, like, Hey, it could be functions as service. Of course. Yes. Functions as a service counts as a microservice because can it be developed by a relatively small team? Yes. Easily deployed in apparently from the rest of the system? Probably. I'm being cautious now saying probably. Let's say yes for the sake of argument and so on and so forth. So yes, a functions as a service has the properties of microservices. So when you say microservice, you do not know exactly everything about it. You do not know whether it's written in Python or it's written in Java. You don't know whether it's deployed in a container or directly on a VM or as a function in, let's say, Lambda. You don't know everything, but you know somethings already. You have a framework through which you can frame your next thoughts. But it's not distributed monolith because distributed monolith is just a monolith that is split for the sake of being able to scale or maybe a few other things, but it doesn't have characteristics of microservices

Darin: [00:08:56]
So you've already called it out at the very beginning of, why do we want to use a microservice? Let's define microservice for real. Let's get concrete 2021. What is a microservice today? Or what should it be?

Viktor: [00:09:10]
Okay, let me give it a try. It is a loosely coupled application organized around business capabilities, owned by a small team and deployed independently from the rest of the system.

Darin: [00:09:22]
Is that your final answer?

Viktor: [00:09:24]
That's my final answer, which I might change in two minutes.

Darin: [00:09:27]
Yes. Survey says, no, you're partially correct for the next 10 seconds. I think that's the problem is why do we want to use them? We want to believe that we can have independently scalable architectures. Our hardware and infrastructure people will argue with us about that.

Viktor: [00:09:44]
Independently scalable because of the speed and because of the cost. Now let's say that you have an application that is huge. Let's say that a single replica of an application needs 10 gigs of RAM for the sake of discussion. Now, let's say that you want to scale it up to two replicas. How much RAM do you need? You need 20 gigs of RAM. 10 times two. Now what if and not what if almost certainly actually only some parts of that single replica was a bottleneck. Maybe that's a logging mechanism. Maybe that's a part that retrieves data from a database. Well, it can be many things, but it's never that all parts of a huge application are equally under heavy load. That never happens. Some part is under heavy load while some other is not. Now, if I split that huge application into two applications and I'm going easy now and each of them needs five gigs of memory, which in total is the same 10 gigs, then when I need to scale up identify, okay, so this part, the left part needs to scale up. I need two replicas. What is the total of that? That's two times five, 10 plus five for the other one. That's 15. You just saved five gigs of RAM when scaling and on top of that, it's probably going to be faster and quite a few other things.

Darin: [00:11:07]
Why else would we want to use microservices?

Viktor: [00:11:10]
Apart from scaling?

Darin: [00:11:11]
Apart from scaling.

Viktor: [00:11:12]
For me, the most important thing is relatively small team. I never, ever, ever saw a team of hundred people working effectively together. I don't think that there is such thing.

Darin: [00:11:25]
Is there a magic team size? The two pizza team that Amazon was so, you know, widely pointed at for, but I don't know that cause I could eat two pizzas by myself, so I know I need more than myself.

Viktor: [00:11:39]
Yeah, but also you're in US. Pizzas are very big over there. I'm not sure if you can eat 2 pizzas yourself. Maybe if you come to Spain.

Darin: [00:11:47]
Okay.

Viktor: [00:11:49]
but let's say that anything between one person and 10 people sounds like a reasonable size to me. Realistically, you would want to have the smallest possible team as long as that team is capable of managing all aspects of an application. Now that the team ideally could be one person, and then you would say, Hey, one person is not enough because if that person leaves and nobody understands what's going on, so let's say two people. But then when we say two people, it is unrealistic for two people to know equally everything about everything. So we need additional people to add to the mix. You might be very good with coding and somebody else might be very good with the system and can be better than you understanding, let's say that you're deploying to Kubernetes, better than you understanding Kubernetes and then some third person something else. So we passed the point where a single person can know everything there is to know about an application, all the aspects of the life cycle of that application. So it cannot realistically be only one or two people, unless it's very tiny project of a company and then we get to some numbers, like five, six, seven, you know up to ten. I would guess it's acceptable. Above ten, you can say, okay, now actually I have too much duplication of everything. Having one or two people who are equally skilled at something is okay. It's good. It's cooperation, but then if you say, Hey, I have hundred people in my team or not in my team. I have a hundred people working on an application, then first of all, almost certainly those hundred people are not reporting to one person. Let's start with that. What are the chances that you will not split those hundred people into different groups, like testing department and developing department and operations department and what so not and then you're already introducing conflicting objectives because different departments have different objectives. Reporting gets messed up. Nobody really knows what's going on because they're all concerned about different aspects of that application. We have handing over. We have blame. The list continues. Let's put it this way. Most of the companies, at least that I know of are in one way or another in the process of breaking the silos and there is no better way to break silos but by having a team dedicated to a single application and you cannot have a manager who has more than, let's say 10 people reporting to him or her.

Darin: [00:14:24]
That sounds like a problem and I think we'll visit that up on a different episode because the people problems of this are huge. We've talked about the why of we want smaller teams, decoupled processes. Why else do we really want microservices? Like there has to be a reason. It's not just because somebody wrote a blog post about it or that we're talking about it today. Is it an optimal way to do application development in 2021?

Viktor: [00:14:52]
I think it is for most of the use cases. If we go through the, what is the name of the highly efficient teams or something like that superheroes mentioned in DORA, we can see that most of the teams that are extremely successful, adopted it already and adopted it effectively. So we know from the experience of others that that kind of works. Doesn't work always, no. Here is the most important thing. Is it good to break your application into microservices? And the answer to that is very often, no, but if you start from scratch, then what's not to like having a team in charge of an application and we already established that the team is small number of people and not huge.

Darin: [00:15:40]
With greenfield, you've got constraints, even though you don't really have constraints in theory with greenfield. If you put your constraints on yourself, no, I can't share a database with this other application. No, I can't look in the memory space and pull things directly out of memory from this other application like you would with monolith, it seems like it's actually more work. It's actually going to cost me more money to run. Again, these are problems. I'm going to hold off on those, but the whys seem to be good but I'm still trying to figure out really why do I want to do it? If I could sit down and just write a monolith, why do I want to have 10 microservices if one monolith is going to work? Is scaling really it?

Viktor: [00:16:19]
How many people work on that hypothetical monolith?

Darin: [00:16:23]
I don't know. 10 or 15.

Viktor: [00:16:25]
Okay. Those 10 or 15 people, that might be already a big number to have a single application, so you might want to go with two, right? And most likely those 15 people are already split. They're already working on multiple applications, most likely. What I dislike is when I see, especially with smaller companies, startups, is that everything needs to be a microservice in terms of splitting it into such tiny pieces that you end up with 10 people having 57 services. That's potentially bad. I'm not really in the group of people who thinks that microservice should be extremely small. I don't even like the name microservice. It kind of alludes that it's something that is almost always very similar to functions. I don't believe that that makes sense. I'm yet to see a team of 15 people that works on a single application only.

Darin: [00:17:19]
So we've talked about the why. Scaling is one. Smaller teams, which in theory should lead to faster shipping

Viktor: [00:17:27]
Yes.

Darin: [00:17:28]
in theory, as long as you don't have too much big A agile ceremony.

Viktor: [00:17:32]
Here's the biggest problem of the real world implementation of what people call microservices. You have that team that is about to ship something and then that's something cannot be shipped because something else needs to be shipped at the same time of that something. Now, if that problem does not exist and that problem really is called in a way distributed monolith, but if that team can ship something, as soon as that something is done and start working on something else without waiting for some other team to finish their work, then you can probably already see that each team goes as fast as they can. So it's kind of, Oh, do you really want to wait until the slowest link in the chain is finished? Let's put it that way. If there are 10 of us working on 10 different aspects of an application or 10 different applications that are all dependent on each other, then we are going to ship it to production when the last one of the 10 is finished and that is inevitable delay.

Darin: [00:18:38]
So the reasons why, and that we keep going back to problems, we're going to have a whole episode about problems. But the reasons why we want to use it should make management, happy. Smaller teams, creating smaller applications, being able to deploy them faster. That's the reasons why we want to use microservices. Again, we'll deal with the problems later.

Viktor: [00:19:01]
Okay. Then remember when you talk about problems to repeat what you just said about management being happy, because management is not happy about it at all.

Darin: [00:19:10]
So why do we want to use microservices? As an application developer, I don't want to look at a 100,000 line. Oh, wait, let me ask one question before do that, because that triggered something because this could also go into a problem. Should microservices live in their own repositories or should microservices be in a mono repo?

Viktor: [00:19:28]
For 99% of us, it should be in its own repository. There must be a good reason that I am yet to find why it should be a monorepo.

Darin: [00:19:38]
I don't want to go any further than that other than I wanted to bring it up. Because that's sometimes an argument that I hear because application developers don't want to have a bunch of repositories that they have to clone. They will only have one repository. And to me, that's just lazy.

Viktor: [00:19:52]
Yeah and also that poses the question, okay. If you, as a developer, you don't want to have 20 repositories that you manage, then.

Darin: [00:20:01]
folders inside of a single folder.

Viktor: [00:20:04]
Exactly repositories are folders at the end of the day, from your laptop perspective, right.

Darin: [00:20:09]
Yes. Okay. That's a problem that I'll also try to remember to bring up. Why do we want to use them? Speed, potential money savings,

Viktor: [00:20:17]
Time to market

Darin: [00:20:18]
Time to market

Viktor: [00:20:19]
speed, I guess.

Darin: [00:20:21]
Yeah. Okay. Why do you think that we should be using microservices? Comment over in the Slack workspace, under the podcast channel and let's talk about it.

Darin:
We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and the link to the Slack workspace are at https://www.devopsparadox.com/contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at https://www.devopsparadox.com/ to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.

DOP 108: Why Do We Want to Use Microservices?

Show Notes

Hosts

Darin Pope

Viktor Farcic

Links

Rate, Review, & Subscribe on Apple Podcasts

Signup to receive an email when new content is released

Transcript