Containers
Not surprisingly, the most popular way to experiment with containers and experience the full cycle of development and delivery with them is to write an application or two and experiment. However, a lot of developers get trapped in this dichotomy and only want to pursue this path to adopt containers and not consider other options. Maybe because it is much easier to get started this way and perhaps they get an empty canvas to create the next masterpiece.
Sometimes fiddling with critical business applications is not an immediate choice. Maybe because: There aren’t enough people around who know the details, There are too many touch points that will make it fragile to touch the code for even slightest of modifications, There is a lot of business logic in stored procedures or There aren’t good test harnesses that provide enough coverage for us to know that modification in one (or few) part or component doesn’t break something else.
In the last article of the series, I covered some of the reasons why planning to migrate all or part of existing application portfolio to containers can be instrumental in accelerating innovation cycle. I also talked about common pitfalls and try to dispel some myths. Now lets examine the journey to container migration and patterns that can help you make informed decisions. I have seen three distinct patterns in container adoption so far.