We cover the initial analysis and prep for a microservices transition; tips and best practices related to the process of splitting monolithic apps into …
Join the DZone community and get the full member experience. A lot has been written about microservices; when to use them, what advantages they provide, and how fantastic life is after adopting them. You may want to consider this architectural approach when your backend is going beyond trivial and you expect the features you are providing to grow, change quickly and become mission-critical if they are not already. However, there are still high chances that you end up working in an organization or project where monolithic architecture is still dominant, for a variety of reasons: We will go through the initial analysis and preparation for a microservices transition, provide tips and best practices related to the process of splitting your monolithic applications into microservices, and comment about the adoption of some technologies and processes that will help future-proof your solution in a world of constant changes. The learnings and opinions written here are inspired by practical experience in large CMS-based web applications/mobile app backends developed and maintained by DMI within the Mobile App Development practice. Most of the ideas could also be applicable to other kinds of applications such as e-commerce solutions, finance, etc. Typically the initial architecture you may encounter is a monolithic one, perhaps even some small collection of different monolithic applications, in a service-oriented architecture. Perhaps these monoliths already communicate with each other using APIs. Assuming you already made the decision to transition to a microservices architecture and you know why (otherwise there is plenty of literature about the topic), you can probably envision the final picture where you would want to go: A large collection of loosely coupled small pieces (microservices), running independently, communicating among them with APIs or messages, encapsulating some domain logic and data, etc. There is no trace of the original monolith(s) since all the functionality has been implemented in a smarter way in small microservices. I am sorry to tell you that this picture is wrong. This is the picture you would draw if you started the implementation from scratch, and although it can be helpful as guidance, you should not get obsessed with it since it is probably not cost-effective to reach there. If you are dealing with a large existing monolithic application developed over the years, the monolith typically will contain lots and lots of functionality which, although necessary for the business, probably there is no point in making the effort to replicate it in the form of microservices. If you could stop the business for one or two years and reimplement the whole thing again using microservices, then it would make sense to get rid of the monolith completely, but in real life the business cannot stop, and the business is normally about implementing new features on top of the existing. Only some of the monolith functionality will be worth extracting in microservices, generally: So, you need to embrace the idea that the monolith is probably not going to disappear any time soon. Your application will be running under a hybrid architecture of monolith + microservices for some (potentially long) time, and you will be deciding what needs to be extracted to a microservice and whatnot depending on where the business is going over the next months or years. Your focus should not be on the ideal final picture, but the transition process itself. This is a challenging enough endeavor, to be able to evolve the architecture without affecting the business, keep releasing new features regularly and minimize or avoid completely any kind of downtime. The very first step you should be taking is to embrace container technology. The biggest difference between a service-oriented architecture and a microservice-oriented architecture is that in the second one, the deployment is so complex, there are so many pieces with independent lifecycles, and each piece needs to have some custom configuration that it can no longer be managed manually. In a service-oriented architecture, with a handful of monolithic applications, the infrastructure team can still treat each of them as a separate application and manage them individually in terms of the release process, monitoring, health check, configuration, etc. With microservices, this is not possible with a reasonable cost. There will eventually be hundreds of different ‚applications,‘ each of them with its own release cycle, health check, configuration, etc., so their lifecycle has to be managed automatically. There may be other technologies to do so, but microservices have become almost a synonym of containers. Not only Docker containers manually started, but you will also need an orchestrator. Kubernetes or Docker Swarm are the most popular ones. My advice is that you adopt containers and choose an orchestrator as soon as possible before you start touching one single line of code related to microservices implementation. Your first milestone should be to be able to release your monolithic application(s) inside a container each and run all these containers in a cluster instead of having dedicated virtual machines for every application, which is the typical way monolithic applications are run. Notice this is applicable to monolithic applications for which your organization owns the source code and there is active development going on, but it can also be applied to third-party applications that are part of your application stack, as long as you have the ability to configure them. Some of the ideas I will express next are based mostly on my experience with Docker Swarm and Kubernetes, but they could be applicable to other orchestrators. In order to embrace containers, before you even think about microservices, you need to do two things: Let’s see these steps in more detail. This will require you to change your build process so that the output is a container, for example, a Docker container. Before doing that, you might have been packaging your application in the form of a WAR file (for example, for Java web applications), or in a ZIP file that contains a Node.js application inside, or whatever other format. After the build, these output artifacts are published and stored in some repository (for example, Nexus) and they are deployed to the servers where the application runs using whatever deployment tools you are using. For example, a WAR file would be copied to some server with Tomcat or Jetty installed in order to complete the release process, or the Node.
