Legacy Technologies Compound Technical Debt in a Modern Cloud Architecture
In today’s software-driven economy, every organization faces an imperative to modernize the way they deliver software in order to adapt and enable the digital era — or perish.
Digital transformation across industries is driving the need for IT to enable Cloud-Native applications. This has led enterprises to adopt Kubernetes as the most effective way to support cloud-native architectures and to modernize their applications and IT infrastructure.
As IT Operations supporting development and production environments, your challenges are getting harder and harder. You’re being asked to support the organization’s desire to improve agility and time to market, your developers are looking for a more cloud-like experience, and you continue to get pressured to reduce the cost of infrastructure management across a mix of systems, technology stacks, and clouds that are growing in numbers and complexity.
Kubernetes is the most transformational cloud technology today – essentially functioning as an operating system for cloud-native applications. Its built-in capabilities – such as HA, granular scalability, portability, rolling upgrades, and more – provide many of the features that are critical for running cloud-native applications on a truly composable, interoperable infrastructure.
Enterprises of all sizes today are looking to take advantage of Kubernetes – for both greenfield applications and for re-architecting and modernizing legacy applications to be Kubernetes-based.
Moving from Monolithic applications to Microservices and from Traditional VMs to Containers
Cloud-native applications are not just architected and developed differently, they fundamentally change how your infrastructure is provisioned and deployed, and how it is managed on an ongoing basis.
Cloud-native apps often take advantage of loosely-coupled architectures, such as microservices and serverless functions. The VM-based model simply falls apart for these types of modern applications, which are most suitable to run on containers. Once you have applications that are composed of hundreds of services – each requiring their own lightweight and granular infrastructure resources that can be deployed and scaled independently – containers are the only way to go.
To better understand the challenges of modernizing hypervisor-based infrastructure with Kubernetes, let us first consider why technologies such as legacy virtualization come up short in this cloud-native world.
Infrastructure Provisioning Process using Hypervisors
In most legacy hypervisor-based organizations, the process of provisioning the correct set of IT resources and configuration required for the various applications looks something like this:
- For instance, VMware-based organizations commonly have vCloud platform deployed across the board to manage large fleets of virtual instances – often hundreds of thousands
- Most of the infrastructure being managed is hosted across fi several on-premises data centers spanning different GEOs or regions
- There is growing interest from lines of business in using public cloud infrastructure in addition to their on-prem data centers. This is often either due to their dissatisfaction with the service provided by their own central IT team and long lead times (typically between 1 and 2 months) or due to the need of some applications to burst into the public cloud for spikes in demand.
- These organizations often have to support hundreds of applications, with demand that keeps growing. To minimize Shadow IT and environment sprawl, they have to tighten their internal processes around permissions, compliance and quota management when enabling business units to create or consume IT resources for their apps.
- IT teams then follow a structured process to identify the appropriate infrastructure provider, technology stack, tools, and configuration, in order to support the most suitable environment for different types of applications. This involves provisioning a mix of compute, storage and network infrastructure using VMware components.
- In an effort to improve agility and time to market, these organizations in parallel also start re-architecting their traditional monolithic, 3-tier applications, to be more microservices-based, and start adopting DevOps practices and CI/CD to improve service quality, cycle times, and release cadence.
- With DevOps busting silos between developers and operations, there’s an expectation from the business to accelerate software delivery, enable the digital transformation, and influence the technology choices and buying decisions traditionally made by IT.
- As the business pressure to deliver software faster increases, and as developers rely more on CI/CD and DevOps practices that require faster feedback loops, Shadow IT expands even more. This is a common scenario, as developers and some business units attempt to bypass traditional IT bottlenecks & delays and be able to take advantage of more modern technologies and architectures, by deploying their applications in the public cloud.
- In parallel, these organizations see that the costs associated with proprietary virtualization solutions are constraining budgets and try to accelerate the move to open source, Linux-based virtualization that is running on commodity hardware. However, system administration skills and costs associated with migration remain a significant bottleneck.
- Feedback from end users and on-going update requests from the business owners get slowly implemented and reflected in the product, causing dissatisfaction with customers and possible loss of revenue or user retention.
The above-described provisioning cycles can take weeks to months. The term “It takes 45 days to provision a group of VMs” is heard as a developer joke in large enterprises.
Key Technical Challenges with Traditional Hypervisor Platforms
The key challenges enterprises face while deploying large amounts of traditional VMware-based virtualization are:
- Lack of Infrastructure Agility – It is a fairly common situation that provisioning VMs for developers can take days to weeks. The IT team is constantly tackling tickets to create new templates, flavors of components ranging from OS’s such as CentOS, RHEL, Ubuntu, Windows etc. Constantly creating, building, packaging, storing these is a huge challenge.
- Ineffective collaboration: From a practical day-to-day perspective, a lot of time is lost not just on copy-pasting templates and configuration files, but also on internal communications between the teams, meetings, syncing, validation of the provisioned resources, communicating configuration changes needed, opening tickets, etc.
- This is a key challenge in creating platforms for Cloud-Native architectures. Such applications need to be architected, designed, developed, packaged, delivered and managed based on a deep understanding of the frameworks of cloud computing. In the Cloud Native world, the application itself is designed for scalability, resiliency, and incremental enhance-ability from the get-go – all of these are virtually impossible in a VMware driven enterprise. High cost (“vTax) – VMware technologies are typically proprietary and charge heavy license fees. Most prongs of the VMware stack are implemented as point-products, which require considerable and lengthy investments in professional services and custom integrations in order to implement effectively. This typically breaks right off the bat one of the key benefits of agile infrastructure, which is around reducing cost and increasing the time to value to make provisioning and on-going management smoother.
- Poor Developer Experience – Developers lead the adoption of the cloud because it is a faster way to build and ship products; especially vs legacy IT virtualization farms. Being dissatisfied with the provisioning processes and responsiveness of technologies such as VMware, developers often turn to the public cloud on their own (“Shadow IT”) simply to accelerate their work and enable themselves to move faster. Legacy hypervisor products have done a poor job catering to developers as a critical audience to facilitate digital transformation. vCloud doesn’t offer a seamless self-service experience for developers to provision resources or easily deploy applications and related services. Further, the governance controls are often poorly implemented and frustrate developers (e.g. limiting capacity usage by enforcing tickets instead of quotas)
- Large Operator Headcount – VMware often requires rather large teams of specialized VMware admins in order to configure and manage the network, storage and compute that are required for operating even a reasonably sized environment.
- Lack of Automated Operations – VMware vCloud installations are provided separately as packages or Linux/Windows appliances. This includes ESXi hosts, vSAN, vCloud, vCenter Server etc. However, all of these components are tied to one another with virtually no ability to customize the individual components. Thus, virtualization admins need to carefully install and manage dependencies between different product components so that upgrades do not cause downtime, slowing down IT processes and operations to upgrade and maintain the environments. Bootstrapping of VMs without a cloud layer or an automation tool such as Chef, Puppet, SaltStack, Ansible is a huge pain point on legacy infrastructure. The simple act of provisioning of the VM and running boot scripts is an issue without an automation tool. For instance, it is a huge pain point in the provisioning process to manually login in and running a Runbook to bootstrap it into their config management process. Legacy hypervisor products have done a poor job catering to operations teams.
- Network Management Challenges – Enterprises that run large virtualized deployments run into challenges in managing network infrastructure. The lack of an SDN layer leads to issues such as running out of IP addresses etc.
And as enterprises re-architect their apps to take advantage of containers at scale, you’d likely settle on Kubernetes as the natural choice for container orchestration. Kubernetes is the path forward.
Having set the stage for what constitutes ITOps Technical debt, the next post will discuss a path to cloud modernization.