Why Non-Technical Business Executives Need To Know What Containers Are? Because your business depends on it.

As I go across the country talking to both customers and business partners, it has become apparent to me that very few people understand the fact that we are moving to a new computing model enabled by containers, which are the building blocks of cloud-native computing.

This paper is specifically written for senior, non-IT executives. Why would someone that is not a technologist need to care about this subject matter? The simple reason is that this technology enables innovation at hyper speed and scale and is the infrastructure of the digital economy as well as digital competition. In other words, if you are an established business, and you are worried about a new entrant into your market that is running circles around your company, and with lower costs, moreover, this competitor perhaps is significantly smaller than you are but much faster to seize market opportunities and attacks you with guerrilla tactics nibbling at your flanks; you can bet that they have likely built their business on what I am about to describe for you today.

Here is a non-technical way of describing the massive change that is happening in the market enabled by containers. In a pre-container model of computing, your applications are monolithic. What this means is that for you to change something, no matter how small, you must interact with all the code, and code dependencies of the application. Therefore, any change that you want to make to the monolithic application is extremely risky, especially when that application runs your business. As a result, these changes take a long time and very often, by the time you complete the change, the market has moved to a different focus making the change, in which you probably spent very significant sums of money and time, irrelevant. Incidentally, being in a position of always catching up could be an indicator you are not using containers.

When you containerize an application, on the other hand, you are breaking that monolith into very small components of logic that perform a certain function. These components are so small that we refer to them as microservices. What before was potentially hundreds of thousands of lines of code in a single monolithic application, become potentially hundreds to thousands of microservices each one with but a few lines of code. This process is called “Containerizing” an application. As a result, when you now need to make a change, you are not impacting all the code. You are simply updating one of these microservices, and the outcome is that you can potentially make an update in a matter of minutes to hours. The proof point is if you look at your mobile phone and you realize that some applications are updated every few days or every few weeks. The people that are updating these applications are most likely using microservices.

As you go beyond the architecture, microservices help you now make strategic decisions as to where you place your workloads for maximum efficiency, and security. Let’s imagine that we have an application that allows your customers to open an account, and you have now containerized that application into multiple small components of functionality. Certain components are mission-critical but also extremely sensitive to your business such as a back-end payment system. On the other hand, you may have a front-end component which is the one that customers interact with to enter their information. Of course, any corporate application usually interacts with a database at the back-end. In this scenario, it would make sense to deploy the component that touches a customer to the public cloud to facilitate and speed that workload and enhance the customer experience. However, the components that handle payments or the database should be kept behind the firewall in your data centre to ensure security. The need to mix public cloud components , with cloud-native components that must reside in your data centre, is why IBM has always advocated for the Hybrid Cloud model, which is a mixture of private cloud (which I introduced last week in this article) and the public cloud, all of it working as a single governed and managed ecosystem which gives you choice with consistency.

Because you now have the versatility of deploying small microservices rapidly, you also start to enjoy massive benefits regarding resilience, expandability and flexibility of the services that you offer customers. Specifically, what this means is, assume you need ten containers to support you during the year. However, you know that once or twice a year you are going to have a spike where you have to grow the number of containers by 10X, 20X, 100X. A containerized architecture managed by a robust enterprise-grade system like Kubernetes automatically deploys these containers to meet demand and moreover should one of them fail, Kubernetes automatically fixes the problem and gets a new container running.

For all these reasons, born-digital organizations have a distinct advantage because they are definitely exploiting these technologies, and my point to senior executives is that as a result of technology, your competitors operate with a different business model that is much faster, much flatter, has a significantly lower cost model, and can respond to the market almost instantly. However, the story doesn’t end there; it turns out that many customers are telling me that they feel pressure in the war for talent because the very best IT talent is demanding that they be allowed to use these technologies, and if they don’t get them, they leave. My point in writing this article is to start a conversation that I hope will be beneficial to your enterprise.

This video from IBM's Technical Education explains containers:

Thank you.

PS: Since writing this article, a client asked me to explain how to "Containerize" applications. My response is in this article [Click Here]