Microservices: Decomposing Applications for Testability and Deployability
Chris Richardson at Kong Summit
During the Kong Summit in September Chris Richardson, founder of CloudFoundry.com, gave an excellent talk describing the characteristics of microservice architectures. He outlined the benefits of microservices, including testability and deployability. He also discussed the drawbacks. Microservices aren’t a silver bullet, and Chris explained some of the factors to consider before deciding to break up a monolithic codebase. In the talk, Chris provided an overview of the microservice pattern language, describing architectural patterns that can help frame the decision to move to microservices, and design your implementation.
See more Kong Summit talks
Sign up to receive updates and watch the presentations on the Kong Summit page. We’d love to see you in 2019!
Full Transcript
Great. Well, it’s good to see so many people here. I must confess I’m a little jet lagged. I just got back yesterday from three weeks in Vietnam and South Korea, so if I sound incoherent at any point during this talk, or fall asleep, you know why. So this is an overview of the microservice architecture, define what it is, explain why you would want to use it. Because certainly one thing I’ve noticed, traveling around visiting clients is somewhat become this magic pixie dust. Oh, we just sprinkle microservices and everything will be perfect and so on. But it really isn’t. There’s a real goal to using the microservice architecture and actually, and also in order to be successful with it, you actually have to have the right in house capabilities as well.
So I’m going to talk about the benefits of using Microservices and also talking about the drawbacks as well. But before I do that, a little bit about me. I’ve been developing software for a long time since the eighties. In fact, it turns out my first paid job was back in 1982 writing RPG on a mini computer, but not cool. But anyway, I worked on a number of things. Worked on Lisp implementations for seven years, quite a long time ago. Eventually ended up programming in Java. 12 years ago now, my book POJOS in Action came out and that was all about building applications with Spring and hibernate, which we’re revolutionizing enterprise Java development. Then back in 2007, I started tinkering with this really obscure service known as Amazon EC2, which was from this online bookstore. Weirdest thing.
Anyway, API, you can provision servers up to 20 servers, pay ten cents per hour per server. It was like, whoa, that’s so cool. So I ended up creating the original cloud foundry. So that was a pass for deploying Java applications on EC2. Uploads your war file, launched a bunch of instances and configured them with Apache Tomcat and MySQL. And then, that got acquired by SpringSource back in 2009, which was right before SpringSource was acquired by VMware. So it was all part of, well, SpringSource, VMware, and then briefly Pivotal, for like four and a half years. That was like five years ago. And since then I’ve been pretty much focused on the Microservice architecture, traveling the world, working with organizations, get to help them successfully adopt the Microservice architecture through training and consoling.
Also, working on a startup, building a platform to simplify the development of transactional business applications that use microservices. And I’m in the middle of finishing a book, which will be, or actually should go to press this week. It was funny with my trip to Vietnam, I was working with a client all day and then in the evenings I was reviewing proofs. So didn’t actually do any sightseeing. Anyway, book should be out, the early access virgin version has been available for quite a while now. But the actual printed version should be available real soon, and you can get a discount 40 percent off today only with that discount code. Now I also work on microservices.io. That’s a destination site where you can learn all about the microservice architecture. And a bunch of what I’m talking about today really comes from that site, and I actually going to be introducing some tooling or self assessment, so you can evaluate your microservice architecture and identify the weaknesses, and it will provide guidance on how to improve them.
Anyway, enough about me. Let’s talk about microservices. So compare. It’s going to begin by comparing the monolithic architecture with a microservice architecture, and explain why you would want to use it. Then I’m going to talk about some of the challenges with using microservices, how they’re not actually a silver bullet that if you simply start using them, we’ll make everything perfect. And then, I’m going to finish up talking about the microservice pattern language. That’s a collection of architecture, design development and operational patterns that can help you successfully apply the microservice architecture. That’s me. Remarkably, I’ve been talking, and I still have 50 minutes remaining, so not quite sure how that works. Okay. So let’s imagine that you are going to build some cool new application. I’m a foodie and so everything I do and somehow involves food.
So an example application in my book, is a food delivery application. I think now it would be cool like online real time logistics application, it sounds fancier. But imagine you are building an application like that. You would most likely come up with an architecture that looked like this. So internally it would layered, it would have modules corresponding to different functional areas of the business, auto management, delivery management, restaurant management and so on. So it actually would have structure to some extent, but then from an actual packaging and deployment perspective, what you’ll then do is just package it up as a single application. In the Java world, that would be a war file or an executable jar. I guess some other language, there’s just this notion of an application and I think if you’re a startup, it’s really common to just build the application.
Your entire business is just a single APP, application, single code base, which is interesting because at some level this is not a bad idea. The monolithic architecture, just building something as a single application is not actually an anti-patent. There are many situations in which this is the appropriate architecture for your application. You can successfully develop software this way. But the problem you have is, if you’re successful, your application has a habit of growing. You go read some classic book on Software Engineering. There’s this notion of why you do requirements. Then you build it, and then there’s this maintenance phase where you somehow maintain the application. But in reality, applications, we never stopped developing. They just keep growing. Those marketing people come up with new features, and we keep having to add them.
So the application just keeps growing. And then because we’re making money or at least we’re getting lots of VC funding because companies don’t seem to make money these days, we can hire more people and the team keeps growing. And then eventually, we might divide up into these different teams focused on particular functional areas of the product. So we’ve got lots of people organized into teams. We’ve got this massive code base, and eventually you’re going end up with a huge application. And I’ve talked with clients were, they say they’re a 10 year old company, and they have 100 developers, and their application is measured in gigabytes. Trying to remember what the largest one was, maybe it was five or 10 gigabyte application. And these are actually successful companies. The unsuccessful ones, they go out of business, and they don’t have any problems with large code bases. But unless you’re lucky, eventually you’re going end up in this place where development becomes quite slow and quite painful.
The code base is beyond the comprehension of an individual developer. The sheer size of the application makes testing a slow, painful process. Likewise, deployment is this slow, painful process. You end up in what I call monolithic hell, just because your application is really outgrown its architecture. And then not only that, another side effect of this is that you tend to be locked into the particular technology stack that you picked at the start of development. Your code just simply is too expensive and too risky to migrate your entire application to a large code base. And then there are other side effects. Like modularity tends to break down and your architecture slowly degrades into a big ball of mud. So it’s deeply problematic.
I am not saying it’s inevitable, but it does seem quite likely that given enough time, you will end up in this situation. So this is a problem. I hate the phrase software is eating the world, but there’s some truth to that. Software become central to how businesses operate. Businesses need to innovate faster, which from a software development perspective means that, we as developers need to deliver software much more quickly, much more frequently and also in a much more reliable fashion. So the whole pace of delivery needs to accelerate. If we’ve got these large, cumbersome monoliths that’s our application, then we’re not going to be able to do that. We don’t have the deployability and testability that we need to truly be competitive. That then leads to the microservice architecture. The basic idea is instead of an architecture like this, we have an architecture like that, where instead of one large monolithic code base, or one large monolithic application, we functionally decompose our application into a set of services, and those services are loosely coupled.
It means that we can easily change one without that change rippling through the system. Also, the services tend to be organized around what are known as business capabilities. So they implementing specific functional areas of the application. That’s a term from business architecture where you think, you analyze the structure of an organization, it’s going to have a set of capabilities, which are basically things that it needs to do in order to deliver value. So an online store must have an order taking function, must have a kitchen management function that manages the preparation of the food of the restaurants. It also has to manage deliveries as well. Coordinate and couriers plan their routes and so on. So if those are the capabilities that you need in order to operate a business, you basically map that into a technical architecture and defined services corresponding to those particular capabilities.
Now, that is an essence of the microservice architecture. It is just a form of divide and conquer, or modularization where what we’re modularizing into is a set of loosely coupled independently deployable services. So what that means is, if we go back and look at the food delivery application, where I have a bunch of services because they’re loosely coupled, each one of those services is going to have its own database. Services cannot communicate through databases or through database tables because that is a form of tight coupling, which actually creates all kinds of interesting challenges around transaction management and querying, which is a whole other talk. You can also functionally decompose the web application so that’s the application running service side that’s generating HTML pages. So you can have a web application that’s responsible for order management, another web application that’s used by the restaurants in all the kitchens and so on. So different parts of your UI or implemented by different web applications.
This API gateway is relevant to this conference. If you’re exposing an API to the outside world, then you need some form of API gateway, which I should say you need to use Kong. I should have updated that slide. As I’m sure you all know, API gateway plays modal pool roles, but from the pure microservice architecture perspective, it’s exposing an API from to the outside world, and it’s responsible for routing in inbound requests to the relevant backend services, so that API might be consumed by mobile devices. It also might be consumed by JavaScript running in the browser. In addition to HTML, maybe you’ll have a single page web application. That API can also be consumed by third party developers, which actually introduced this serious API management issues as well.
And you might also have a gateway to handle inbound messages as well. So what’s interesting about this is already hints at one of the downsides is like, whereas before we had one application, and we just ran a few copies of that application behind a load balancer. Now we’ve got all these different moving parts, each one of these boxes represents a piece of software, which at run-time will have multiple instances with some load balancing capability for each one. So this is a much more complex architecture. The services themselves look something like this, from a client perspective a service has an API and that API is comprised of two parts. There’s the command API, it will command and query part of the API, which you could implement using REST. But there are other ways to do that. gRPC for example.
Could also be done with asynchronous messaging, you send in a request, you get back a response, and the commands update data, the queries simply retrieve data. And other key part of the API is the event publisher, is quite common for services to emit events. So for instance, when an order is created, the order service will very likely admit an order created event. When it’s canceled, it’s going to emit an order canceled event. Also, the service will actually have a database storing the data that it owns, and it also might store data that is replicated from other services by subscribing to the event stream. And then, there’s the implementation where the client, where service rather because it often needs to collaborate with other services, is going to invoke commands and queries on those other services and also subscribe to their events.
So this is a useful view of what a service is. Key part of this is that is independently deployable. That’s one of the key benefits of the microservice architecture is that, we can modify a service changes code and redeploy it independently of all of the other services that make up our application, enables us to develop and deliver software much faster and deploy it much more frequently. An interesting aspect to the microservice architecture as well. How big should our services be? And one of the drawbacks of the term is the first thing you hear is micro. Which makes it sound like these services should be tiny. And in fact, during the early days when people were talking about micro service architecture, people would say, oh, it should just be a 100 lines of code, or you can develop it in two weeks.
In reality, a service should be small enough to be developed and owned by a small team, the so called Amazon two pizza teams. Which could be six people, eight people, maybe as much as 15, but really no bigger than that. The idea is you’ve structured your organization into these small independent teams that own one or more services. That’s a good starting point and maybe a team would own multiple services. So to me the size of a service is really not important. It should just implement meaningful business functionality and enable a team that owns it to deliver software frequently, rapidly and reliably. So you end up with an architect organization and architecture that looks like this, where you have these loosely coupled teams that each responsible for a particular functional area of Your business. They’re developing, testing and deploying their service or services independently from what all of the other teams are doing.
At least the vast majority of the time. Obviously, if two services need to collaborate, there needs to be some agreement on what that API should be. So that’s when teams would actually meet and hash out, what the API to support the collaboration should be. But once they’ve done that, they can go their separate ways. This is one of the key benefits of the microservice architecture is that it lets you have these small autonomous teams that are working independently the vast majority of the time. Ultimately, what this leads to is, it basically enables you to do DevOps or style development of these large applications. So this is grabbed from the 2017 state of DevOps report. Interestingly, I went to the 2018 report recently but couldn’t find the exact same table. Well, so this is a survey of organizations about how they deliver software and there’s like four key metrics.
There’s deployment frequency, how often are you deploying changes into production? There’s also another key metric is lead time. How long does it take from when a developer commits their change checks in some code, to that code running in production. So that’s measuring speed and then the last two metrics are measuring and reliability. What’s the mean time to recover from an outage? Then there’s the change failure rate, how often does a deployment result in an outage? Those are really the key metrics that assess the health of your software engineering organization. They group it into three categories, low performers, medium performers and high performers. What’s interesting is the high performers they are delivering, they’re deploying into production multiple times a day. And there’s this really crazy statistic from 2014 where Amazon was deploying a change every 11.6 seconds, obviously massive engineering organization.
But like, whoa. So while I’ve been talking, they’ve done hundreds of deployments, and they’ve done that without … They rarely have downtime. Also, the lead time for change in a high performing organization is under an hour developer commits to change. There’s an automated deployment pipeline that runs a series of automated tests once it’s completed, that changes pushed into production. And there was some story about Netflix where one of their services, you could make a change to it and it was deployed around the world within 16 minutes. So it is all about moving fast. And then, what’s awesome is that they’re actually not breaking things. So high performing organizations are able to deliver software much more reliably, where they can recover from errors much more quickly. And the change failure rate is much lower than medium or low performing organizations.
You achieve this through a combination of the right architecture combined with namely micro services, combined with, proper DevOps practices. This in a sense is the key benefit of the microservice architecture. It gives you the testability and deployability that DevOps requires or more specifically continuous delivery and deployment requires. And it also, the architecture enables the teams to be small and autonomous. This whole model of a team owns one or more services that they can develop, test and deploy independently of what those other teams are doing. And that’s ties it. That’s the organizational structure that fits in with DevOps. And then, this is essentially why what we should be doing using the microservice architecture.
And then, there’s this graph, which came out in his excellent book, Accelerate. What’s really interesting is, normally when you grow an organization, productivity drops because you spend more and more time in meetings, the coordination costs, which are like N-squared, start dominating once your organization gets quite large. But there’s this great chart that shows in these high performing organizations where you’ve got these loosely coupled teams in a loosely coupled architecture. As you increase the number of developers, productivity actually goes up, which is quite powerful, which is such an awesome concept.
Also, another great benefit of the microservice architecture is that you can experiment safely and evolve your technology stack. So for instance, you might have an old Java stack. And then you hear that Google uses gore language makes it super cool, so you use that. Then you realized that you really want a modern language, not like C, 1990s version of C. So you might then decide that Caitlyn is better. And that’s okay. You’ve done an experiment, and you’ve you’ve tried using one language and decided that it wasn’t a good fit for you, which is a valuable thing to know. And then, later on you can replace that service with a language that you’ve decided is a much better fit. That’s a really important benefit of this architecture. So you can incrementally and safely evolve your technology stack over time.
So a whole bunch of benefits. But there’s also some significant downsides to this architecture. There really is no silver bullet in software engineering. Basically, any technology house has both benefits and drawbacks. That it’s inescapable. And by far, the biggest drawback of the microservice architecture is its complexity. From a development perspective, you’re now building a distributed system. So you have to deal with interprocess communication. You have to deal with partial failure. When you invoke a service, there’s no guarantee that that service is going to respond in a timely way. And also, you have to deal with distributed data. Each service is owning its data and so traditional transaction management techniques can’t be used. Good news is, for all of these issues, there are frameworks, but there is this additional complexity that you have to deal with.
Also, testing is simultaneously easier and harder. It’s easier in the sense that each service is small and so easier to test, but you then have the issue of, well, how do we make sure that our services can actually work together? So when service A equals B, that’s actually going to work. The good news is, is that there are testing strategies in particular consumer driven contract testing that you have to employ in order to do that efficiently. That actually enables you to test services independently while being confident that when you actually deploy them into production, they will actually work together. And hen also from a deployment operational perspective, it’s more complex. Before, you had a monolith one application, and you just ran multiple copies of it in production. Now they’re potentially tens, or hundreds or in some cases, thousands of services, each one of which will have multiple instances.
So in production there are just many more moving parts that you have to monitor and manage. Good news is, is that yet again there are solutions to this modern platforms like Cloud Foundry, like Kubernetes and all of that deployment technology goes a long way to tackling this complexity. So yeah, it’s like more complex, but on the other hand, your monolith is complex and there isn’t much you can do about it, and it’s just going to get more and more complex over time. You also have to figure out, how microservice is a good fit for my application? Is it complex enough to justify using the microservice architecture? If you’re a team of two people, probably not. If you’re a team of 30 people, quite possibly. The actual answer is a little bit more complicated than that. It depends because I’ve worked on two person teams where we probably could have benefited from it.
And then also, do you have the skills in place to properly use the microservice architecture? A common weakness of many software engineering organizations is, they’re terrible automated testing? Sure, all of you are good at it, but all the other folks that I go visit, even though like JUnit Popular Java Testing Framework is like 20 years old now, it still doesn’t seem to be used widely. I mean there was some statistic report showing that maybe only 23 percent of organizations made extensive use of automated testing, yet if you’re going to use the microservice architecture, you have to do automated testing. And not only because what you’re building is much more complex, but if your whole goal of using microservices is to deliver software frequently and reliably, well a big part of that is automated testing.
Also, automated provisioning. No more SSH’ing into machines and copying over files and so on. You have to have that automated. And then also, when you are using microservices, there’s a whole bunch of technical issues that you have to address around interprocess communication and so on. So there’s a bunch of challenges. Because of that, that motivated me to create to microservices patterns language. So that’s a collection of patterns that solve these architecture, design development and operational problems. So if you go to microservices.io, you’ll see this pattern language. Just to briefly recap, what’s a pattern? Has a really simple definition. It’s a reusable solution to a problem that occurs in a particular context. And it was popularized by the so called Gang of Four book, which came out in the mid nineties and that was a collection of object oriented design patterns. Singleton, strategy, proxy and so on.
But the concept of a pattern is much broader than that. There’s a vast number of domains that you can use patterns in. In fact, the original pattern concept came from real world architecture. Christopher Alexander created the patent language for architecting everything from cities down to like, how to lay out a room, lay on two sides, for example. So patterns are really useful and one reason for that is that, they really encourage objectivity. Now today, if you think about how we talk about technology, it’s usually, well, this is awesome. Oh, that sucks. My favorite technology rocks. Yours sucks. We raise polarized positions that don’t properly evaluate the benefits and drawbacks of any given approach. Whereas patterns take a different approach because if you look you’ll see this on microservices.io.
When you talk about patterns, you have to describe the benefits, but you also have to describe the drawbacks. Then you have to describe the issues. Which are problems that this pattern introduces. And then you also have to say, well, if you’re going to use this pattern, you will have these issues. And in order to solve those issues, here are the patterns that you must apply or consider applying to address those issues. So patterns actually have relationships with other patterns. And not only that, a pattern also should say, here are the alternative patterns, other ways of solving the same problem. It’s a really simple idea, but it’s a much more objective way of describing a technology, or an approach, or a solution because of the fact that it’s describing the drawbacks, the issues, and then the related patterns.
So this is the pattern language, which you probably can’t read, but that’s okay. If you go to microservices.io, there’s a very readable version of that. But it’s different areas of patterns top level, it’s like, well, should I use the monolithic architecture, or the microservice architecture? And then if you decide to use microservices, everything else on all of the other patterns apply to the microservice architecture. Then obviously, the next question is, when I’m going to use microservices, what are my services? And so there’s patterns that guide you on how to decompose into services. And then, once you’ve done that, there’s all these other patterns that you have to use to actually make all of those services then work together. So it’s great we split it up, but then they have to collaborate. So there are patterns around managing distributed data, and interprocess communication, and then there are operational patterns as well.
How do we deploy the services? And then also, how do we do monitoring of them? So that’s the big groups, and there are obviously other parts of the pattern language as well. And the idea is that it just guides you when you’re developing an architecture. For each of the architectural and design decisions that you must make, the pattern language actually tells you what your available options are. So here are the two, or three, or five patterns that solve this problem. And then it also tells you what your trade offs are with using them. So there’s various key patterns. Step number one is, well, am I going to use a monolithic architecture or a microservice architecture? Am I going to architect my system as a single executable or tightly coupled set of services that say share a database? And sometimes. That’s fine. Particularly if you have a small application. But then if you’re building something more complex, then yes. You do need to have structure it as multiple loosely coupled services. Then the next thing is, well, okay, if I’m going to use microservices, how do I decompose them?
So there’re two main approaches. The end result services that implement the business functions, but you can either come at it from a business architecture perspective and decomposed by business capability. Or you can come at it from a doe domain driven design perspective and decomposed by sub domain. The end result is actually the same. Just depends on which school of thought you’re in. Okay. So we’ve now split up our system, but then one issue is, how do we maintain data consistency? That’s because in order to ensure loose coupling, each service has its own database, and the data is private to that service. So we can’t actually use traditional two phase commit, traditional distributed transactions because that impacts availability. And so, there we ended up having to use what’s known as the Saga pattern, which is an eventually consistent approach.
A saga is a sequence of local transactions that are coordinated through messaging. So quite a different way of managing data consistency is one of the biggest challenges with this architecture. And then, related to that it’s like, how do we do queries? Each service has its own database, that data is private, so we can’t just execute traditional distributed queries. And so, there’s two main patterns, one of which is API composition, which is why, if there are five services that own the data that you need, you simply invoke their APIs. You just call each one and then combine the data. And that works well in some situations, but in other situations it can be prohibitively expensive. You end up having to implement what was basically a distributed query mechanism, which you really should not do. So the other pattern that you can use is called CQRS, command query responsibility segregation, where you basically implement a database that is a queer easily queryable replica of data that exists in multiple services. That replica is kept up to date by subscribing to the events that are published by the services when their data changes.
In this replica, it’s constantly being updated. And then, the actual structure of that replica is designed specifically to efficiently implement a set of queries. This approach is analogous to dumping data from your relational database into a tech search engine like Elasticsearch, or [inaudible 00:40:23] to support tech search queries. It just generalizes it and makes it more real time by using events to keep the different replicas synchronize. And then of course it’s like, oh, what API should we expose to the clients? And there’s a lot of really interesting issues here. An API is often consumed by a diverse set of clients. It might be JavaScript running in a desktop browser that needs … It’s got a rich display of data, or it might be a mobile application, which is likely to display a lot less data.
And then, different clients are communicating over different networks, high speed local area network versus lower bandwidth, higher latency mobile network. There’s usually a mismatch between what the client needs. The client might want to display the status of an order, but the actual information about an order might be scattered around amongst multiple services. The order service might know some aspects of it. The delivery service probably knows where that order is at a given point in time, and so on and so forth. That ties back into the API composition and so on. And then also, we want to evolve our application architecture without impacting clients, so the clients shouldn’t actually know about individual services. And then also, some services might use protocols that are not web friendly. Internally, we could use whatever protocols we see fit, whereas the web is more HTTP and WebSocket oriented.
What that ultimately means is, we need some kind of API gateway. Or should I say we need Kong in order to act as the mediator between the outside world and our internal services. So that’s the main pattern, this API gateway pattern. And then, there’s a variant of it where we have a different API gateway for different clients. We might have an API gateway from mobile devices and that gateway is for the mobile applications, and that gateway is actually owned by the team that develops the mobile application. And then, we might have another API gateway for the public API that’s used by third party developers, and that API gateway is owned by that team. And that likely have to deal a whole lot of API management issues, long term backwards compatibility, which say the mobile team wouldn’t necessarily have to deal with.
So there’s a couple of different architectural patterns there, a single one size fits all API gateway, or an API gateway per client. That’s the API gateway. And then, obviously testing is another big part of it. Services collaborate and how do we ensure that services can actually communicate without running the expense, without having to heavily rely on end to end tests, which is slow and brittle and expensive? And there’s this really important technique known as consumer driven contract testing where we define contracts, which are basically an REST API. Each contract would be an example HTTP requests response, and so the API would be defined by a set of examples like that. And then, there are tests that use those contracts to test the service. And then, there are tests that use those contracts to test each of the clients.
So the tests are being run at different times, but they’re being driven by the same set of contracts. So fingers crossed it does mean that the client and the service can actually work together when we push, deploy them into production actually works quite well. Those are a lot of the key patterns, the key issues that you need to address that it’s going to determine the success of your microservice architecture. And then, there’s a whole bunch of just generic patterns that, I call them undifferentiated heavy lifting. But patterns around the actual low level details of communication, REST versus GRPC or, which message broker to use. There’s also a handling cross cutting concerns. So you should build your services on top of a micro chassis framework that deals with all the basic concerns like logging, externalized configuration.
Deployment is another issue. I mean, what’s interesting is that’s the primary focus in many ways when people talk about microservices, it’s Docker, Docker, Docker. Yet in reality, there are many different ways of deploying your services with different trade-offs and it’s a detail to some extent. And then, there’s mechanisms around service discovery. This is becoming less of an issue because platforms like Houben Eddy’s take care of this for you, but you can implement it at the application level as well. And then, you also have to have in place the right monitoring. You’ve got to have the basics like log aggregation, you should implement distributed tracing, so you can visualize the request flowing through your system. You should capture an aggregate metrics and alert on them and so on and so forth.
Those are all important issues. Whether they’re important, you have to do them right, but it’s not really, it’s not where you’re going to compete. Having the right set of services is way more important than that. Anyway, that’s pretty much my talk. I hope you found it interesting. So just to summarize, the goal of architecture is to satisfy nonfunctional or quality attributes like deployability and testability. Given that software is eating the world, and we need to deliver software much more rapidly, much more reliably and so on, you want to pick the architecture that best enables that. And if you have a small application, the monolithic architecture could very well be just okay. But if you’ve got a large complex application with a large team, it’s quite likely that the microservice architecture will be a better fit. You should use the microservices pattern language that guide your decision making.
So it’s pretty much all I have to say except, remember my book is 40 percent off today, just today only. And if you want to know more you can go to that link and that’s my contact info. Thank you for listening. I hope that you found it useful.
Big Round of applause for Chris. I think we’re going to open up for a little Q and A. We’ve got about five or six minutes.
Any questions for Chris? Yes.
It’s actually a basic question but that’s okay. When you have these small snippets of databases, what is the best practice to consolidate data across the micro services architecture?
Yeah. So I think maybe what you’re getting at is like for reporting purposes, say, or analytics. So the model is, so each service is owning its own data. That data is private to that service. And then, when the service changes that data, an order is created or canceled, that service will emit an event. Order created event, order canceled event. And then, interested parties can subscribe to those events. So let’s say that you want to do some reporting on the entire state of your system. So you could write a service that subscribed to all of the relevant events and uses those events to maintain a replica, the appropriate replica of that data. Effectively, it’s event driven ETL, and then you could run reports on that data, against that replica.
So the question, thank you for the answer. If in future where we’re getting data streams live and then doing AI and MLS pattern recognition on top in real time, how do you see the aggregation of data, and what microservices that play a role in that?
Yeah. It’s possible. It depends on your specific use case and what you’re really getting out there. It’s possible that the whole architecture is entirely orthogonal to the problem that you’re trying to solve. Having said that, if you’ve got some streaming architecture, you have a streamer events, which is essentially a form of pipes and filter architecture. The individual nodes in that, that are processing the data or transforming the stream of events that are coming in, that’s very amenable to the microservice architecture.
Chris, what are two or three problems that you see consistently across the board among projects?
Yeah. Number of things come to mind. One problem I’ve seen is, like say, a CIO gets excited about microservices and then just announces that everyone should be doing microservices. It happened at least with at least one client I had where they read an ebook that I wrote and got super excited. On the one hand is like awesome that leadership is promoting the improvement of software architecture. But in reality, what’s actually better is to say, if you think about those metrics around deployment frequency and lead time, that should be your goal, say. And then, the individual teams should have the ability to decide the architecture that is best in order to achieve those metrics. Like my, so in a sense the goal should never be the microservice architecture.
The goal should be deploying multiple times a day with minimal lead time. That’s one. As I mentioned earlier, a huge thing is the state of all automated testing within organizations does not seem to be that good. Can anyone here, anyone here actually go, yeah, we’re doing it really well. Anyone? Awesome. Yeah. As I said, I think there was some statistic and it was like 23 percent of organizations were relying heavily on automated testing, but it was like only six percent of organizations actually, exclusively did automated testing. That means the other 75 percent doing a large amount of manual testing. And so, it’s like, yeah, we want to use microservices so that we can deliver software quickly, but at the same time you don’t actually have the capabilities in place to do that.
I made the joke about, in a sense microservices is getting a Ferrari, but then if you’ve got manual testing, it’s pulling your Ferrari around by a horse. Makes no sense. And she made me a more realistic one, I didn’t even know if this is true, but it was like the early days of automobiles, someone had to walk in front with a red flag to warn people that a car was coming. That represents a more general problem where, if you’re not doing automated testing and then your corporate policies are, well you can only deploy once a month into production at midnight on a Saturday. That is incomplete defeats the purpose of using microservices. I see those issues a lot.
So they say a wide versioning your services because at some point of time it’s going to be unmanageable. So practically, in reality how much is being added in terms of services and versioning, or how do you handle that?
Yeah. Well, services do evolve. There’s two levels of revolution. One is where you’re changing the implementation, which in theories that’s just happening all the time. So there’s the internal stuff and they’re the primary issues. When you are rolling out a new version, you want to make sure that you haven’t broken anything. So then that gets into modern deployment practices, like canary deployments and the like.
And then, the other issue you have is API. At the API level, we’re going to roll out a new … We’re actually making changes to the API of our service. So number one, you should make sure that those … You should strive to make backwards compatible changes which are basically additive. So adding optional parameters to the request, and then adding additional attributes to the response, but writing clients in a way that so they can ignore them. And then, when you make a backward incompatible change, a service will likely have to support the old version and the new version of the API for some time until you’ve persuaded everyone in your organization to upgrade. So it’s a bunch of work. Whereas in the monolith, you just change everything in theory and build it, deploy it. So yeah. Changing your internal APIs in this world is more complex, but one would hope, which is part of the challenge, that you decompose in a way that you’re not constantly changing your APIs in an incompatible fashion which causes the changes to ripple throughout your architecture.