 My name is Satie. I'm from McKinsey Digital Labs. I manage the practice at McKinsey for the digital labs. So I'm here today to talk about microservices but before I do that let me just ask a couple of questions. So how many people here are developers? Put your hand up. How many people here manage developers? How many people want to be managers or leaders in the future? So this topic is going to be kind of more about thinking outside the browser and more about a topic that's at least coming up a lot in the conversations I'm having with people and it's really going to be centered around some of the implications of microservices. So we're seeing a lot of traction. A lot of the guys in the West Coast are doing this. I'm not going to go into the technical details but what I am going to go into is some of the implications and some of the things that you need to know especially on the people side and the talent side but also on the challenges that you need to overcome if you want to if you want to embrace microservices. So a lot of today I heard isolation, scale for the app and the frameworks or the same thing applies across systems. You want to design for isolation, you want to design for scale and hopefully I'll touch on that. So I'm going to do this in about five segments. I'm going to start with just a little bit about microservices and then talk about what they are, who's using them and how. Then I'm going to talk about why it's a relevant topic for people like me. So people who advise companies on how to fix some of the problems they're having and then talk about what it takes to be successful with microservices. So what I'm not going to do is say microservices are perfect, they're the next best thing because if I say that another two guys at the front will yell at me. We keep arguing over when to use microservices and when not to. So that's the five segments. So let's get started. So life according to Google in the last 12 months, so the scale is not on here so it could be very small numbers anyway. But there's a lot of attention and increase in globally, not globally, at least on Google trends about microservices. So we're seeing a sharp increase in people talking about it and certainly in the last three months or four months pretty much every organization I've talked to has this topic has come up. People want to go fast, people think that what they have is going too slowly and many people think that microservices is the answer. So it is part of the answer but not the full answer. So how's it relevant to this conference? So quick scan on GitHub, I just searched for microservices. So the top two languages at least on GitHub today for what it's worth. JavaScript comes up in the top two way above most of the other languages. So hopefully it's relevant. It's even more relevant because there's nothing happening in India. So at least if you're sitting on a browser, just search for microservices. So the next time I do this search for Google trends, you'll see a spike in Bangalore. But a lot of activity in the US and the UK. And then the other interesting thing that I'm noticing is I looked at the documents that Google trends referred to. Those are five or six documents that have been very popular in the last few months. And I did a word cloud of them. So the thing that the interesting thing that I got out of the word cloud is there's no vendor names in here. Which I think is really cool. Unless you're a vendor here who's trying to tackle this market. But the one name that does come up all the time is Amazon and AWS. So we've got Lambda here. But other than that, there's not much in terms of vendors who are kind of in this space. And I expect that if we do this talk this time next year, they're probably full of IBM and Microsoft and a whole bunch of others. So far it's pretty cool. But a lot of the community doing a lot of the heavy lifting. So what are microservices? So here's what Wikipedia has to say. I'm not sure how many people can actually read that. But effectively, tiny pieces of software. Each independent of each other. Each somehow communicating with each other to get something done in a coordinated and orchestrated way. But the key thing is they're all small independent tasks. Lots of small bits. Here's just a comparison at least of just another way to look at it. So one of the things I want to highlight is that we use the word monolith. And it sounds bad when we say monolith. I don't know why. But it sounds like a bad word. It's really not a bad word. Monolith just happens to be a way to describe kind of a Rails app or a Node app or a Play app. It's really a good way to get started with something. You don't want to go straight into microservices. And so that's a monolith and that's microservices. So that's just another way to think about it. Monolith is one whole piece. You deploy it together. You build it as one. You change it as one. Microservices, you just blow the thing up and make lots of small changes. So no talk about microservices is complete without referring to Mike and Fowler. Here's my Mike and Fowler slide. It says the same thing. The left hand is monolith or a conventional app on the right side. He describes microservices. I should also at this point mention Fred George, who coined the term microservices, but I don't have a slide for him. But in terms of just where it originated and where it comes from, I think the first, at least the first recognition that I had of microservices really came from Bezos in 2002. So 13 years ago, he was thinking about small units of software. And this is his email to his team. I think hopefully you can read this, but the last one was interesting. So how do you get your organization to adopt what your CEO wants? You just tell them they're going to be fired. If they don't do this. So it worked for Amazon. So the key thing is, you know, it's not a silver bullet, right? So I won't repeat Hewlett's joke from earlier, but it's not an all or nothing. It's not like you have to go to microservices. It's not like it's a monolith versus microservices. It's a journey from somewhere to some microservices. At least that's what I've seen that's been most successful. It's an evolution. All right. So who's doing it? And let me give you some examples. So most of my examples are from the West Coast and London, actually. So when you saw the original slide of microservices at the UK and the US as the two places where all this is talked about. So Halo originated the UK taxis, think Uber. And they have moved to a services based architecture over the last two or three years. They started off with a Ruby on Rails application. And they went to this and they built the whole thing in Go, a thousand AWS instances, but 200 plus services right now. So they think they'll get to 230 or 240 by the end of this year. And what they're doing is just as services get too big or get too complicated, they kind of just split them up. And here's a kind of visual. This is how they kind of share what they're doing. And when I was talking to the guys from Halo, basically they had the classic problems, right? They had the code base was getting very big. They needed to go fast rooms and do features much more quickly. And the developers were stepping on each other's toe. You have 100 developers changing one code base. There's a lot of changes to deploy and test every time you want to deploy something. And it was getting frustrating for them. So they moved to this architecture. And as a result, 30% less operational cost. But it certainly wasn't 30% operationally easier, I can tell you that. But the cost went down. They do at least 10 to 20 deployments a day of different pieces. Not the whole thing. They can now deploy lots of bits and pieces. And they can actually focus on the business priorities much, much quicker. Because they only need to make changes in small predefined areas. So it's been hugely successful for Halo. Another obvious one is friends at Netflix. So at least if you look on Google, if you search for microservices, you'll get a whole bunch of videos from Adrian Cockroft at Netflix. Let me show you a visual of how they break up their services. I think they have 600, the last I heard at Netflix. So this doesn't happen overnight. It doesn't happen in the year. It probably happens in a couple of years, right? And if you take a look at this, what they do is every time something becomes too big, they start breaking up. So it's not something you design upfront. It's something that you evolve. Next one, over to New York this time. So guilt does kind of flash sales. And they have a sale at 12 o'clock noon every day. And so at 12 o'clock noon, that's the spike that happens. So they need to optimize for that 15 minute, 20 minute period. Rest of the time, they're kind of like, there's hardly any traffic. And what they want to optimize for is the first two or three things they're logging, registration and browse. Like they didn't need to scale the whole application at that time. Because a number of orders were still manageable with the infrastructure they had. They couldn't scale to meet the login requests. And so this is what they started with. Good old memcache. This was three or four years ago. And now they're at this. So about 160 services. Again, an evolution. Not an overnight win. Next one, I'll give you an example of this is basically, I talk to these guys a lot. So this was a node application. So these guys have about, I think about 60 developers in node building what they call the organized monolith. So they had services that had really good structure. They had lots of great end points. But they were going slower and slower and slower. And they wanted to go faster, faster and faster. So they kept hiring people to try and go faster. But every time they hired a bunch of people ended up going much slower. Because everyone was stepping into each other. To understand the application they were building, they were building a platform. Every developer who was coming onto the team took weeks to learn about the whole application. How to deploy it, where everything lived. And they started that journey to microservices. So on yesterday, they actually was the first time they just started splitting the application up into small pieces. And the way they did that is they first launched, yesterday they launched their development pipeline. So they can now take their monolith from the Mac all the way to production. With a couple of clicks. And now they can start breaking it up into smaller pieces. And this is going to be their runtime environment. So why did all these companies do this? So here are the core reasons. So the first one is that just the size of the code base makes a big difference on how fast you can go, how many people can work on the same thing at the same time without stepping on each other. So how many folks here kind of have a large code base that they're currently working on? A few? How many have multiple development teams that are coordinated in terms of the projects that they're running on? It's all the same people. Ownership, right? So when one part of the application breaks because something else changed and somewhere else, how does that coordination happen? It's probably a ton of emails. Or a ton of finger pointing usually. It wasn't my piece of code that broke it or something from another team. And if you want to make one change, you have to build, test, deploy the whole damn thing. And technology stack limitations. You want to optimize for one area with maybe a different type of database than what's holding most of the data. But you can't do that because you need to use your one database. So these are the things. So if you're having these kinds of issues, if you're seeing these patterns in your development organization or your products, there may be at least some elements of what you'll hear about today is kind of relevant for you. So that's kind of who's using it and why they're using it. The next section is really when I talk to clients, and this is what we definitely talk about, which is kind of these five topics. And these are all people related. So if you move to microservices, what you'll see immediately is an uptick in the happiness of developers. Not when they first have to break up their application because they've spent months crafting it. But what we've seen a big change in is things like developer onboarding. So if you have microservices, and you have an intern start, the good idea to give a very simple service with someone to work with, and he can pick that up in a day. And if you're in the microservices environment, everything's going to be automated. Because I'll talk to you in a minute about, you know, to be successful in microservices, you need to be able to click a button from your developer machine all the way through the different environments. And you shouldn't have to manually touch anything. Right? So we went from a situation with ADP, where we can go from taking weeks to do developer onboarding to get them started on a microservice on the same day. That's a kind of kind of change we need to see. The other one, this was kind of probably the most important one, is you can distribute your teams. So if you have a microservices-based architecture, and you've got a few hundred services with about six or seven teams, each team can be in a different place, can have different levels of skill even. And so if you're thinking about development teams that go from India to the U.S., if you have clear boundaries from your services, people in each of the locations can actually drive autonomously, much more so than they ever had before. And think of the skills you need. If you have one monolith node application, you need a lot of good developers to manage that. You can't have junior developers starting and giving them full access to the full code base. Services really allows you to change the way you think about your people model. Autonomy is key. The other thing that happens is, I don't know how many people recognize this, but Conway's law when, you know, if your organization is split between database people and test people and infrastructure people, your architecture just looks like your organization. So how many people have seen that happen? Okay, so this is another benefit of this, right? This prevents that from happening. And then the next one is what developers like the most. Stack freedoms, right? New tools, new gizmos. I want to learn how to do that. So if you have a small microservice, that's a few hundred lines big, and you want to go test out new technology and play around with a new stack, long as you've got everything else in place, you can actually do that. So what happens in places like enterprises, right? So this is where I have the most pain talking to people who have. So one thing that we've done really successfully is bridging legacy IT with new front ends by just installing a layer of microservices in the middle. So you can actually build them very quickly. They're basically the interface into the new front ends. So typically the front end is in the cloud, the back end is still in the enterprise IT structure, and you can build a small piece of middleware using microservices very quickly to plug the gap. So we've done that very, very successfully. And the last one, this is a good one. You can actually have different governance models for different services. So think about it. If you're doing payments and you have PCI compliance and you have PII and all that stuff, only that service needs to go through a different governance process. The rest of the services, the rest of the application doesn't have to go to the same rigor that you might want to do with that particular service. And so we've seen situations where if you've got a payment service and a search service, the payment service needs a completely different governance structure, completely different SLAs. You might be relying on a third party, but the search one you might have complete control over and you can deploy as frequently as you like. So really it changes. It's not like one size fits all. So I think that's another massive benefit in terms of microservices. So if it's all that good and that easy and that powerful, why isn't everyone doing microservices? Who wants to do microservices? It's the same guys that have big code bases. So it's really cool and I think it's fun to get up and running. But to be successful, to have a powerful set of microservices based architecture, there's a lot of things. There's at least five things that you need to get really right. And first one is continuous delivery. So if you don't have continuous delivery, I would not try and even start doing microservices. So if you imagine deploying one application being hard for your organization, try deploying 50 services. Because if one application is a pain in the ass to deploy, you have to multiply that by 50. So you really need to think about how you're going to do continuous delivery. You need to have separate repos for everything. Everything has to be a click of a button. Everything has to be audited, tracked. Everything has to probably be containerized and so on. So the deployment pipeline is absolutely critical. That's the first thing we did or ADP did when they were moving to microservices. The second one is immutable infrastructure. So you just want to basically have infrastructure that's divided into data that you care about and everything else needs to be able to blow it up. So if something's wrong with your infrastructure, what you want to do is not try and fix it. You want to just replace it. And what we've seen is pretty much in every single microservice example I've seen, Amazon AWS is kind of a key part of it. So I don't think I've seen anything at scale without Amazon. For some reason, they make it nice and easy. So with this, you get much easier change management. So those of you who work in enterprise IT and have to go through a change management process and fill out forms about what you're changing, this makes most of that go away. I think you have to be in an environment in microservices where you have to embrace failure. Things will fail. Machines will go down, networks will drop, all that shit will happen. And you're doing it now 50 times more than you had before. So how do you solve for this? I like telling the Netflix story. So they've written a bot called chaos monkey. And the bot, all it does is it goes running around their services and starts switching services off deliberately. And so as a development team, as a microservice team, you don't know when the bot's going to hit you and turn off your services. So you just need to make sure you have things in place that can react to it. So imagine you're working in a place where someone's going to deliberately sabotage your infrastructure. But if you're resilient to that, then you've got a good setup. But they didn't stop there. They decided that they needed to go with the chaos gorilla. So chaos gorilla started turning off whole clusters of systems. So now instead of just turning off a service at a time that's making you redirect, it's just turning off whole areas of your data center. And they didn't stop there. They had chaos con. So here you're turning off whole regions. So you basically, at a flip of a switch, the whole region goes down and all the traffic goes over to a different region. So this is how seriously Netflix takes immutable infrastructure and designed for failure. And not that you have to go to this length, but you need to be able to embrace this type of operations. Third one, designed by contractor. This is really important. So if you don't have the discipline to define the contracts and promises that you're making to your callers and you're promising them that this API or this call will always return what they expect it to run, if you can't work in an environment where you can't keep your promises, then don't try and go to microservices. Not only do you have to keep your promises, you have to keep your SLAs, too. Otherwise you're going to just fall apart. If you're all relying on one service that's never up or constantly changing, it's not going to work. And the third piece of this, you just need to embrace backward compatibility and semantic versioning. Without that in place, you're going to blow up pretty quickly. And if you haven't used Swagger, it's a great collaboration tool for kind of getting going on these. Next one. This is critical, right? So instead of having one application that you're monitoring, you've got 50 apps and you've got different versions of them, you have to measure everything. And this measurement is not like, it's my servers up, right? That's not going to work in a microservices architecture. You can't just check whether, you know, you've got a health check and the service is up. You've got to figure out where the message is flowing. You have to figure out that if I have 400 logins, I expect 400 of these other things to be present. You need to have checks and balances that everything is working as you planned it. You have to know what to do when a service stops responding. There's lots of tools and techniques to do this, but you need to measure very, very differently. Here's what, I think this is Halo, have this. So their operations team, all they need to monitor is all these services across the bottom, but they also have to make sure that the red line never gets anywhere near the green line. And the tracking messages, they're not tracking CPU, they're not tracking memory, they're not tracking network speed. They're tracking the functionality of the application. And then here's another example where this is more sophisticated, right? So this is comparing ad items messages that are going through the system to the sales tax messages. And so you see that thing, the two things at the top growing at the same pace. But what they're actually measuring is that the ratio between the two is one. So there's no situation where you add an item to a cart and you don't calculate a sales tax. So all these types of measurements are really important for Microsoft's implementation. And the last part is expertise. Don't try this at home yourself. We'll try it, but don't try it at work. You do need people who have done this before. The good news is that a lot of work that someone Netflix, Halo and all those Google eBay is a lot of its open source, so you can get started very quickly. But it is a big undertaking, right? So the upside is massive in terms of scaling people, scaling your infrastructure. It's massive for distributing software teams. It's massive for having really happy developers. But it comes out of premium. And so you need to be ready to pay that kind of premium. So you've seen kind of what leading edge companies do. We've talked about some of the benefits. I think if you have some of the challenges we talked about, this is a great path to go down. Remember, start with them on a list. Get some expertise. And it's a multi-year journey to get to the end state. But for many companies, the end state is completely worthwhile. So if you want speed and immediate business value, it's a good way to go. Thank you very much. So one last piece I just wanted to mention. Nothing related to microservices. But for many of us who have been with McKinsey Digital Labs for three or four years, and some of you who are here last year have heard this already. One of the things we sat in a room in Gorgown about three or four years ago was to say there's not enough JavaScript in India and Asia. And we wanted to do something about it. So the guys who are organizing this at least three years, maybe four years ago, said we're going to organize the largest ever JavaScript conference in Asia. And I think this year they've done it. So well done to the organizing team. So I think we do have some time for questions. It doesn't mean I'll give a good answer though. Actually it's not a question. You were saying that you don't see any blips in India, but might be just because of different names. In the company where I work for weeks to have separate services for email, OTP, SMS, it's just that we call them apps. And they all have their own, basically, or maybe just a question for you that by microservices you mean on the server something which is running on the own, on its own port as a separate process, right? Yeah, so I think so we'll get into semantics here. But I think one of the things that I look at when I look at microservices is that it's a standalone piece of, it's a standalone service, but it also goes all the way down, right? It's a shared nothing architecture. So it doesn't share an ESB, it doesn't share a database with somebody else, it doesn't share anything. So it can stand alone by itself. So if it doesn't, if it's not doing that then for me it's not a microservices. I think traditional SOA is probably more like it if you have an ESB or a big database that everything was relying on. Others might have a different point of view. Any more questions? Hi Sadi, you started MDL in McKenzie. So I see it starting and running a startup within a company, like an existing company. So can you talk about your ups and downs in this journey and then what will be your ideas and suggestions if you have to do it all over again? I hope I don't have to do it all over again. So I'd say the highs were high and the lows are really low, hence the gray here. I think in terms of, I think what's most important is, and the thing that's worked well for MDL is that we've let developers make nearly all the decisions, right? So I think everything we try and do or try and optimize for is the teams that are doing the work. So whether it's a developer or a product donor, an analyst, we really try and optimize for them and make as few decisions as possible up the chain. So I think the less I do, the better we are. So I think that's probably the lesson I've learned the most which is don't interfere with the people doing the work. And I think we've been super successful because I think we've hired great people, but we've let them run by themselves. Any other questions? Good. Thanks a lot. Thank you, everybody.