A 2020 O’Reilly survey of more than 1,500 technology workers found that 61% of organizations have been using microservices for a year or more. However, 23% do not use microservices at all. Of those that do, 29% are migrating or implementing a majority of their systems using microservices.

In other words, application modernization paints a more complicated picture than the developer advocates on social media would have you believe. Many container-based microservice applications were built from legacy environments, and there’s a lot of migration to come over the next few years. On-premise bare- metal servers and monolithic applications are the starting point, and Cloud-Native Applications are the endpoint, but each organization plans its own route based on where it is now, its needs, and what is achievable.

Code

Writing and updating code for an application is an arduous task. Just getting it out the door is challenging. Pride of ownership causes many developers to wrap their arms around it and consider it “theirs.” This sense of ownership is fantastic, but there is often a dark side.

Murphy’s Laws tells us that eventually, a legacy application will have to be updated while the code owner is on vacation or otherwise unavailable. This leads to a classic Theory of Constraints scenario, where the team will have to choose between waiting for the owner or having someone
else work on it. The time will also come when the owner of the application leaves the company and is no longer available to even answer questions.

The new person who gets into the application could be in for a rude surprise. Custom code, personal comments, odd ordering, no comments, not using accepted syntax, and poor formatting can all turn simple tasks into detective work and make introducing automation almost impossible. Outdated Java could disable critical integrations on your website. If suddenly your website can’t provide services or collect payments, you’re damaging the business.