Application Modernization and containers
- 3 minutes read - 434 wordsI have just recently watched the keynote sessions of the current dockercon'16. It’s been very interesting and eye-opening. You can still watch the recordings here: https://2016.dockercon.com/ (original URL https://2016.dockercon.com/).
I do use Docker for some internal infrastructure deployments. It enables me to efficiently use a broad set of different application servers that form a deployment scenario for a complete solution.
One of the key themes I heard from the Docker conference are the topics around application modernization. This is quite interesting since one wouldn’t connect Docker with transformations of business applications to modern environments. I do think that the major theme of Docker makes sense and it is a viable approach to modernizing business applications. At least it helps to migrate these applications from one platform to another.
However, one of the caveats of this approach is the general dependency on the legacy environment and programming language it is written in. Let’s imagine you have a legacy application written in Cobol or MS Access. If you deploy this then into a container format, you can definitely gain advantages of using Docker. However, you still are dependent upon subject matter experts in these source solutions to update them and make changes as necessary. Typically, the biggest risk of maintaining these solutions is lack of documentation, slow pace of implementing new features and available resources with the appropriate skills to actually being able to maintain and implement new features and functionality. By simply re-hosting the application, you keep all the dependencies and restrictions from a software architecture perspective.
A much better approach in my opinion is to re-architect such a legacy application to a new target environment. This means to transform the application from Cobol or MS Access to maybe .NET or a cloud-native architecture such as Azure or Force.com. Sure enough, this is not a fast and easy approach, because a lot of analysis might be required in order to fully understand the application. Also, the detailed specification and software architecture of the new solution might be challenging. However, once re-architected, the benefits are very clear … you will get a new application based on current methodologies, frameworks and so on and are able to innovate much faster.
Keith Fulton (CTO, ADP) did a great presentation as part of the day 2 keynote and I really like his statement about speed of innovation. In our world where pretty much every company is a tech company, the key differentiators are who codes faster but also - and more importantly - who ships faster. This is key in such a very disruptive environment that we live in.