Container Orchestration: What Works
From “An Insider’s Guide to Cloud Computing”
Containers and container orchestrations generally live up to the expectations and hype. They offer cost-effective ways to build highly scalable and reliable applications on cloud or non-cloud platforms, and they provide portability within and between platforms. Vast ecosystems have grown around container orchestration, including security systems, databases, governance systems, operations systems, and other systems needed to meet specific requirements of an application that leverages this technology.
The ability to run containers that leverage redundancy, meaning either running cloned containers within a cluster manager or running more than a single cluster, provides both scalability and resiliency. Developers use containers to define an application that can solve business problems and then leverage container orchestration and clustering to effectively execute the containers and manage most aspects of the execution. Those magical capabilities are why most enterprises now choose container orchestration and clustering to build net-new cloud applications, as well as to redesign and rebuild applications to function on public clouds.
Of course, all this magic comes with trade-offs. Traditional development may still have more value over containers or container orchestration. Figure 5-4 depicts what most enterprises encounter when they adopt containers. The first trade-off is that, as mentioned earlier, containers cost more to build and deploy than traditional development approaches. It doesn’t matter if the application is net new or an application that must be refactored to move to a public cloud platform. There are exceptions, of course, but they are not the rule.
On the magical side of the argument, the longer the containerized applications exist, the more business value they can create. This is often preceded by a dip in value for the containerized applications as enterprises go through an initial learning curve. Eventually, the enterprise will find the value drivers of the containerized applications, such as portability, scalability, and resiliency, and the recognized value inflects as you can see with the value curve container-based development in Figure 5-4. At the same time, traditional development-based applications slowly reduce in value over time, much as they did in the past.
Figure 5-4. When comparing container-based development with or without orchestration and clustering, we must consider that the initial value is much lower due to the additional costs needed to build well-designed containerized applications. Over time the value increases and greatly surpasses that of traditional development approaches on clouds.
If you’re sold on containers and the value they can bring to the business, first consider the added costs and then the longer-term benefits container-based development will likely bring. Many just assume that containers will be the best way to go. Perhaps, but the value this technology can bring will not be consistent from application to application. The values of portability, scalability, and resiliency are not the same for each application.
As a rule, container-based application development costs more and takes more time. You’ll need skilled developers and architects to do a container-based application right versus more traditional approaches that we’ve leveraged for years. Do you have that talent on staff? One skill set is new; the other is not. New skills are usually more expensive to find, develop, and/or hire, and this is no different.
Keep an eye on the values when you do a business case. The additional build costs, staffing requirements, and learning curve of container-based applications remove value. Be prepared to put specific values on the benefits of scalability, portability, and resiliency. The value curve will determine if containers are worth it for your specific application or the enterprise itself. If you find the value, then containers will work for you.