• The API Platform for AI.

      Explore More
      Platform Runtimes
      Kong Gateway
      • Kong Cloud Gateways
      • Kong Ingress Controller
      • Kong Operator
      • Kong Gateway Plugins
      Kong AI Gateway
      Kong Event Gateway
      Kong Mesh
      Platform Core Services
      • Gateway Manager
      • Mesh Manager
      • Service Catalog
      Platform Applications
      • Developer Portal
      • API and AI Analytics
      • API Products
      Development Tools
      Kong Insomnia
      • API Design
      • API Testing and Debugging
      Self-Hosted API Management
      Kong Gateway Enterprise
      Kong Open Source Projects
      • Kong Gateway OSS
      • Kuma
      • Kong Insomnia OSS
      • Kong Community
      Get Started
      • Sign Up for Kong Konnect
      • Documentation
    • Featured
      Open Banking SolutionsMobile Application API DevelopmentBuild a Developer PlatformAPI SecurityAPI GovernanceKafka Event StreamingAI GovernanceAPI Productization
      Industry
      Financial ServicesHealthcareHigher EducationInsuranceManufacturingRetailSoftware & TechnologyTransportation
      Use Case
      API Gateway for IstioBuild on KubernetesDecentralized Load BalancingMonolith to MicroservicesObservabilityPower OpenAI ApplicationsService Mesh ConnectivityZero Trust SecuritySee all Solutions
      Demo

      Learn how to innovate faster while maintaining the highest security standards and customer trust

      Register Now
  • Customers
    • Documentation
      Kong KonnectKong GatewayKong MeshKong AI GatewayKong InsomniaPlugin Hub
      Explore
      BlogLearning CentereBooksReportsDemosCase StudiesVideos
      Events
      API SummitWebinarsUser CallsWorkshopsMeetupsSee All Events
      For Developers
      Get StartedCommunityCertificationTraining
    • Company
      About UsWhy Kong?CareersPress RoomInvestorsContact Us
      Partner
      Kong Partner Program
      Security
      Trust and Compliance
      Support
      Enterprise Support PortalProfessional ServicesDocumentation
      Press Release

      Kong Advances Konnect Capabilities to Propel Today’s API Infrastructures into the AI Era

      Read More
  • Pricing
  • Login
  • Get a Demo
  • Start for Free
Blog
  • Engineering
  • Enterprise
  • Learning Center
  • Kong News
  • Product Releases
    • API Gateway
    • Service Mesh
    • Insomnia
    • Kubernetes
    • API Security
    • AI Gateway
  • Home
  • Blog
  • Engineering
  • So You’ve Decided to Transition to Microservices, What Now?
Engineering
June 26, 2018
3 min read

So You’ve Decided to Transition to Microservices, What Now?

Mike Bilodeau

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.

  1. Ice Cream Scoop Strategy
    This strategy implies a gradual transition from a monolithic application to a microservice architecture by "scooping out" different components within the monolith into separate services. Given the gradual nature of this strategy, there will be a period where monolith and microservices will exist simultaneously. The advantages of this are that our gradual migration reduces risk without impacting the uptime and end-user experience. This gradual transition, however, is also a drawback as the process will take longer to fully execute.
  2. Lego Strategy
    This strategy entails only building new features as microservices, and it is ideal for organizations that want to maintain their existing monolith. Using the Lego strategy will not resolve issues with our existing monolithic codebase, but it will fix problems for future expansions of the product. This option calls for stacking the monolithic and microservices on top of each other in a hybrid architecture. The primary advantages here are speed and reduced effort due to not needing to do much work on the monolith. The primary disadvantages are that the monolith will continue having its original problems and new APIs will likely need to be created to support the microservice-oriented features. This strategy can help buy time refactoring, but it ultimately risks adding more tech debt.
  3. Nuclear Option Strategy
    Our final option is rarely used. The Nuclear Option requires rewriting the entire monolithic application into microservices all at once. We may still support the old monolith with hotfixes and patches, but we would build every new feature in the new codebase. The main advantage is that this allows the organization to re-think how things are done and effectively rewrite the app from scratch. The disadvantage is that it requires rewriting the app from scratch, which could create unforeseen issues. The Nuclear Option may also inadvertently cause "second system syndrome" where end users will need to deal with a stalled monolith until the new architecture is ready for deployment.

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.

Topics:Microservices
|
API Design
Powering the API world

Increase developer productivity, security, and performance at scale with the unified platform for API management, service mesh, and ingress controller.

Sign up for Kong newsletter

Platform
Kong KonnectKong GatewayKong AI GatewayKong InsomniaDeveloper PortalGateway ManagerCloud GatewayGet a Demo
Explore More
Open Banking API SolutionsAPI Governance SolutionsIstio API Gateway IntegrationKubernetes API ManagementAPI Gateway: Build vs BuyKong vs PostmanKong vs MuleSoftKong vs Apigee
Documentation
Kong Konnect DocsKong Gateway DocsKong Mesh DocsKong Insomnia DocsKong Plugin Hub
Open Source
Kong GatewayKumaInsomniaKong Community
Company
About KongCustomersCareersPressEventsContactPricing
  • Terms•
  • Privacy•
  • Trust and Compliance
  • © Kong Inc. 2025