Our Journey to a Microservices Architecture
December 16, 2019
The Digital Transformation that Made
Us (Even) More Competitive
When I first started working in software, I was working on an engine application that would translate objects into a query language for databases. This was a large, monolithic application, and I remember how difficult it was to update parts of the code – you can imagine the weeks of regression test suites we would run with every release.
As my team and I worked through weeks of rigorous merging, testing and release sign-offs, I remember thinking, “There has to be a better way to build software.”
From Monolithic To Microservices
Fast forward 10 years to my role as a Technical Product Manager at CoreLogic. We were working in partnership with Pivotal Labs, a company that provides resources to help enterprises run applications, to increase our speed to market. But, all the apps had one thing in common: They were monoliths.
Remembering the headache of releasing new features on a mature yet aging monolithic application, I began to panic. Monoliths are okay, but they need limits – just like a child with a sweet tooth and a 5-pound bag of gummy bears.
Enter the app continuum.
The App Continuum
The app continuum is an easier way to manage your application lifecycle without worrying too much about how it becomes a minimum viable product (MVP). The continuum provides a guide to refactoring your app, while adding features and iterating on your application’s maturity. Here’s how I like to use the app continuum framework.
It isn’t reasonable to scan an entire codebase looking for components. Drawing boundaries on the new features you and your team are tackling can help create parameters. Plus, small reusable components make great microservices – the more you isolate repeated calls, the more you see a path to building an application with microservices.
Having components also gives a clear description of how the API interface interacts with the application. It builds a lightweight app that exposes the component’s business logic through a restful API. This enables a microservice that can evolve independently without adding risk to the main application.
Think: Lather, rinse, repeat.
What’s the Catch?
If you look at the image above, you will see that one large application has become five small applications. You may wonder how this is easier to manage and less risky?
It’s easier to manage because volatility only affects the application that is changing, versus a monolithic application, which needs five times the number of changes in the codebase. It’s also less risky because the changes are localized to a smaller codebase and a change to the microservice will not affect the structure and stability of the original application.
The real catch, however, is that the applications are now talking to each other via an API. Once two applications are communicating, be careful not to disrupt the agreement. This agreement in request and response structure is called a contract, and it’s imperative to protect the microservice architecture. With the creation of more microservices, be careful that contracts stay intact.
By shifting your approach from monoliths to microservices, you can build a highly resilient and scalable ecosystem capable of accelerating your application development and focusing your refactoring.
For businesses interested in embarking on their own journey from monolith to microservices, you will have to pave your own unique way. Pull in your team from the very beginning and take this transformational step together. There are so many fun things to discover and learn along the way – you don’t want anyone to miss out on the journey.
Jeff Taylor has been with CoreLogic for 4+ years and currently leads the development of all CoreLogic Enterprise Services. Jeff brings 10+ years of Product Management experience in building large scale backend applications. His team is focused on serving the development community at CoreLogic by building services and instituting best software development patterns.