 Thank you for joining my on-demand webinar, learning to contain your microservice sprawl. We're going to talk today about some of the issues that you will find as you move into a microservice architecture and move away from your monolithic. I call this your fast path to business agility. We're going to discuss three major challenges to controlling your microservice sprawl. First of all, lack of organization. I sometimes call this the junk drawer approach. Ambiguous service ownership and profile. And a reactive approach, what I often call a lack of visibility. But first, a little bit about me. My name is Tracy Reagan. I am somewhat of a microservice evangelist. You probably have seen me around at some of these conferences. I'm passionate about configuration management, have done it all of my life. I am the co-founder and CEO of Deploy Hub. I am the community director of an open source project under the CDF. It's incubating under the CDF. I was recognized as a tech beacon, or a top DevOps visionary by the tech beacon folks. I'm a founding member of the Eclipse Foundation way back when. And I'm also a founding member of the CD Foundation. I am hanging out around the DevOps Institute often. And I have probably about 20 plus years of DevOps experience, even though we didn't always call this DevOps. And if you ever like to chat, you can reach me on LinkedIn at Tracy-Ragan-OMS. So just a little bit about Artelius, our open source project under the CD Foundation. I'm super excited to be part of the CD Foundation. I was super happy to be able to contribute our code base around this particular problem area. So Artelius is a microservice management platform. Some people have referred to it as a DevOps dashboard, that versions and tracks microservices, their blast radius and their inventory across all your clusters, providing this proactive view of your microservice architecture and how it changes over time. As I said, it's incubating under the CD Foundation. And our mission is to simplify the adoption of microservices through a world-class microservice management platform driven by a supportive and diverse global open source community. To deploy have contributed about 80% of the code base to this open source project. So as you probably know, since this is a CNCF webinar, but I'm gonna cover it anyways, a service-oriented architecture and a microservice architecture are sometimes interchanged, but there are some subtle differences. A service-oriented architecture was still monolithic. And NSOA uses APIs as a way to build out your architecture, but also uses a service bus for those APIs to connect. A microservice architecture is truly, truly a decomposed architecture. And the concept of an application goes away and you start managing microservices instead of an application. But the application is still there. We often call microservice architecture a fine-grained SOA. Microservices have really shown a increase in usage over the course of the last few years. The market itself is growing pretty fast, particularly around this concept of a service catalog or a way to manage microservices themselves. This is also kind of converging with continuous delivery and GitOps and these kind of progressive delivery markets because they are low-code. Once you really build your microservice architecture, it really provides the business agility that you need, not only taking advantage of the benefits of Kubernetes like fault tolerance and auto-scaling, but just the ability to build out a foundational collection of microservices and then have everybody reuse them. According to the CNCF's recent survey, 92% claim that they use containers in production and they also are using Kubernetes in production. Now, microservices follows that trend. People normally start with a containerized application and then they move into decomposing that into individual microservices. But they can be complex. They are essential to business agility but they can be very complex, particularly when we try to use the same kind of development practice and workflow practice that we may have in monolithic. Here's some interesting quotes. Alexandra Nuenan from a company called Segment. This was early on in the microservice adoption. She was quoted in SD Times as saying, what would happen is we would release an update to a library and then one service would use a new service and now all of a sudden these other services were using older versions and we had to keep track of which service was using which version of the library. She's talking there about drift where multiple clusters are using different versions of the same service. And as Randy Hefner states, microservice development falls apart without a coherent discipline managed approach. So moving to microservices, we're really talking about taking our static application, breaking it into smaller puzzle pieces and then sorting out how to manage those smaller puzzle pieces. Benefits of microservices are huge. First, you get service granularity, which is super important. They're independently deployed so you can deploy them all day long. You're not waiting for an application to be recompiled and retested. They're polyglot, meaning that you can use multiple different languages. Not everybody has to be learning Java script, for example. They are reusable, but they're loosely coupled, which is one of the benefits and also one of the drawbacks. And as I said, they enjoy the fault tolerance and auto-scaling of a Kubernetes environment, meaning you can auto-scale a small portion or one single microservice without having to auto-scale your entire fat binary. But the problems really revolve around the ability to organize, the ability to change the way we manage our workflow and just disrupting our general practice of delivering software through a monolithic practice. So lack of organization is probably one of the main complaints I hear from individuals and companies moving to a microservice architecture. And microservice sprawl is a common symptom of a lack of organization. Multiple services are written by multiple teams that do the same function bad. If you have everybody writing their own login routine, you're not doing it right. Not only that, you might have somebody who does that job really, really well and somebody who doesn't do it so well and you wanna add some security functions around that now where are all those login routines. So that is a symptom of a lack of ownership or I'm sorry, a lack of organization. Now lack of service ownership in a profile also becomes a problem. So who wrote it and who's using it becomes an issue and what versions are we using? You may have a microservice out there but what version of that microservice are you using and that version of the microservice goes, tracks all the way back to the version of the small piece of code that was used to create that container image. And what we also see is a reactive approach to this model where observability tooling which is super critical but it's used as a way to determine usage. So instead of understanding your configuration prior to a deployment of a service, you wait till that service gets pushed out and if there's an incident then you begin to try to track it using observability tooling. So let's take these one at a time. Let's talk about the lack of organization or this process I like to oftentimes call the junk drawer approach. What we see our organizations moving to a microservice architecture, they may have used a domain driven design approach on paper but then when they start to implement it one of the ways they could do that is maybe a naming standard where they put the domain in the name or the app or the team that might have developed the microservice but it's pretty obscured. And a domain driven design is super, super important in sorting out how to organize your microservices. So a DDD really facilitates the organization and modeling of your microservice architecture but you have to have a way to continue that in practice. So taking it from a piece of paper and a design model and actually starting to organize it in the way in which you deploy and manage your microservices is problematic. When you think about how we start layering a domain driven design in microservices we oftentimes will break it into these problem spaces or oftentimes I like to call them solution spaces having a more positive approach like an application layer and a domain model layer and infrastructure layer. So if you're taking the time to build this out what you wanna be able to do is manage those microservices based on that DDD and that will solve your organizational structure problems. And really think about DDD as identifying patterns to really further organize the development and usage of your defined layers. So we're talking today about deploy hub and how deploy hub solves some of these problems. Again, deploy hub we contributed about 80% of the code base to the Ortelius project. So if the Ortelius doesn't do that function I'll let you know. Most of the code base is available as an open source so that is through the Ortelius project. And a domain driven design is one of those features that we did contribute to the open source project. It is key to managing a microservice environment. So Ortelius and deploy hub uses a domain driven model within its service catalog to organize your microservices. And it does so based on a high level global domain and subdomains. Now in our pro version you can have multiple layers of your subdomains in the open source version you're limited to how many subdomains you can create. But in essence what you're able to do is for example on the right hand side you see one of our maps of our domains. There is a fictitional company out there called the online store company. And it has two domains that are catalog domains. And catalog domains are how you manage and register your microservices. For example in this purchase processing you have currency, checkout, cart, payment and shipping. And those are more granular subdomains so that those small little functions of microservices can be categorized based on purchase processing and cart service for example. So a domain driven model does two things. It organizes your microservices and once your microservices are organized they're easier to share because people can find them. So it really facilitates the reuse of microservices, the collaboration around microservices and the knowledge of who's using them. The second problem that we identify here is ownership. A service catalog would tell you who owns the microservice but there's also a profile of that microservice. It's not just about ownership or the microservices workflow that it went through. So Deployhab and Artilius has a backend database that tracks microservices based on this domain driven design catalog but we also added a version control engine to it. So now we have a version control platform for managing these microservices that has depth to it. It solves questions or answers questions like who created the service, who uses the service, which speaks to the blast radius we're gonna get to. What version of the service is running where? This addresses the drift and obviously you wanna be able to manage your drift. So if you're gonna deploy a microservice you wanna be able to deploy it to everywhere that it's running, whether it be multiple clusters or in multiple namespaces. And what is the deployment metadata? How many times have I heard people say, well, we have problems because we'll have a container which has our microservice but everybody writes their own home chart and deploys it in different ways with different parameters. No place to manage in a clean way key value pairs. Sure, they may be stored someplace. However, everybody can store their own key value pairs in a central location. They're just different people using different key value pairs. So creating a service catalog around microservice and tracking what I call its profile as well as its ownership helps simplify microservices and eliminate some of the drift in terms of how they're used and deployed. So I've been talking about a service catalog and that's the essence of what deploy hub and Artilius is. It's a service catalog and a logical collection of microservices and how they relate to their applications that are consuming them. Now I talk about the logical application because it's still important. It is still a piece of the overall puzzle that we have to understand. Our application teams are still building out their products. They're just consuming microservices or they're writing their own. So how do we solve the lack of service ownership within this service catalog? Well, we have your microservice developers or API developers register their microservice. And when they register their microservice, they're gonna register it to a particular domain. They're going to define who they are. They're going to indicate what account chart they use or what deployment solution that they're using for deploying this. They're gonna manage the key value pairs and they're going to indicate what workflow, what CICD workflow if you're using one is pushing it. This starts to be getting to build the who and the how. Now we also have the what, which is really, really important. The what is the version? And in the microservices world, your version is based on your container saw. That's what makes it unique. Certainly the code inside of it is also unique, but what's unique about the microservice container is the saw and that's what allows us to track versions. Now, deploy heaven artillery is triggered based on the registry of a container image. When that occurs, it goes out and it pulls that saw information, actually the tag and we create a new version of that particular, what we call a component. Now anytime a new component is created, any application that consumes that component has a new version. So we version at the component level and that triggers a new version of the application level. And that's how we begin to create these maps of usage of microservices across all of your clusters. So if we think about what that looks like, once we are triggered to grab that information and create a new component, we start managing that component's life. Sometimes it may never be deployed. It may just be a release candidate. And when you think about that, think about how we did continuous integration. And we triggered a build, a build compiled a new binary and now we had a release candidate sitting there waiting to be deployed. There's always arguments about where the release candidate actually starts, whether it be at point and check in of the source code, that's the release candidate. But when we talk about continuous integration, we did that to continuously build and have a viable release candidate that could be pushed across the test. We are sort of taking those concepts and reusing them. And we're reusing them here by saying, we have a new release candidate that was just registered. The MOS was just registered, the container registry. It's available to use. This is what it looks like. This is its home chart or whatever process you're gonna use to deploy it. And now we have a new version of it and we're gonna track it based on that tag. Because of the type of visibility we're starting to build, we are providing us a proactive approach because there's a problem with being reactive and waiting for an incident report and then using observability at a cluster to see the transactions or what actually changed. What we're providing is information before you ever think about deploying the impact of that particular update. So for microservice changes, what consuming applications are going to be impacted. And that's what we call the blast radius. So Artilius and Deploy Hub provides these proactive maps that shows you exactly what will be impacted and it also shows you where it's deployed so that you can be sure and deploy it to all locations that it needs to be deployed to. And knowing your blast radius can reduce errors and incidents while increasing your microservice sharing by as much as 50% according to our early adopters. That visibility can be super, super critical. It can be used for many things, not just deploying, but who to test. So before you ever release a microservice, you really should understand who's consuming it and what needs to be done with it. And Deploy Hub can tell you who's consuming it. And again, I've often asked how do you do that but just think about it as a relational database with a versioning engine built on top of it. So we have some depth and we can start creating those relationships based on versions. Now the other thing that you think about is testing. We talk to testing teams often and they are often frustrated because they're not aware of a new microservice being pushed across. And they would like to know that because they wanna be able to run some basic tests. And they wanna do the kind of testing that they've done in monolithic because in their world, sometimes they see this as a monolithic, still a monolithic practice, they're still testing an application even though the underlying pieces may be moving a lot quicker than they're used to in a monolithic world. So with the ability to have these impact reports or these blast radiuses, Ortelius and Deploy Hub can actually push off to the CI-CD pipeline and tell those other application test workflows when they should execute. So that can be automated. So how do we do this? So from an application team's perspective, they are still doing and building out applications and they're still building out applications and understanding them based on a package. So within Ortelius and Deploy Hub, we provide them a packaging blueprint where they can select the microservices they're gonna use. We call this their base version. So we prime the pump by defining a logical application based on what services it consumes and that base version information then is like checking in your first piece of source code. All of the updates then create new versions from that point on. Now, if we're gonna add additional microservices to your application, you would create a new base version and that allows us to start tracking the components within that. And that's how we track the blast radius. So like I said, the way Deploy Hub is configured or is built out is we get triggered on a push to a container registry. As soon as a new image is created, we wanna know about it and we grab it. That triggers us to do the, to grab the show our information, the digest and the tag and create that new version of that microservice. It also tells us that we have to do all of our automated configuration management. So at that point in time, we build out the maps, we update the application versions that are consuming that microservice. So everybody has that information right there, right in their face, basically. Now, if it gets deployed, we can be triggered by your CD pipeline to go ahead and say whatever that component, however that component's been defined, whatever tool is being used for that component, whether it be Helm or it's being pushed out by something else, to go ahead and trigger that deployment and then we listen and get that information back. Well, what do we do with that information? We start tracking where it's been deployed and with that information, we can tell you where you need to deploy it again. We also have a full set of API so you can get to this information and we store it all in a Postgres data store. So as I mentioned, we are really doing automated configuration management and at the end of the day, we're providing data not only to microservice developers who are writing these services and working very hard to maintain them and provide new features to them, but we're also providing information for application teams. So when a new container is registered, we're going to update their application and tell them what was new and we're also gonna give them maps of the kinds of information that they used to have when they were doing monolithic development, but we're gonna do that in an automated way. So again, our secret sauce is this version control engine built on top of a relational data store because when we know a new microservice has been updated, we go ahead and we create new versions of the consuming application and it may not be deployed yet, but it's out there and it's a release candidate and the results are these types of maps, a bill of material report. We're doing work now even to drive down and to do bond reports for the individual microservices, which we could then expand to a bond report for the entire, all the way down from the microservice to the application and the microservices consuming. So we're putting that bomb logic back into a microservice architecture. We show you the blast radius, we show you a consuming application, in this case, the orange box or I'm sorry, the pink boxes and the microservices that was changed that caused the new versions of the applications and the applications that it impacts. And super, super important for everybody is the difference report, what changed? This was running yesterday and now I get a call and it's not running. We didn't do anything as an application team, what changed? And with both Ortelius and Deploy Hub, you can look at your difference report and you can say this changed, the cart service changed. And now you can, with our ownership information, you not only know that the cart service changed, but what version of it and who owns it. Now I told you, I tell you the differences between the two. Deploy Hub Pro goes a bit a step farther in these comparisons and we provide comparison reports for environments showing any between any two clusters, what we have changed in the cluster. And we also show that same report based on applications and we do it based on the component. So anytime we do do something has been pushed out to an environment, we start tracking that information which allows us in the same way as we track microservices, we track applications, we track environments and endpoints because that's where those microservices are gonna be running. And so we begin tracking those changes as well. So just to summarize, what we're delivering with Ortelius and Deploy Hub is microservices without complexity. We're helping you control the sprawl and have a central catalog of microservices, their ownership, the who, what and where of the microservices so that you can improve your confidence and eliminate risk. Knowing your blast radius before you go has always been important, but it used to be important at the compile and leak time now it's important at runtime. We're gonna reduce the development cost by reducing the amount of microservices that are written that do the same thing. Not having 10 or 15 login routines in individual services is not a good way to achieve business agility. And we're gonna restore some control, especially to the application teams by creating that logical application and versioning it with the change tracking and identifying these new release candidates as they show up because the underlying microservices have changed and most importantly, we're gonna give you the proactive visibility that you need to understand and track your microservices as they change across all clusters. We're not running in a single cluster. We're running above all the clusters and tracking this in a catalog format. The results from our early adopters, they tell us we're saving them about 50% of reduced coding and redundant coding and sprawl, as well as drift, drift is just as big as a problem. When you have sprawl, you tend to have drift. The automated configuration management saves about one to two hours of this manual work to try to track microservices like Alexandra Newton described how they were having to track the services manually. And it gives that proactive visibility so your SREs can really make data-driven decisions before they ever push something out or at minimum notify the application teams or automatically push those testing workflows to execute those tests. And we're really evolving the CI CD pipeline and delivering these high frequency and we're not talking about high frequency in the door metrics where it's great if you're doing a release every day. You're releasing it all the time with microservices and that is the essence of business agility to be able to deliver new features on a high frequency basis where thinking about doing a deployment isn't a scary thing. It is a common thing. Just to kind of view what the pricing is around deploy hub. Of course, we have a free version. We have taken the Ortelius code base and we do have a SAS version of it so you can sign up for it with deploy hub team. Go to deployhub.com. You'll see a sign up for deploy hub team and you can start playing with it. Please give us feedback and let us know what data. We love to hoard data. What are we missing? And deploy hub pro, we charge based on an application. We don't charge based on endpoints. In some cases, we're not even doing the deployment. We charge based on the mapping, based on an application. So in our example, the hipster store was an application. The cart service was a component. The hipster store would cost $2,500 per year. We do have an enterprise price at 75K and that's unlimited. And if you get to 30 applications, we just consider you an enterprise account. Some of the differences, most of the differences between Ortelius and the pro version have to do with what an enterprise would really, really need. Enterprise level support. Security around your user groups and the ability to have more granular user groups. In the Ortelius version, you have an admin group and you have a user group. In the pro version, you can build your own groups and those groups can have security around particular levels of domains. As I said, additional domain modeling for really defining how your organizational structure looks. We do add more security around deployments to endpoints, comparison reports. I showed you those. We also have something called smart calendars. So if you're a testing team or you're an operations team and you don't want that microservice to be updated into your cluster, you can block your environment out and deploy, we'll take a look at it and say, hey, is this cluster open for business? If it is, cool. If it's not, we're gonna block the deployment. And the next time the deployment happens, we will get that cluster back up to its correct state. And we also have something called release train management. We still see companies trying to coordinate shared services around multiple applications of doing release trains and we do provide that release train management. Thank you. Thank you so very much. And if you do want to get a hold of me, the best place to get a hold of me is by Mann LinkedIn. I'm at tracy-regan-oms and ask for a meeting. I'd love to be able to chat with you. I would love to be able to chat with you. I like to do 15 minute coffee chats. So find me on LinkedIn and let's talk. Thank you.