The Problem With Microservices

microservices is probably the most popular architectural approach today it's extremely effective it's the approach used by many of the most successful companies in work in the world particularly the big web companies as a result i see lots of organizations and teams attempting to adopt it or so they think in reality they often miss both the value and the costs of micro services and end up doing something that really isn't micro services at all and so kind of doing micro service the micro service idea something of a disservice they don't gain the benefits that they were looking for very often so what is the problem with micro microservices [Music] hi i'm dave farley of continuous delivery welcome to my channel if you haven't been here before please do hit subscribe and like if you enjoy the content in this episode i want to explore the problem with micro services and particularly while this very valuable architectural idea is probably not quite what you think it is it's simple right microservices is all about small service isn't it no not really the first problem is that microservices is a distributed systems architecture and what however you wrap it up distributed systems are way more complicated than non-distributed systems there are all sorts of problems that you just automatically buy into when you start distributing computing across multiple different devices one of the things that micro services are not are not are not services with simply a rest api that's another thing that's rest it's it can be implemented as a micro service or not rest may be a useful technique in implementing micro services or not there are there are many different ways of approaching this but a restful api does not define a micro service and all services are not micro services services as an organizing principle for software systems has a very long history we'll talk a little bit more about that later on the defining characteristics of microservices are that they are small as we've already mentioned they're focused on accomplishing one single task they're aligned with the bounded context in the problem domain they are autonomous independently deployable and loosely coupled let's talk about each of those ideas in a bit more detail so what does small really mean everybody asks this question and it's kind of an obvious question from the name right micro services so what does micro mean there is an answer that comes from the early pioneers of microservices which is that a micro service fits inside of james lewis's head james was one of the people that first popularized the idea of micro services he along with martin fowler wrote the first article that was published i believe online or at least the best known article that describes them in more detail and james as you can see from this picture has a reasonably large head he's a smart guy so a fair amount fits in his head but the idea is to make them understandable to compartmentalize a problem so that we can deal with it and understand what's going to happen um a reasonable rule of thumb to try and figure out how small is small is or how micro is micro is to imagine being throwing away your micro service and re-implementing it how long would that take if you can do that in a few days or maybe a couple of weeks it's probably on the right kind of scale if it's going to if the idea scares you of throwing away the service and rewriting it from scratch it's probably too big the next in the list is focused on a single task and doing it well this is really about separation of concerns but at the level of the problem domain what we're really trying to try to express here is the idea that a micro service accomplishes one task when viewed from the outside now implementing that task may involved a bit more more concerns perhaps maybe you're thinking about storage or getting data from another source or something like that but from the outside the the service is going to be focused on accomplishing one task and achieving that well the next in the list is aligned with a bounded context most teams miss this idea and it's an important one a bounded context is an idea that comes from domain-driven design the fantastic book written by eric evans which describes modeling the problem domain as an approach to designing the software and one of the things that eric talks about one of the key ideas in domain driven design is this idea of bounded content eric defines it as a defined part of software where particular terms definitions and rules apply in a consistent way this is a part of the problem domain where the concepts are related to one another and so it makes a a cohesive unit this is an important idea in lots of different contexts but in the i in this sphere of micro services it's a very important idea because those are the boundaries that we would prefer to align our services with and this is important for several reasons first if we break a problem a monolithic application say into a a collection of smaller technical services that doesn't really qualify as micro services they are not aligned with the bounded context and you're going to suffer from increased coupling between those components bounded contexts are kind of like natural fire breaks in the problem domain they are if we align our software with those fire breaks then it means that our system is going to naturally be less coupled because the problem domain is less coupled at those points and so it means that we can write cleaner interfaces to our services and have less chatty interactions between them one of eric's pieces of advice in the domain driven design book is that whenever you transition a bounded context a boundary then you should translate ideas information that crosses the boundary that means that every microservice should be translating its inputs and translating to its outputs in order for every interaction microservice should always make a break between these points we should make a significant distinction between the external protocol with which the micro service exchanges information with other parts of the system versus the internal representation of that service and the model within we need to really treat seriously the difference between the design of those apis those entry points into our services and our consumption of those apis from other services if you aren't using ports and adapters in your implementation of microservices you're probably making a big mistake we want to always be translating at these points the next in the list is that micro services are autonomous the teams that look after these micro services can make progress alone without the need to interact with other services or other teams i can change the implementation of my service without needing to coordinate with anybody or anything else this is the biggest value of microservices this is the thing that allows microservices to work in organizations that can that scale enormously but it's also the most commonly missed attribute of microservices what i see frequently is teams claiming that they're implementing microservices but testing the building testing and deploying all of those pieces together that's something else let's explore this idea for a moment of of autonomy service based design is not the same thing as micro services service based design has a long history it's been around for a very long time if you'll forgive me i'm a bit lazy and i haven't looked up the history of service based design so i'm going to do this from a personal point of view and tell you my interaction with it i've been building distributed service oriented systems however you want to frame that for about 30 years now i started at the end of the 80s and 90s with my first foray into distributed computing i moved reasonably quickly in the early 90s into ideas like remote procedure calls and then quickly into an idea of something called object request brokers where we were simulating interactions with component-based systems in distributed systems i got involved in a startup where we built some infrastructure to support what we would now think of as quite advanced micro services based on a concept called cooperative business objects little little bundles of domain logic that communicated through what we call a semantic data service a bit like xml but predating xml i then worked moved on on bigger commercial systems working on component-based systems message-oriented architectures service oriented architecture came in at the beginnings of this century and became more popular and then i moved into building high performance systems based on event driven architectures sometimes using patterns like cqrs micro services and ending up with something that we ended up we called reactive systems all of these are service oriented systems all of these models were based on that concept of little bundles of logic that were somehow more discrete from one another than the classes and functions within our implementation and so brett had more abstract interfaces between them the ideas of of service orientation are extremely useful they're an important idea i would argue in computer science and building bigger systems and i think that they principally matter for two reasons one of those is technical the other is organizational now these are very closely related as mervin conway stated in 1967 any organization that designs a system defined broadly will produce a design whose structure is a copy of the organization's communication structure so the architecture the design of our systems is closely related to the communication topologies that we employ in the organizations that we work in this has an impact on the kinds of architectures that it's possible for teams to build and the the the organization the architecture mirrors your organizational structure if we decide to divide up our city our teams into on technical boundaries we have a ui specialist team and a middleware team and a data team then we're going to build a system that looks a bit like this a tiered layered system and the teams will be have to coordinate and interact more modern software development approaches tend to prefer smaller more autonomous teams if we're going for a variety of reasons if we are going to organize ourselves along the lines of more modular autonomous teams we're going to build more modular software with more autonomous components and it looks like this but this is not necessarily a micro service organized system we could choose how we how we were going to organize our teams around this we could put everything into one big repo and have a distributed service oriented system communicating with rest or messaging or whatever other technique or we could have independently deployable units of software autonomous components that were micro services they're not the same thing so if we can have distributed monoliths organized as collection of services which is probably my preferred architectural approach if i'm honest for many systems what does micro services add to that well the key thing is that they are independently deployable deployability is one aspect of autonomy for these services but it's an incredibly useful one if we can work on changes to our to our service and deploy it without necessarily communicating or interacting with other groups of people that means that we can make progress without being constrained by those groups it means that we are developmentally less coupled to the rest of the organization that's really what independently deployable means if i need to care about dependencies on other services before i release my change into production my software is not really independently deployable anymore well this is a big idea and this is the biggest stumbling block that i see with teams adopting micro services and the biggest problem the biggest cost of micro services this has serious implications for the way which we design software and the way in which we employ it you don't get to test your services together before you release you don't get to force changes that you make to your service on consumers of your service you can't demand that they update in step with you that's not part of a microservices model if our services are autonomous and independently deployable we build test and deploy them independently this is the real value of microservices this is the the step that decouples organizations both technically and culturally and allows them to grow and create software at an enormously fast rate it's the thing that that differentiates organizations like amazon from more conventionally organized firms and this is also the real cost because if you want to be able to independently deploy these services then you've got to be able to take the the ability to maintain that independence really very seriously services are an in organizational decoupling play that's what they are for if you don't need to decouple your organization developmentally they're probably not the right thing to do because they come with this cost they allow development organizations to grow very big and to work as a large collection of small independent teams but to achieve this microservices must be loosely coupled we need to take that separation of external and internal representation incredibly seriously and we're going to invest time and effort and development effort into keeping that separation clean we need to treat the external interface of our services like a public api because it is we can't demand that other people change in step with us when we want to make changes to our api so we've got to be very very cautious about the ways in which we can change that api when we're consuming the api from such a service we should be cautious not to couple ourselves too tightly to it we should only take the information that is of interest to us and no further we'd like to make those interfaces as clean and abstract as we can achieve so we should be very very very cautious of breaking changes at any point it brings in techniques like supporting multiple versions of interfaces on the same service or multiple versions of services in some in some approaches these are the techniques of microservices this is the cost of micro services but for that cost you get some huge advantages we need to create interfaces to our services that we can defend and rarely and only with great caution change there's lots more to talk about on this topic we'll certainly explore microservices and modular loose coupled design in future episodes but if there's anything else that you would you think would be interesting please do let me know in the comments thank you very much for watching

