Skip main navigation

New offer! Get 30% off one whole year of Unlimited learning. Subscribe for just £249.99 £174.99. New subscribers only T&Cs apply

Find out more

Jim Rose on monolithic architectures and microservices

Watch Alex Cowan interview Jim Rose on continuous integration and delivery.
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.

In this video, Alex interviews Jim Rose, CEO of CircleCI, on continuous integration and delivery. Alex asks Jim to describe the concept of continuous integration and continuous deployment to a product manager who is new to the topic. He says, “continuous integration and continuous deployment are basically end to end automation of the development process between the time a developer makes a change to code until the time that that code is a running application in the datacenter.” In your work and life experience, have you had exposure to continuous integration and delivery?

This article is from the free online

Digital Product Management

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now