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 architectures and micro services? This is a big topic that some product managers may encounter as they do in 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 has its changes made to it. You run the tests against it. If it goes green, you know that the entire application suits it and that works, and is ultimately deployable into the data center. A service oriented architecture or micro services architecture is instead of having a single consistent code base, you have a web of individual code bases in individual services that work together in the data center to deliver the application. An example of that could be in a monolith, you have everything in one code base but the 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 service that runs independent of that. And for a lot of firms, their move towards enhancing their continuous integration and continuous delivery capabilities is tied to a move from monolithic architecture, some micro services. Can you talk a little bit about that and the relationship between these two activities? Yeah. So oftentimes, when you start moving into a service oriented architecture, the importance of testing goes up dramatically. And 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 webs of services that need to work together an coordinate themselves in the data center to be able to deliver the service to customers. And 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 micro service architecture, your need for automation and your need for just greater and greater amounts of test coverage go up exponentially. Got it. And 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 or micro services? 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 green field, 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 a market fit, 99 times out of 100, you're best off building a monolith. And 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 a product market fit, as things start to mature, as your test volume gets bigger and your test gets slower, 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 case when you want to start thinking about moving from a monolith to a micro service architecture is you change something in one part of the code base and all of a sudden, something in a 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 sort of hidden complexity inside of your monolith that are best to start isolating in services. And as you start to isolate into services, what we see with customers is you 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 of that agility back and some of that speed back in your process, you usually go from one service to tens of services quite quickly. And 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 micro services. Thanks for joining us, Jim. Sure. Thanks for having me.
