Jim Rose on monolithic architectures and microservices

Joining us is Jim Rose, CEO of Circle CI. Circle CI 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 microservices? This is a big topic that some product managers may encounter as they tune their interface to their development team. >> Sure, so a monolithic architecture is basically when you have all of the components of the application inside of a single codebase. So, it’s one piece of code that as a change is made to it, you run the tests against it. If it goes green, you know the entire application soup to nuts works, and it is ultimately deployable into the data center.

A service-oriented architecture, microservice architecture, is instead of having a single consisting codebase, you have a web of individual codebases and 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 codebase, but in 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 service that runs independent of that. >> And for a lot of firms their move towards enhancing their continuous integration continues delivery capabilities it’s tied to a move from monolithic architecture of microservices.

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 that 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 and 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. 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. 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 microservices? >> It usually has to do with the maturity of your business and the maturity of your codebase. 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 product 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 codebase gets bigger, as you find 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 is when you want to start thinking about moving a monolithic to a microservice architect is you change something in one part of the codebase, and all of a sudden, something in a completely unrelated part of the codebase 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 the 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 microservices. Thanks for joining us, Jim. >> Sure, thanks for having me.