It’s possible to containerize legacy monolithic apps by running your entire app in a single container. However, that’s not the point of containerization. It’s great as a start to use a single container for your entire app, but eventually you want to break out every part of your app and use a container for each. What you end up with then is a collection of services that are packaged in containers, which together make up your microservices application.
That all sounds neat. But how do you actually get from a monolithic app to a microservices app? That’s what we discuss in this post by outlining tips and strategies you can use to make the transition from monolith to microservices.
1. Rethink teams and infrastructure
In Gilt’s talk at AWS re:Invent last year, they described their previously monolithic application as being organized around technology capabilities.
This model is flawed because it builds walls between each function, and results in strong silos across the organization. The infrastructure layer of the application has its roots in the era of hardware servers, and the underlying nodes are the basic units to consider when developing your application.
Gilt’s transition to microservices required them to reorganize their teams and underlying infrastructure around business initiatives.
Teams become cross-functional, small, and independent. From large Dev, QA, and Ops teams, you now have tens or hundreds of teams of 3-5 people, each enjoying full ownership of a small part of the application.
Similarly, infrastructure is decomposed to be organized by application logic.
Each feature of the app gets its own database, libraries, and so on, and they communicate with each other using a REST API, or a more modern communication protocol like gRPC.
Reorganizing your teams and infrastructure in this way is a major change from the old way of building monolithic applications. But it’s worth the effort, and will enable development at a pace you never imagined possible before.
2. Support multiple languages
Martin Fowler was one of the first to talk about polyglot persistence. It means using more than one programming language, or data storage option for an application. This concept is gaining even more importance in microservices applications, as there is more variation and independence between different parts of the application.
The biggest advantage of this is that you can let your developers use the programming language they’re comfortable with to develop the service they’re building. Because each team works independently, they can make decisions on implementation, and don’t have to wait for consensus from an architecture team or from a manager.
In this post, Michael Brunton-Spall provides an example of how he and his teammates at Guardian were restricted by their Java background, and were unable to effectively solve a scalability problem that was affecting their app. They benefited from the new perspective of a new teammate who was a Python developer. Though the idea of having this “inconsistency” across teams may not appeal to some managers, the benefits it brings in out-of-the-box problem solving and autonomy are priceless.
3. Simplify infrastructure with managed platforms
Developers are given greater responsibility with microservices apps. As Werner Vogels famously said a decade ago about the Amazon team, “You build it, you run it.” For developers to take ownership of deploying their code, it would mean a different approach to infrastructure, one that puts less focus on the hardware and minute details of how the infrastructure is built and scaled.
Serverless platforms like Lambda are all the rage now because of how much control they put into the hands of developers without compromising the security and reliability of the app. By letting developers upload code as functions, without worry about how many servers to provision, which databases to configure, and how to stitch together the entire infrastructure layer, Lambda lets developers deploy code with ease.
Apart from Lambda, other platforms like the container services such as ECS, and Azure container service make it easy to run containers without having to manage the underlying nodes that power them.
4. Use a container orchestrator like Kubernetes
Unlike VMs, which require a lot of manual configuration and take time to initiate, Docker containers are ephemeral, and are meant to run for short time frames. The benefit of this is that you can create and destroy testing environments easily. In fact, with each commit, you can automate a series of build and unit tests to be executed by a CI server, and the entire process would happen automatically in a matter of minutes. By being so dynamic, Docker makes the pipeline faster—much faster.
However, containerizing your app brings its own challenges of scalability and availability. This is where a dedicated orchestration tool like Kubernetes comes in to provide replication control. It manages your list of containers in clusters, providing automatic failover for every node, even the master node. Additionally, leveraging a managed Kubernetes service like Wercker takes the pain out of an otherwise painful transition to microservices.
If you’re still struggling to keep pace with business requirements because of the monolithic structure of your application, it’s time to get ahead by adopting a microservices architecture. However, this is not an easy task, and can go wrong. By starting with your team structure and infrastructure, and then embracing polyglot persistence, you’ll have a good foundation. Further, by leveraging containers and a capable orchestration tool like Kubernetes, you’ll be off to the races. But to top it all off, you need to use a managed service for your infrastructure, especially for completely new components like Kubernetes, for which you may not have all the required expertise in-house. Keeping these pointers in mind will make your move to microservices seamless.
About the Author
Twain Taylor began his career at Google, where, among other things, he was involved in technical support for the AdWords team. His work involved reviewing stack traces, and resolving issues affecting both customers and the Support team, and handling escalations. Later, he built branded social media applications, and automation scripts to help startups better manage their marketing operations. Today, as a technology journalist he helps IT magazines, and startups change the way teams build and ship applications.
We’re hiring! Check out the careers page for open positions in Amsterdam, London and San Francisco.
As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using Wercker, be sure to tweet out your #greenbuilds, and we’ll send you some swag!