Monolith to Microservices: Is Your Organization Ready?

Transitioning from a Monolith to a Microservices architecture can take years to complete. The internet is full of stories of companies famously making this transformation. But how do you know if it’s right for your organization? Is your organization ready?

In this article, we will look at five questions you can ask to see if you’ll benefit from a Microservices architecture. We’ll also discuss five challenges you will face during this transformation. In part II of this series, we’ll look at strategies for moving from a Monolith to Microservices.

There will be one prevailing theme during this process: change. Can your executive team stay focused on a long-term, company-wide transformation long enough to see it through completion? Like any large project, it can take years to complete this transformation, can your organization continue to allocate resources to this project while managing other company initiatives? Have you successfully implemented other large-scale changes? If so, your transformation will likely be a success. Determining your organization's readiness is an essential part of mapping out your implementation plan.

Benefits of a Microservices Architecture

You shouldn't adopt a microservice architecture simply because it's trending, but because your organization needs the specific benefits this type of architecture provides. Is your company ready for these benefits?

1. Team autonomy - Microservices are loosely-coupled independently deployable services. They are resilient to failure and are elastic. Does your organization have experience with independent teams? Deploying a Monolith is usually a coordinated effort across teams and departments. Autonomous teams are the exact opposite. Teams should own a service from inception to retirement; they build it, deploy it, and support it. 
2. Faster time to market - Can your organization optimize for both time to market and compliance/regulation? Is your company in a competitive industry where getting to market first is mission critical? That may sound obvious but “time to market” isn’t always the highest priority.
3. Improved system reliability - Does your system have issues with reliability? Where does reliability fit into your overall strategy? An error in a Monolith deployment can take down the entire system. An error in a single Microservice should only impact part of your system, if at all. 
4. Scale teams faster - By leveraging team autonomy, Microservices enable you to scale teams faster. One approach to growing teams is to split an existing team into two; one takes a few services, the other the rest. Now you can add people to both teams and they can each implement different parts of the system, independently.
5. Flexibility to adopt new technologies - By breaking up your Monolith, each service is only bound by its API. This frees up the team to use the right technology for the job at hand. Perhaps your original codebase was in Java, now you can have some services in Java and others in Python or NodeJS. Teams can use different databases. Some may use NoSQL, others an RDBMS while others just Redis or ehcache.

Is Your Organization Ready?

Determining if your company is ready to adopt a Microservice architecture can be tricky. If you and your coworkers are excited about this approach to designing and deploying software, then it can be difficult to be objective about the state of your company's readiness. Here are five questions to ask:

1. What’s your culture? - What is your organizational culture? Ron Westrum defined three organizational cultures and Jez Humble popularized these classifications in the book Continuous Delivery. The three cultures are: Pathological, Bureaucratic, and Generative. Here’s a quick test to determine your work culture. Ask the question, “how are messengers” handled by your organization? When bad news is delivered, how does your organization react? If the “messenger is shot”, then you have a pathological culture. If the “messenger is ignored”, then you have a bureaucratic culture. Finally, if the “messenger is trained”, then you have a generative culture. If your company is generative or moving towards a generative culture, then a Microservices architecture might be a good fit for you.
2. What’s your Dev and Ops maturity level? - Do you have unit tests and integration tests? Does your operations team support scripted deployments? What about Infrastructure as code? Do you have standards for how to do a code review? How about a version control system workflow? If you have mature development and operations practices, then a Microservices architecture might be good for you.
3. Is automation a core practice? - Do you have a Continuous Integration system? Can you spin up infrastructure with scripts or tools like Terraform? Is there a general culture of automation? If you do it twice, do you automate it? A Microservices architecture needs a lot of automation. After all, you are deploying multiple services many times a day. 
4. What’s the state of your application monitoring? - This is a critical component of a Microservices architecture. Can you easily pinpoint performance problems and errors? If something fails in any environment, do you know how often it happens? What code caused the error, and what about the code commit introduced this change? Can you compare today’s errors with historical norms? Rollbar is a great tool that can help answer these questions quickly. Does your development and operations teams know how to use your logging software? Do they use your current infrastructure to troubleshoot problems today? 
5. Will you reap the benefits of a Microservices architecture? - Do you want team autonomy? Does your organization want to build services quicker and get to market faster? Many will say yes to these questions only to implement a process that takes weeks for applications to be deployed to production.

Challenges of a Microservices Architecture

Before you start diving into implementation, here are five challenges to consider when designing your system:

1. Distributed Communication - In a Monolith, most communication is in-process. This means that a class/function in one part of your codebase invokes a method/function in another part. It’s fast and easy, and since it’s one big codebase, providers and consumers are updated when you refactor an API. In a Microservices architecture, communication is inter-process. This means each service is running in a different environment, sometimes on different HW and operating systems. Because communication is over the network, now you need to be aware of issues like the fallacies of distributed computing.
2. System Latency - Similar to communication, now that services are distributed, latency is introduced into your system design. Many factors can impact latency such as network placement, the number of services involved in processing a request, a services system load, and network speed. With a Microservices architecture, you need to monitor system latency and understand how your portion of the system is operating and how it impacts other services. 
3. Distributed Transactions - With a Monolith you can have Atomicity, Consistency, Isolation, Durability (ACID) transactions. Now that your services are distributed, you won’t have ACID transactions. To implement something similar in a Microservices architecture, you’ll want to look to design patterns like SAGA.
4. Multiple services to debug an error - How do you debug issues across services? How do you know where a request started and where it failed? Two items can be useful here: correlation IDs and error tracking tools like Rollbar. Correlation IDs are a unique identifier assigned to any message entering your system, if it doesn’t already have one. This ID is propagated between every service and included in your log messages. You can use this ID when searching across all logs of your system. Secondly, error monitoring tools allow you to tie the correlation ID into your error and stack traces. These tools also capture additional information about the execution environment such as the client device, payload, local variables and more. These two items together can help you quickly pinpoint errors. 
5. Multiple services instead of one monolith - Instead of deploying your Monolith you will now be deploying multiple services. It’s worthwhile looking at your current deployment processes. Until your deployment process is streamlined, deploying more services may exacerbate your dev and ops teams.

Conclusion

As you can see, moving to a Microservices architecture is decidedly all about change; a very specific and multifaceted change, but change nonetheless. While this isn’t an exhaustive list, if all of this seems viable, great—you are ready to start planning your organizational transformation. In our next post, we’ll look at the 10 best practices and 10 items to consider for implementing effective Microservices. Learn more about the differences between a monolithic architecture and microservices architecture.