I don’t know about you, but by the time I figure out the answers, the questions have changed again. Over the years, I have built many apps using object-oriented programming principles and structured design techniques. But now I see many of those patterns being consigned the legacy status—being monolithic is not cool! “Monolithic” as in a single application (developed in Java, .NET, etc.) that has all the required functionality coded in it. Microservice has emerged as the architecture du jour, hence the pressing urgency to refactor those legacy apps, especially when migrating to the cloud. I am not here to contest that, although a bit of due diligence is always in order before hopping aboard the latest trend. Microservices stem from the same ideology as Agile and DevOps, seeking to break down slow-moving, monolithic systems into multiple small, independent services that are highly decoupled and self-contained to focus on a specific function or capability. This allows enterprises to be nimbler and compete more effectively with their smaller competitors.
Once you have established that you want to go the microservices route, what’s next? Here is a six-step approach for you to consider:
1. If your application is not yet in the cloud, but it is on the horizon, consider doing a simpler lift-and-shift migration (or the “forklift” migration, as some hyperscalers call it). This will enable you to easily benefit from several cloud-based features, such as autoscaling, monitoring, and automated deployment. These features will come into play subsequently when you start developing and deploying your microservices as containers.
2. Once your current monolithic app is running in the cloud, identify those parts of the app that are good candidates for being built or refactored as microservices. The plan being to gradually replace all portions of the old app with microservices over a period of time, using one or more alternative design patterns. For example, the strangler pattern incrementally incorporates a new application around the legacy application.
3. If you need to add new functionality to the app, consider building it as a microservice. That will keep your monolith from growing even more.
4. If a certain portion of the existing app is prone to evolve frequently, consider extracting that functionality into a separate microservice.
5. This is easier said than done, but try to split the presentation layer of your app from the business and data layers. This three-tier architecture has been popular for quite some time; you will not be reinventing the wheel.
6. Last but not least, look for solution accelerators to jumpstart your journey to developing and deploying microservices. At CTG, we have encapsulated our vast experience in developing microservices-based applications into a framework that accelerates application development as well as platform engineering.
Keep in mind, moving to microservices can alter the way people interact and how processes work. A microservice could encompass everything from the UX team to the database team, which could determine the way it couples with other microservices (the API). In fact, a microservice team tends to be fully autonomous, contrasting with the more established separate groups for UX, database design, development, and testing. So, don’t overlook the human angle when moving to microservices. Good luck!
Contact the CTG team if you need assistance refactoring your applications or developing microservices.
/1.%20Visuals/Website/Icons/x-twitter.svg){kind=icon}