software & applications
The genesis of the orchestration platform in practice begins with a company that started using containers at a massive scale , and therefore had the need for container orchestration , well before docker saw the light of day : Google . Everything at Google has traditionally been implemented using containers and , as Google needed to scale and combine these services , it also invented a container orchestration engine . The lessons learned from its inhouse container orchestration tool led to the design of the next-gen tool , which Google open-sourced . Over time , and in collaboration with others , this now is known as Kubernetes , effectively the defacto standard in how organisations manipulate and manage Linux container deployments at scale .
How does this matter to you ?
So now that we know why we need container orchestration , what it does and where it started , it ’ s important to understand what aspects of orchestration matter specifically to your organisation . Will you be running tens of thousands of Linux containers as complex , composable applications ? Are you eager to integrate a container platform with your existing systems ? Is rapid innovation a key driver for your technology strategy ?
Since the introduction of the docker and Kubernetes projects , many other container orchestration technologies have also emerged , offering similar capabilities with different levels of nuance and community / ecosystem support . But outside of the technological differences , there are four broad categories that enterprise IT decision makers need to assess before they should go about choosing an orchestration platform , specifically scalability , integration and a combination of security / reliability / support .
Depending on requirements , scalability can be a significant factor . And if one wants to start building services from microservices architectures of the next years / decades , selecting an orchestration layer that is capable of scaling to and managing hundreds if not many thousand containers , is a real plus .
If the orchestration layer is also expected to interface with many external systems as well , to allow the creation of new services by leveraging already existing services , then integration is a key piece of the puzzle . Integration may , arguably , be more important than scalability , as it allows for existing IT investments to play a role in the creation of new , cloud native workloads and their associated infrastructure . Without key integration points , enterprises risk developing two distinct silos – one for current architecture and a container based stack for new workloads , which can lead to a myriad of management and process based challenges .
Finally , IT decision makers need to assess how an orchestration platform will affect or impact their mission critical systems – if it ’ s intended to be a production system ( and many are likely selected with that role in mind ), then security , reliability and support come into play . While each of these aspects is effectively critical on its own , they all are interconnected , with support forming a likely linchpin . A properly supported platform by a well known , respected vendor or , at the very least , knowledgeable and dedicated internal experts , should produce a reliable , secure foundation for production workloads , not just R & D projects .
As with all enterprise IT decisions , orchestration platforms are one thread in a broader tapestry made up by the overall landscape of a given enterprise environment . Every enterprise has specific , unique needs with technology , and containers and orchestration are no different ; once a business is able to best understand what they value most – scalability , integration , etc . – then they can select the best technology and strategy for their own needs .
March 2017 | 29