In our first two container articles, we talked about the architecture and the deployment of container solutions. We'd now like to tackle the topic of application transformation. This article was written together with our partner company – Skillbyte. Skillbyte provides services in the areas of DevOps & Cloud, Big Data and Analytics, as well as software development.

But let's get cracking with the actual topic: In application transformation, companies are pursuing two extreme directions... and, of course, as always in IT, there is a large grey area in between. Some companies want to transform all existing applications and to develop new applications exclusively as containers. Others are still cautious and decide on how to deal with an existing or new application on a case by case basis. In both scenarios, however, the question arises as to whether ANY application can run in a container.

Let's have a look at the obvious advantages of a container:

- Container images contain all the libraries and artefacts an application needs at runtime. Unlike traditional virtualisation technologies such as Hyper-V or VMware, however, container images do not host a complete operating system. They use large parts of the host operating system. That's why they are lighter than regular VMs and start up much faster. As a result, host resources can be used more efficiently which in turn means that more applications can run on one piece of hardware --> Saving of server capacity

- Because the container has everything it needs at run time, it can run on other hosts without any problems. To a certain extent it is even possible to move the container to another operating system. This is similar to the Java paradigm: 'Write Once, Run Everywhere' --> Increase of portability

- Containers run in isolation and can thus run in parallel with several other applications on one host --> Reduction of compatibility problems thanks to libraries

- Containers can be automated, deployed and scaled more easily --> Reduction of deployment times

- Containers are 'immutable'. The idea is that changes like patches, the adding of new libraries, etc. always results in a new image. This reduces the risk of diverging servers significantly. The maintenance of large server farms is simplified substantially from the perspective of the administrator --> Reduction of administration complexity

Where it gets really interesting is with applications that are subject to enormous resource fluctuations. A classic example of this is the WebShop which is frequented higher, for example, due to a promotional campaign or a special event. In this case, container technology can help to scale the application easily, automatically and within seconds. This sounds simple and usually it is – providing a few conditions have been created. Thus, the architecture of the application must always be designed with scalability in mind.

Container technology is a new paradigm that applies not only to operations, but also to software development (keywords: DevOps, GitOps, 12-factor-app, etc.). The migration to an agile, automated, modern infrastructure requires experts. The landscape of tools and approaches is large and characterised by constant change. Then again, there are fantastic, positive changes in the speed of software releases, increased security, cost savings, faster adaptation to market conditions, etc. The theorem 'It is not the big ones who eat the little ones, but the fast ones who eat the slow ones' has never meant as much as it does now.

To make it easier for companies to migrate to container technology, companies have come up with automatisms to move existing applications into docker containers, e.g. Docker MTA, Image2Docker, etc. The marketing message is to migrate 'without rewrite code' or changes to the applications. We consider this approach to purely be a marketing campaign as technically, it cannot work. A monolith is and remains a monolith, even if it runs in a container. The test and release cycles remain the same, because the complexity is part of the monolith. For most 'porting projects', the point is rather to break the big ones into small parts precisely to reduce that complexity. This way, smaller and more agile teams are created that are only responsible for specific parts of the application.

Imagine you're using A/B testing to test two versions of a call-to-action button to see which versions get you more conversions. In a monolith, the build and deployment are so complex, buggy, and slow that such tests are refrained from because they're just too expensive. But if you have broken down the software into meaningful parts, the frontend code can be built and deployed independently of the rest of the software.

Furthermore, the container is the smallest technical unit of a more general change, a new culture of approach. Automating something with 'magic' without understanding what exactly happens is not recommended. Contexts need to be understood and decisions made sensibly.

At TEAL Consulting and Skillbyte, we help you understand these complex landscapes, find the right approaches for your specific use cases and make the right decisions. If you like, we also provide support in the implementation of the migration, consulting, but also hands-on assistance.

In summary, we find that there are huge benefits in containerising a large number of applications. In principle, any application can be transformed. Even if the code doesn't provide dynamic scaling, resources on the host can still be saved.

Before companies start large migration projects to transform a variety of existing applications, it is worth analysing them more closely. It is recommended to start with the web and less complex applications. This ensures, on the one hand, that first successes are achieved quickly and, on the other hand, that, above all, experience can be gained.

But how exactly do you proceed to transform existing applications? Together with Skillbyte, we have developed a procedure in which, depending on the customer know-how, knowledge is first built up and then an existing application is transformed.

After about a month*, we transferred a sample application from your environment into a modern cloud native version with you which you can operate on-premises or in the cloud.

If we can help you with the application transformation or if you need more information, feel free to contact us via This email address is being protected from spambots. You need JavaScript enabled to view it.

*The phases can vary greatly depending on the size of the application. The goal is to introduce your employees to the topic and to bring the benefits of the new technology closer.