See what makes Kong the fastest, most-adopted API gateway
Check out the latest Kong feature releases and updates
Single platform for SaaS end-to-end connectivity
Enterprise service mesh based on Kuma and Envoy
Collaborative API design platform
API and Microservices Security for Gateways, Service Mesh, and Beyond
Call for speakers & sponsors, Kong API Summit 2023!
3 MIN READ
This is the second of two blogs examining considerations for transitioning to a microservices-based architecture. For more information, check out our e-book Blowing Up the Monolith: Adopting a Microservices-Based Architecture. In our previous blog, we outlined the five questions we must consider before making the transition to a microservices architecture.
Now that we have a better understanding of the benefits and challenges of a transition to microservices, we need to understand how we make the transition from a technical perspective. There are three primary strategies we can adopt to transition to microservices – the Ice Cream Scoop, the Lego, and the Nuclear Option. Before we evaluate the pros and cons of each of these, we need to identify our boundaries and test. This process will be the same for any strategy we choose, but it’s important not to overlook as it will fundamentally shape our success as we dive into the transition.
To identify the boundaries of our monolith, we must first figure out what services need to be created or broken out from the monolithic codebase. To do this, we can envision what our architecture will look like in a completed microservice architecture. This means understanding how big or how small we want our services to be and how they will be communicating with each other. A good place to start is by examining the boundaries that are most negatively impacted by the monolith, for example, those that we deploy, change or scale more often than the others.
Testing transitioning to microservices is effectively a refactoring, and we need to take all the regular precautions we would before a “regular” refactoring. A best practice here is that before attempting any change, a solid and reliable suite of integration and regression tests are put into place for the monolith. Some of these tests will likely fail along the way, but having well-tested functionality will help to track down what is not working as expected. With our testing and boundary identification completed, let’s look at our three strategies for transitioning to microservices.
While transitioning to microservices will always require substantial effort, choosing the correct strategy for your organization can substantially reduce friction during the process. No matter which strategy we choose to make the transition, it’s critical that we effectively communicate expectations and requirements to team members. With a clear strategy outlined and agreed upon, we are well on our way to blowing up our monolith and reaping the benefits of a microservices architecture.
Share Post
Join us as we explore the history, advantages and key considerations of transitioning to microservices.
Register For The Webinar