Channel: Continuous Delivery

Views: 155,301

Rating: 4.9539022 out of 5

Keywords: microservices, microservices architecture, what is microservices, what are microservices, microservices example, continuous delivery, devops, Dave Farley, software development, software engineering, micro services, microservices tutorial

Id: zzMLg3Ys5vI

Length: 17min 47sec (1067 seconds)

Published: Wed Oct 28 2020

Reddit Comments

[u/flavius-as]

Summary:

A microservice is independently deployable. If you need to orchestrate any deployment, you have a distributed monolith.

Each microservice has its own state (database) not shared to any other microservice.

Each microservice can issue events and it can choose to react to other MS'es events, asynchronously.

Microservices come with a huge operational cost.

And finally, the most important one: use microservices only when you have multiple teams. MS is a people's pattern first and foremost.

My own input:

1. people have gone crazy with them, thinking they're all Netflix. No, most companies are not Netflix, you're not Netflix. A good old pair of load balancers with a floating ip and a bunch of worker servers, and a fast DB server can accomplish A LOT!
2. You can actually start with a nice Monolith, do hundreds or thousands of req/s, and later on analyze your use cases and extract microservices from them. It's not easy, but it's not a terribly difficult undertaking either, especially if you've done the layered architecture with a nicely encapsulated domain model (watch out the direction of the dependencies, your domain is supposed to be free of any dependencies)

[u/mini2476]

I always think about the phrase “if you can’t build a monolith, what makes you think microservices are the answer?” when designing systems

[u/protienbudspromax]

This was amazing, thank you!