Joining us is Jim Rose, CEO of CircleCI. CircleCI offers a commercial continuous integration continuous delivery product. Thanks for joining us Jim. Sure. Happy to be here. Can you talk a little bit about the difference between monolithic architecture and microservices? This is a big topic that some product managers may encounter as they tune their interface with their development team. Sure. So, a monolithic architecture is basically when you have all the components of your application inside of a single code base. So, it's one piece of code that as are changes made to it, you run the tests against it. If it goes green, you know that the entire application suit to that works and is ultimately deployable into the data center. A service oriented architecture or microservices architecture is instead of having a single consistent code base, you have a web of individual code bases and individual services that work together in the data center to deliver the application. An example of that can be, in a monolith, you have everything in one code base, but a service oriented architecture, usually the first service that gets broken out is an authorization service. So, you might have an application service and then when users want to sign up, there's an authorization server that runs independent of that. For a lot of firms, they're moved towards enhancing their continuous integration and continuous delivery capabilities is tied to a move from monolithic architecture to microservices. Can you talk a little bit about that and the relationship between these two activities? Yeah. So, often times, when you start moving into a service oriented architecture, the importance of testing goes up dramatically. The importance of testing goes up because now, instead of having a single code base when you make a change, and you can go in, and validate that change even if you needed to do it manually, fairly easily, now you have website services that need to work together and coordinate themselves in the data center to be able to deliver the service to customers. That becomes incredibly difficult to test. You have to run a lot of different integration tests to be able to guarantee that the service stays up and running. So usually, as you're making this transition from a monolithic architecture into a microservice architecture, your need for automation, and your need for just greater and greater amounts of test coverage go up exponentially. Got it. You talked about what these are and how they relate to testing. How do you decide where you want to be on this pendulum between monolithic architecture and microservices? It usually has to do with the maturity of your business and the maturity of your code base. So, if you're just getting started out, and you have a greenfield, you have a brand new application, and you don't really know if it's going to work, and you don't know what's going to work in the eyes of your customer, and you don't have product market fit, 99 times out of 100, you're best off building a monolith. The reason for that is you're making changes only to one place. You don't have to worry about all the overhead related to testing, all the overhead related to logistics and orchestration. You can just make a change, push the change, see your customer reaction, and then keep moving. As your code base gets bigger, as you find product market fit, as things start to mature, as your test volume gets bigger, and your test gets lower, you want to start thinking about how do you start pulling those pieces apart, so that you can start to pick up speed again. A classic key is, when you want to start thinking about we can from a model with your micro service architecture is you change something in one part of the code base and all of a sudden something completely unrelated part of the code base breaks as a result of your change. That's usually a sign that you have a lot of underlying and hidden complexity inside of your monolith that are best to start isolating into services. As you start to isolate into services, what we see with customers is, usually start with a big monolith and you pull out one service. Once you pull out the one service, and you start to get some abet agility back, and some of your feedback, and your process, usually go from one service to tens of services quite quickly. Once you can do that, you're usually in a space where you're mature enough to be able to deal with the increased testing complexity to do that. Some great practical perspective on this question of monolithic applications versus microservices, thanks for joining us, Jim. Sure, thanks for having me.