A Practical Guide to the Journey from Monolith to Microservices

More developers are keen on practices in terms of how they modernize monolith application into microservices easier, quicker, and smoothly. There are many microservices development frameworks such as Spring Boot and Linux container, container orchestration tools make it faster for your Microservices journey. When you develop a brand new application on top of Microservices architecture with this nice framework using an Agile methodology, it would be a perfect opportunity to make it happen without unexpected issues.

However, if you have to migrate or modernize your current monolith application to cloud-native or microservices application on top of Linux containers. That will be the real problem for most enterprise developers where they need to live in the cloud world.

The safe, easy way we approach to migrate and modernize applications is that we should separate 2 different methods for them. Let’s begin modernizing existing applications as below:

• Reuse existing functionality and data as much as possible
• Move existing workloads to a modern deployment platform
• Apply new processes, products, and technology to existing apps

Secondly, you get started to develop a new application as below:

• API-centric polyglot microservices architecture
• Autonomous development teams
• Agile development, continuous deployment, DevOps culture
• Containerized & orchestrated cloud deployments

Optionally, You want to consider rehost(aka lift & shift) for smaller or frozen application via small footprint application runtimes such as Spring Boot, Vert.x, Node.js, MicroProfile, JBoss EAP, etc.

When you’ve done about lift & shift for rehosting, you want to replatform(aks lift & reshape) for highly scaled and high rate of change applications.

I’d like to share one of my customer’s success story when they adopt this approach and what their practices are for the fast monolith as below:

• Refactored to REST and JavaScript
• Adopted enterprise container platform
• Automated testing via open source tools
• Redefined Dev and Ops boundaries
• Continuous deployment pipeline
• Zero downtime release to production
• Release cycles from 3 months to 1 week

Another recommended practice to modernize enterprise applications is to strangle the monolith.

Strangling means incrementally replacing functionality in applications with something better(cheaper, faster, easier to maintain). As functionality is replaced, “dead” parts of monolith can be removed/retired. It includes new functionality during strangulation to make it more attractive to business stakeholders.

More importantly, you have to ask for yourself, your team & organization why you want to modernize from monolith to microservices at this time.

• What is your overall business objective for app modernization like biggest perceived risks?
• How much are you spending on app maintenance like lack of automation/IT standardization often the culprit?
• How long does it take to get changes into production and what is your success/fail ratio?
• How about the current skill set and do you need training on newer technology before modernization?
• Regulatory & compliance requirements such as regional CCSP workloads, data sovereignty?

Conclusion

Application development teams are evolving their process, platform and architecture to meet modern business challenges. There are multiple technical solutions for application modernization depending on resources, regulations, and risk. In order to move faster than others, you should follow the path of modern application development that is called “DIGITAL DARWINISM” as below.

Besides, you keep in mind to build a new digital architecture along with asynchronous, event-driven, anti-fragile, scalable, serverless, polyglot, reactive, microservices, agile, velocity features.

This article originated from http://www.linkedin.com/pulse/practical-guide-journey-from-monolith-microservices-daniel-oh/