Suppose you have a situation where you have a complex monolithic system that is important to your business, you have read the relevant articles, and you want to migrate this system to a more advanced platform that uses microservices and containers, But don't know where to start.
If you are facing this problem, then this article will definitely help you. Next, I'll help you evolve your monolithic application into a microservice-oriented application, both in terms of best practices and areas to focus on.
Overview
There is no doubt that the "Greenfield Development" model, which is completely from scratch, starting with container-based cloud services, is the most ideal development model. However, for most development teams, this is not realistic. Most development teams support multiple applications that have been around for several years and need to refactor them with modern toolsets and platforms, often referred to as "Brownfield Development".
Not all application technologies can easily fit into containers. We can adapt existing applications to containers with some work, but the question arises: Is it really worth it? For example, you can indeed move an entire large-scale application to a container or cloud platform, but does this really significantly increase flexibility or reduce cost?
Evaluate all existing components
Evaluating the current state of the application and its underlying stack does not sound like a revolutionary or creative idea, but when you have fully evaluated all network and infrastructure components, you can say that you have achieved phased success . You don't necessarily have to go directly to the core of your application, and small, incremental steps are the best way to make it easier for your partners and support teams to use containers.
Examples of container-friendly infrastructure components: web servers (like Apache HTTPD), reverse proxies and load balancers (like haproxy), caching components (like memcached), and even queue managers (like IBM MQ).
Suppose you're in an extreme situation: if the application is written in Java, is it possible to have a lighter-weight Java EE container run in Docker without splitting the application? WebLogic, JBoss (Wildfly) and WebSphere Liberty are great examples of Java EE containers for Docker for this problem.
Clarify existing application components
Now that the containers at the infrastructure layer are up and running, the logical decomposition of components can now be found inside the application. For example, can the user interface be split out as a separate deployable application? Can part of the UI be tied to a specific backend component and deployed separately (such as a billing interface with billing business logic)?
There are two important considerations when combining application components into separate artifacts:
-
In a monolithic application, there are always shared libraries that are deployed multiple times in a new microservice model. The benefit of multiple deployments is that each microservice can follow its own update schedule. Just because a common library has a new feature doesn't mean everyone needs it, and everyone must upgrade immediately.
-
Unless there is a very obvious way to separate the databases (like multiple schemas) or the feature spans multiple databases, drop it. Monolithic applications tend to cross-reference tables and build custom views that typically "belong" to one or more other components, since the original tables are readily available and are admittedly fast in timeliness.
Next Steps: Business Improvement
If by this point you are done, have made some progress, and may have identified application components that can be split into separate deployable artifacts, it is time to redesign the application with business improvement as your first development path For smaller container-based applications, these will eventually become your microservices.
If you've made billing the first area you want to split from the main application, then you need to complete the required enhancements and bug fixes related to those application components. Once you're ready to release, deploy them and include the split in the release.
As the application continues to be stripped, your team will become more familiar with how to split components and put them into their own containers.
in conclusion
When a monolithic application is decomposed and deployed as a series of smaller applications using containers, it reaches a new level of efficiency. Scale each component independently based on actual load (rather than simply building peak loads), and updating individual components (without retesting and redeploying everything) will greatly reduce the time spent on QA and getting approval for change management. Thus, running small applications with different functions on containers will be the (more efficient) way of the future.
Original link: http://rancher.com/moving-your-monolith/