Mention Flickr to anyone familiar with DevOps, and they will surely recall that the company has become well known in certain circles for 10+ deploys per day. The containerization which this company has, allows it to deploy quickly and scale rapidly, responding in an agile way to business needs. Not only Flickr, but other companies including Uber, Facebook and other application-running software companies can benefit from this agility.
For the Fortune 2000, this deployment model is virtually impossible. With established brands, large customer bases and huge install footprints, the cost of taking their applications offline and refactoring is a huge undertaking. However, as times change, consumption increases and mobile, tablet and Internet of Things (IoT) technology takes over, these large businesses have to adapt. They are seeking the scale that microservices running in containers, orchestration and CI/CD can bring, but they are unable to refactor the large applications which need to be running 24/7 for their global audience.
Below are the top 3 considerations for software architects when they start the analysis process of refactoring monolithic apps for microservices:
Where to break apart the design
The first problem that needs to be solved is identifying what areas and functions should be independent of others. For example, a Java EE order system that encompasses customer data, products and services, orders, inventory and pricing groups together a huge volume of data. It is essential to locate the appropriate points where the services can be broken apart as independent services.
Things which can help you in your consideration include questions such as:
What areas need to be refactored first?
Are there areas that can be naturally separated?
Are there services that can break out and use a different tech stack to ease in support?
For example, in an e-commerce app, the order entry screen could be written in a more UI-friendly way. In this case the UI can be broken out and written in NodeJS, separate from the remaining Java code. The change to the monolith would be to call the new broken out service instead of the encapsulated legacy code.
How and where to maintain the needed states of an application
This includes storing information so that the service can be stateless and follow the scaling to be highly available and ephemeral. For example, in an order entry application, the users’ current status of the order needs to be maintained including details relating to the items currently in the order, the prices of those items, quantities and the user’s progress in the checkout process. If the user decides to close down the browser or disconnect, these details should be maintained. Also in high availability situations, there could be several instances of the service running at the same time. The load balancer should be able to pass along requests to instances that have more throughput available. To enable this, the session information for the user would need to be shared across all the instances. This data can be cached in a tool like Redis and then accessed by all the instances of the order service application.
How to mature the pipeline so that there is continuous integration and delivery.
Make sure the tests are robust and reflect a high coverage area. Not all monolithic applications will be completely replaced with an updated microservice design. The application team will be breaking down the monolith into smaller independent pieces. For this to happen, there is a need to robustly test and integrate each of the pieces so that the functionality and stability of the resulting application is maintained and even improved. The challenge with this is more like a shift in mindset than an architectural change, but it can be overcome.
This shift means that developers (or automation testers) can have non-functional (or non-feature) changes that would provide an overall enhancement to the application experience. If there are areas that continuously prove to be a support problem, integration tests, unit test and health checks can be developed and integrated to improve the stability and performance of the application. This wouldn’t add any new features from the user’s perspective, but it will allow new changes to be released without draining the resources to support the changes. This is a major DevOps concept and will snowball as it allows more resources to be available in the future for improving functionality.
Conclusion
The DevOps market is growing. As businesses are finding significant benefits in refactoring their applications, the number of businesses expected to use this approach is set to expand nearly 20% over the next five years. By finding natural breakpoints, ensuring state, and gradually integrating a DevOps mindset, enterprises can make the transition from monolithic to microservices for their existing applications.
About the Author
David Ford is a Software Architect, Docker Certified Associate, DevOps Skills Association Coach, and architect of Stone Door Group’s Microservices Accelerator, a solutions offering that helps companies start their application refactoring journey. David serves as a mentor, coach and architect to mature enterprises who need to transition to a DevOps culture. He is part of an army of Stone Door Group consultants who have spent countless hours helping customers execute on their digital transformation initiatives. Click here if you’d like to chat about your DevOps journey.