Development Teams Need to Keep All Options on the Table
- September 29, 2021
The ability to move code between platforms is an inalienable right that has also become a critical business imperative. Every developer knows that not every application workload runs equally well on all platforms. Developers in this day and age also need to be able to easily shift between platforms as platforms and business conditions evolve.
Containers, along with the Kubernetes orchestration engine, have emerged in recent years as arguably one of the best safeguards of freedom of choice. However, not all development platforms based on containers afford development teams the same level of flexibility. The simple truth is many container development platforms have been extended in ways that lock organizations into a specific platform without them realizing until it’s long too late to do much about it without incurring massive costs. Given the level of merger and acquisition activity that occurs in the digital age, no one is quite sure which friend might overnight be turned into a foe.
Requiring development teams to employ different tools and services for each platform employed is also the surest way to make application development and deployment not only more expensive but also much less flexible than the business is likely to require.
At their core, containers are an abstraction in the application layer that enables code and dependencies to be compiled or packaged together. That approach makes it possible to run containers on different platforms with each container running as an isolated process that shares the operating system with other containers.
Containers enable images to be managed via several different union mount file systems that are provided by an operating or file system to make code changes, patches, and configuration files. Building an image using layers means only the delta updates need to be made to update an image.
The use of layers is employed in the distribution of both read-only images and data stored in active containers. The container runtime engine creates a writeable layer sitting above the read-only image layers that as a container is started encapsulates all of the configuration changes made in the container. Those images are then stored in a repository to enable hosts to run Docker images without having to download the entire image content each time code changes.
Capable of running on any platform, one of the most valuable aspects of Kubernetes is that it presents DevOps teams with a standard set of application programming interfaces (APIs) that make it simpler to deploy modern cloud-native applications built using containers anywhere.
As long as organizations don’t make use of any proprietary API extensions on a platform, strict adherence to the Kubernetes APIs make it possible to switch platforms at will.
Each platform provider, both inside and out of the cloud, is betting that given all the work required most organizations won’t want to go to the trouble of moving an application to another platform.
The only way to overcome any effort to lock an organization into a specific platform is to make certain the application can be easily ported between on-premises and cloud computing environments regardless of what type of virtual machine or physical host is employed.
Mirantis Kubernetes Engine, meanwhile, comes with a built-in ingress controller based on the open source Istio service mesh and open source Calico networking software that can just as easily be deployed anywhere.
Continuously updated by Mirantis, the platform also provides a set of REST APIs through which Mirantis Container Cloud and Mirantis Kubernetes Engine can be integrated with, for example, any continuous integration/continuous delivery (CI/CD) platform or identity access management (IAM) platform. Alternatively, IT teams could opt to replace Istio or Calico with alternative platforms if they so choose.
Finally, via a single pane of glass an IT operations team can automate the entire lifecycle management process in a way that enables developers to self-service their own requirements so long as they conform to governance policies defined by an IT operations team.
Mirantis Flow rebalances that equation in favor of the application developers and the application development teams that support them. Instead of being trapped in a web of proprietary APIs, the Mirantis Flow platform ensures that any provider of a platform can be replaced at will.
That’s a crucial capability because without it, providers of platforms either deployed on-premises or in the cloud don’t have much incentive to negotiate. Worse yet, IT teams can’t easily take advantage of technology advances that might suddenly become available on one platform that are not available via the platforms they currently employ. Modern cloud-native applications are constructed using microservices that are built using container platforms. As these applications evolve, microservices are likely to be ripped and replaced by other microservices that provide additional capabilities. It’s not possible to predict which platform relied on today to deliver a microservice might need to be replaced by something more advanced tomorrow. The Mirantis Flow platform is designed from the ground up to enable IT organizations to keep all their options open.
There’s also the very real threat that today's supplier will become tomorrow's competitor. The parent companies of cloud service providers continue to rapidly move into adjacent sectors as the digital economy continues to evolve. It’s not uncommon for business leaders to wake up one morning to discover that one of those parent companies has either launched a new service or acquired an entity that competes with their organization’s existing product portfolio.
Not only are business leaders generally uncomfortable with storing their intellectual property in the form of data on a cloud platform owned by a rival; they also resent paying a rival for the privilege to use their cloud. Rather than having an uncomfortable conversation about why the organization is locked into a specific platform or service, most business leaders want to hear about how quickly the IT organization can pivot as business conditions may warrant.
Unlike any other platform, the goal is to enable development teams to realize both the technology and business goals that only true application workload portability can provide.
Containers, along with the Kubernetes orchestration engine, have emerged in recent years as arguably one of the best safeguards of freedom of choice. However, not all development platforms based on containers afford development teams the same level of flexibility. The simple truth is many container development platforms have been extended in ways that lock organizations into a specific platform without them realizing until it’s long too late to do much about it without incurring massive costs. Given the level of merger and acquisition activity that occurs in the digital age, no one is quite sure which friend might overnight be turned into a foe.
Requiring development teams to employ different tools and services for each platform employed is also the surest way to make application development and deployment not only more expensive but also much less flexible than the business is likely to require.
Container Portability Explained
One of the main benefits of containers is the level of portability between platforms they enable by reducing the dependency developers have on the operating systems and virtual machines being employed on any given platform.At their core, containers are an abstraction in the application layer that enables code and dependencies to be compiled or packaged together. That approach makes it possible to run containers on different platforms with each container running as an isolated process that shares the operating system with other containers.
Containers enable images to be managed via several different union mount file systems that are provided by an operating or file system to make code changes, patches, and configuration files. Building an image using layers means only the delta updates need to be made to update an image.
The use of layers is employed in the distribution of both read-only images and data stored in active containers. The container runtime engine creates a writeable layer sitting above the read-only image layers that as a container is started encapsulates all of the configuration changes made in the container. Those images are then stored in a repository to enable hosts to run Docker images without having to download the entire image content each time code changes.
The Kubernetes API dream
All of this portability is great, but when organizations begin to deploy hundreds and even thousands of containers it quickly becomes apparent that there is a need for an orchestration engine to manage them, and the open source Kubernetes container orchestration engine being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) has become a de facto standard.Capable of running on any platform, one of the most valuable aspects of Kubernetes is that it presents DevOps teams with a standard set of application programming interfaces (APIs) that make it simpler to deploy modern cloud-native applications built using containers anywhere.
As long as organizations don’t make use of any proprietary API extensions on a platform, strict adherence to the Kubernetes APIs make it possible to switch platforms at will.
How the Dream Gets Twisted
It requires a lot more than just containers and Kubernetes to successfully build and deploy cloud-native applications. Each platform a developer employs includes a range of additional storage and networking services that are unique to that platform. A containerized application is theoretically portable, but reliance on proprietary networking and storage services, for example, makes disengaging from a platform both time consuming and costly. The same is true for any number of proprietary APIs that might have been employed to, for example, integrate Kubernetes clusters with a continuous integration/continuous delivery (CI/CD) platform or database that only runs on one specific platform.Each platform provider, both inside and out of the cloud, is betting that given all the work required most organizations won’t want to go to the trouble of moving an application to another platform.
The only way to overcome any effort to lock an organization into a specific platform is to make certain the application can be easily ported between on-premises and cloud computing environments regardless of what type of virtual machine or physical host is employed.
How Mirantis Enables the Kubernetes Dream to be Realized
Mirantis Flow enables IT teams to circumvent efforts to lock development teams into a specific platform by providing them with one set of APIs and tools to deploy, manage, and observe Kubernetes clusters on any infrastructure, and virtually any cloud provider.Mirantis Kubernetes Engine, meanwhile, comes with a built-in ingress controller based on the open source Istio service mesh and open source Calico networking software that can just as easily be deployed anywhere.
Continuously updated by Mirantis, the platform also provides a set of REST APIs through which Mirantis Container Cloud and Mirantis Kubernetes Engine can be integrated with, for example, any continuous integration/continuous delivery (CI/CD) platform or identity access management (IAM) platform. Alternatively, IT teams could opt to replace Istio or Calico with alternative platforms if they so choose.
Finally, via a single pane of glass an IT operations team can automate the entire lifecycle management process in a way that enables developers to self-service their own requirements so long as they conform to governance policies defined by an IT operations team.
The Economics of Portability
Organizations only retain leverage over any supplier when they can easily switch from one to another. If the cost of switching is high, most organizations will continue to rely on a supplier, no matter how poor or expensive the platform becomes. All the economic leverage is on the side of the supplier. One of the primary reasons that the cost of IT has not fallen as sharply as it might is because cloud service providers lack any real incentive to lower costs to retain customers. The more dependent IT teams are on proprietary APIs the more trapped they become.Mirantis Flow rebalances that equation in favor of the application developers and the application development teams that support them. Instead of being trapped in a web of proprietary APIs, the Mirantis Flow platform ensures that any provider of a platform can be replaced at will.
That’s a crucial capability because without it, providers of platforms either deployed on-premises or in the cloud don’t have much incentive to negotiate. Worse yet, IT teams can’t easily take advantage of technology advances that might suddenly become available on one platform that are not available via the platforms they currently employ. Modern cloud-native applications are constructed using microservices that are built using container platforms. As these applications evolve, microservices are likely to be ripped and replaced by other microservices that provide additional capabilities. It’s not possible to predict which platform relied on today to deliver a microservice might need to be replaced by something more advanced tomorrow. The Mirantis Flow platform is designed from the ground up to enable IT organizations to keep all their options open.
There’s also the very real threat that today's supplier will become tomorrow's competitor. The parent companies of cloud service providers continue to rapidly move into adjacent sectors as the digital economy continues to evolve. It’s not uncommon for business leaders to wake up one morning to discover that one of those parent companies has either launched a new service or acquired an entity that competes with their organization’s existing product portfolio.
Not only are business leaders generally uncomfortable with storing their intellectual property in the form of data on a cloud platform owned by a rival; they also resent paying a rival for the privilege to use their cloud. Rather than having an uncomfortable conversation about why the organization is locked into a specific platform or service, most business leaders want to hear about how quickly the IT organization can pivot as business conditions may warrant.
Conclusion
Mirantis Flow is designed to provide organizations with maximum flexibility in a world that can change at a moment’s notice. IT teams can even swap out Kubernetes for Docker Swarm as their container orchestration engine if they are so inclined.Unlike any other platform, the goal is to enable development teams to realize both the technology and business goals that only true application workload portability can provide.
