By on June 12, 2018

Thinking of Moving to Microservices? Five Questions You Need to Answer


This is the first 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.


Making the decision to transition from a monolithic architecture to microservices cannot be taken lightly. The time and resources needed to undertake a move to microservices are substantial, and it’s essential to carefully weigh the pros and cons before blowing up your monolith. When debating whether to make the transition, it’s important to take a holistic view of how microservices will impact your organization. Though there are clear advantages to microservices, such as improvements in performance, ease of deployment, and scalability, some characteristics of a microservices architecture can also support maintaining a monolithic architecture.

When considering making the shift to microservices, be sure that you can confidently answer the following five questions:

  1. What are Your Goals?
    As a first step, you should make sure that a microservices-oriented architecture aligns with your organizational goals. Make a list of the key objectives and initiatives you hope to accomplish. For example, you may want to free up resources, increase flexibility in deploying or updating applications, or better ensure scalability. These goals will provide the backbone for making the decision whether or not to move to microservices.
  2. What are the Pain Points and Boundaries?
    With your goals outlined, identify the biggest pain points and boundaries within your monolithic codebase. View your monolith as a collection of services and note which aspects pose challenges to achieving your goals. For example, your monolith may limit flexibility in deploying applications due to the length of the development cycle. While doing this, avoid spending too much time “sizing” these services as it pertains to the amount of code behind them. There is always going to be time in the future to decouple services even further as you learn the pain points of building and operating under this new architecture.
  3. How Will Microservices Help Achieve Your Goals?
    Now that you have a good view of the issues caused by your monolithic codebase, you can map the benefits of Microservices directly to your organizational needs. For example, we can draw a line to the greater flexibility offered by microservices in deploying or updating the application thanks to shorter and more focused development cycles. This carries over into a far more efficient overall application development process, which frees up resources. With the anticipated benefits well understood, you can make a compelling case and gain organizational buy-in.
  4. Are You Resourced Appropriately?
    As you consider transitioning to microservices, it’s important to keep in mind that your existing business will still be running and growing on the monolith. To avoid interruptions and unforeseen complications, your organization must simultaneously maintain the old codebase and work on the new one. An effective method of doing this requires creating two teams to split the work. Doing this, however, means that a keen eye must be kept on resource allocation. A common side effect of this split workload is friction across the two teams, since maintaining a large monolithic application is not as exciting as working on new technologies. This problem can be more easily dealt with in a larger team, where team members can rotate between the two projects.
  5. What is the Time Horizon?
    From the considerations above, it’s clear that transitioning from a monolith architecture to microservices cannot be done overnight. It’s essential that expectations for the undertaking are managed appropriately across the organization to avoid frustrations or resource conflicts. Implementing a microservices architecture provides numerous benefits, but it’s not a quick fix. As you build out your transition plan, be conservative in estimating the amount of time it will take. When in doubt, overbudget time in order to avoid missed deadlines and frustration among team members.


As mentioned, a common driver for moving to microservices is the argument that maintaining a monolithic codebase is inefficient and hinders the organizational pursuit of business agility. However, this does not mean that transitioning to microservices will be easy. Check back for our next blog where we’ll examine the tactical aspects of transitioning from a monolith to microservices.