Virtual machines – Best DevOps https://www.bestdevops.com Lets Learn, Do it & Share! Thats a Best DevOps!!! Wed, 14 Oct 2026 10:31:39 +0000 en-US hourly 1 https://wordpress.org/?v=7.1.3 Configuring Virtual Hosting in Apache https://www.bestdevops.com/configuring-virtual-hosting-in-apache/ Fri, 20 Aug 2021 10:23:22 +0000 https://www.bestdevops.com/?p=19505

“Virtual hosting is a method for hosting multiple domain names (with separate handling of each name) on a single server (or pool of servers).”

Wikipedia

How Does Apache Know Which Site to Serve?


The short answer to your specific case: apache will serve the FIRST overlapping virtual host. Since 000-default is before fc.localhost in the alphabet the first virtualhost is loaded and served.

To answer what i assume is the follow up question: You can host many sites on the same IP:PORT using named VirtualHosts

The host field in the http request header identifies which site (virtual
host) to serve:

Matched against the containers in the configuration file

A More Complete Virtual Host Definition

You can put (almost) any directive inside a virtual host container For example, it’s common to write separate logs for each site

Name Resolution

  1. In the “real world” our East and West sites would each have an entry in DNS (Domain Name Service)
  2. Our demonstration system uses only /etc/hosts for name resolution:

]]> How to Split Workloads with Microsoft Azure Stack https://www.bestdevops.com/how-to-split-workloads-with-microsoft-azure-stack/ https://www.bestdevops.com/how-to-split-workloads-with-microsoft-azure-stack/#respond Mon, 11 May 2020 05:32:25 +0000 http://www.bestdevops.com/?p=12330 Hybrid cloud infrastructure gives enterprises the ability to distribute workloads across public clouds, private clouds, and on-premises resources. Done well, this approach balances cost efficiency, performance, security, and compliance. Microsoft Azure Stack is one platform designed specifically to make that workload-splitting practical without forcing you to choose between public and private deployment models.

Why Split Workloads Across Environments?

Not every workload belongs in the same environment. Organizations typically split workloads for two broad reasons:

  • Cost optimization: Dynamic, bursty, or temporary workloads—such as software testing, peak-demand traffic, or batch analytics—can be run on a public cloud where you pay only for what you consume, rather than over-provisioning on-premises hardware.
  • Data sensitivity and compliance: Regulated or sensitive data (financial records, healthcare data, personal identifiable information) may need to stay on-premises or in a private cloud to meet compliance requirements and data sovereignty obligations.

Understanding the Three Deployment Models

Public Cloud

A public cloud is operated by a third-party provider—such as Microsoft Azure, AWS, or Google Cloud—who charges customers based on resource consumption. The provider owns, manages, and maintains the underlying infrastructure. Public clouds are well suited for:

  • Absorbing peaks in workload demand
  • Developing and testing applications
  • Running big data analytics jobs
  • Rapid prototyping and proof-of-concept work

Private Cloud

A private cloud is dedicated to a single organization, hosted either on-premises in the organization’s own data center or through a managed private hosting provider. Because the organization retains greater control over the infrastructure, private clouds are commonly used for compliance-sensitive workloads where security and governance cannot be compromised.

On-Premises Resources

On-premises resources are deployed and managed entirely within the organization’s own facilities. The organization is responsible for hardware procurement, maintenance, patching, and all related operational processes. While this model offers maximum control, it requires significant capital investment and operational overhead.

A hybrid cloud strategy combines all three models, giving an organization the flexibility to place each workload in the environment best suited to its requirements—balancing scalability, cost, security, and regulatory compliance.

A Framework for Splitting Workloads

Whether you are migrating to Azure Stack or planning a broader hybrid strategy, a structured four-phase approach helps avoid costly mistakes:

1. Qualification

Use tooling to analyze existing workloads and infrastructure. The goal is to characterize each workload by:

  • Utilization patterns (CPU, memory, storage, network)
  • Data classification (public, internal, confidential, regulated)
  • Technical dependencies (operating systems, middleware, databases)
  • Performance and latency requirements

This analysis produces a workload profile for each application or service, which informs subsequent decisions about where each workload should live.

2. Assessment

With workload profiles in hand, evaluate which hosting environment best fits each profile. Consider:

  • Compliance and data residency requirements
  • Total cost of ownership across public, private, and on-premises models
  • Service-level requirements (availability, latency, throughput)
  • Application architecture compatibility with IaaS or PaaS models

Group workloads that share characteristics so they can be migrated together, reducing complexity and coordination overhead during execution.

3. Execution

Migrate workload groups to their target environments according to the plan. Prioritize validation at each step: verify that migrated workloads are functioning correctly, that data integrity is preserved, and that performance meets expectations before decommissioning source environments.

4. Optimization

Migration is not a one-time event. Continuously monitor resource utilization, cost, and performance after migration. Use this data to right-size allocations, identify further optimization opportunities, and adjust workload placement as business requirements evolve.

How Azure Stack Supports Workload Splitting

Microsoft Azure Stack is a hyper-converged infrastructure platform that extends Azure’s public cloud capabilities into your own data center. Its core value proposition is architectural consistency: Azure Stack uses the same APIs, tooling, and management interfaces as Azure’s public cloud, eliminating the integration and compatibility friction that typically makes hybrid deployments complex.

Key Capabilities

  • Unified management: Manage public cloud and on-premises workloads from a single interface, reducing operational overhead.
  • IaaS and PaaS support: Import and run virtual machines under an IaaS model, or deploy applications on managed platform services under a PaaS model—without changing your toolchain.
  • Resource aggregation: Azure Stack aggregates and classifies underlying hardware resources, then allocates capacity dynamically to workloads based on demand.
  • Consistent developer experience: Development teams use the same Azure SDKs, CLI tools, and ARM templates regardless of whether they are targeting the public cloud or an Azure Stack deployment, which accelerates application development and simplifies deployment pipelines.
  • Disconnected operations: Applications can run on Azure Stack in environments with limited or no connectivity to the public internet, then sync data once connectivity is restored—useful for edge or remote scenarios.

Common Enterprise Use Cases

Use CaseHow Azure Stack Helps
Compliance and data sovereigntyKeeps regulated data on-premises while providing the same security controls and audit capabilities as Azure public cloud
High-performance processingRuns large analytics or compute workloads locally, avoiding public cloud upload latency
Disconnected or edge deploymentsOperates applications in low-connectivity environments and syncs results when reconnected
Consistent app development and deploymentUses identical Azure tooling on-premises, enabling developers to build once and deploy to either environment
Gradual cloud adoptionAllows organizations to move workloads to the public cloud incrementally, at their own pace

Who Benefits Most from Azure Stack?

Azure Stack is particularly well suited for organizations that:

  • Operate in heavily regulated industries (finance, healthcare, government) where data cannot leave a specific jurisdiction
  • Are already Azure customers and want to extend the same operational model to on-premises workloads
  • Need low-latency processing that a public cloud cannot provide due to geographic distance or connectivity constraints
  • Want to modernize IT infrastructure gradually without a full lift-and-shift to public cloud
  • Run edge or remote sites that require local compute but benefit from centralized management

Summary

Splitting workloads across public, private, and on-premises environments is a practical strategy for balancing cost, performance, and compliance. A disciplined approach—qualification, assessment, execution, and ongoing optimization—helps ensure each workload lands in the environment that best meets its requirements.

Microsoft Azure Stack simplifies hybrid workload management by bringing Azure’s public cloud capabilities on-premises with full architectural consistency. For organizations that need the agility of a public cloud but cannot move all workloads off-premises, Azure Stack offers a credible path to a functioning hybrid architecture without the integration complexity that typically accompanies mixed-vendor environments.

]]> https://www.bestdevops.com/how-to-split-workloads-with-microsoft-azure-stack/feed/ 0 Google Cloud Expands Anthos to AWS: Multi-Cloud Application Management Now Generally Available https://www.bestdevops.com/google-cloud-expands-features-in-anthos-now-running-managing-applications-on-aws/ https://www.bestdevops.com/google-cloud-expands-features-in-anthos-now-running-managing-applications-on-aws/#respond Fri, 08 May 2020 05:37:38 +0000 http://www.bestdevops.com/?p=12279 This article is based on a Google Cloud announcement originally covered by Analytics India Magazine in May 2020.

What Is Anthos?

Anthos is Google Cloud’s managed application platform designed for hybrid and multi-cloud environments. It gives enterprises a single, consistent control plane to build, deploy, and operate applications — whether those workloads run on Google Cloud, in an on-premises data centre, or on a third-party cloud provider such as AWS or Azure.

The platform is built on Kubernetes and integrates tooling for service mesh networking, policy management, configuration management, and workload migration. The core promise of Anthos is that teams should be able to apply the same operational practices across every environment without re-architecting their applications for each deployment target.

Anthos Multi-Cloud Support Reaches General Availability

With this release (announced May 2020), Google Cloud moved Anthos multi-cloud support from preview to General Availability (GA). The GA release started with AWS, consolidating operations across on-premises environments, Google Cloud, and AWS under a single management layer. Support for Microsoft Azure was available in preview at the time of the announcement.

The practical impact for platform and DevOps teams includes:

  • Unified operations: A common management interface covers workloads regardless of where they run, reducing the operational overhead of context-switching between provider-specific toolchains.
  • Consistent security posture: Policies can be defined once and enforced consistently across every cluster, whether it is on-premises or in a public cloud.
  • Protection of existing investment: Organisations can continue using infrastructure they have already provisioned on AWS or on-premises without being required to migrate everything to Google Cloud.

Key Feature Expansions

Policy and Configuration Management for VMs

Anthos Config Management was extended to support virtual machines on Google Cloud, bringing the same declarative, GitOps-style configuration approach that was already available for containers. By expressing VM policies as code, teams can:

  • Reduce configuration drift caused by manual changes.
  • Enforce a desired state continuously across heterogeneous workloads.
  • Accelerate delivery by removing manual approval steps for routine policy updates.

Anthos Service Mesh Support for Virtual Machines

Anthos Service Mesh was announced to gain support for workloads running in virtual machines via a sidecar proxy model. The sidecar acts as a network gateway, making VM-based services visible to and manageable by the mesh alongside container workloads. This allows teams to:

  • Apply consistent traffic management, observability, and security policies across containers and VMs.
  • Incrementally modernise legacy VM workloads without a big-bang migration to containers.
  • Maintain service networking consistency across Google Cloud, on-premises, and other clouds.

Note: At the time of the announcement, VM support for Anthos Service Mesh was described as coming in the following months, not yet GA.

Running Anthos Without a Third-Party Hypervisor

Google Cloud announced that, beginning later in 2020, customers would be able to run Anthos on-premises without requiring a third-party hypervisor. This was intended to reduce licensing costs and remove the operational complexity of managing an additional vendor relationship for the underlying virtualisation layer.

Migrate for Anthos Improvements

The release also included updates to Migrate for Anthos, Google Cloud’s tooling for lifting and shifting VM workloads into containers. The updated release focused on simplifying day-two operations — the ongoing management tasks after an initial migration — and improving integration between migrated workloads and the broader Anthos service ecosystem. The goal is to lower migration costs and improve performance without requiring manual re-architecting.

Why Multi-Cloud Management Matters for DevOps Teams

Most large enterprises already operate workloads across multiple environments by necessity — legacy on-premises systems, cloud migrations underway, and SaaS dependencies create heterogeneous infrastructure by default. The operational challenge is not choosing a single cloud but managing complexity when workloads are spread across environments with different APIs, security models, and toolchains.

Anthos addresses this by abstracting the infrastructure layer. Teams interact with Kubernetes-native APIs and Anthos tooling regardless of the underlying environment, which means:

  • Platform teams can enforce consistent security and compliance policies without writing provider-specific automation for each environment.
  • Application teams can deploy to any target environment using the same CI/CD pipelines and manifests.
  • Organisations retain the ability to move workloads between environments as cost, compliance, or latency requirements change — without vendor lock-in to a single provider’s proprietary services.

Summary of the Anthos May 2020 Expansion

FeatureStatus (May 2020)
Anthos on AWSGenerally Available
Anthos on AzurePreview
Anthos Config Management for VMsGenerally Available
Anthos Service Mesh for VMsComing in following months
Anthos without third-party hypervisorPlanned for later 2020
Migrate for Anthos updatesAvailable with this release

Further Reading

For the latest Anthos documentation, feature status, and release notes, refer to the official Google Cloud Anthos page. Feature availability and product names may have changed since this announcement.

]]> https://www.bestdevops.com/google-cloud-expands-features-in-anthos-now-running-managing-applications-on-aws/feed/ 0 How to Scale Kubernetes: 3 Key Factors Every DevOps Engineer Should Know https://www.bestdevops.com/how-to-scale-kubernetes-3-factors/ https://www.bestdevops.com/how-to-scale-kubernetes-3-factors/#respond Tue, 14 Apr 2020 05:27:09 +0000 http://www.bestdevops.com/?p=11802 This article is based on a post originally sourced from TechRepublic. The original publication date was April 2020.

Kubernetes has become the dominant container orchestration platform for good reason: it can scale applications elastically in response to demand. But that capability does not come out of the box. Kubernetes requires deliberate configuration at multiple layers before it will scale reliably under production load. Miss one layer and you risk overloaded nodes, wasted cloud spend, or cascading failures across environments.

This article walks through three distinct scaling dimensions in Kubernetes: application-level scaling, cluster-level scaling, and managing multiple clusters. Each layer builds on the previous one, and each introduces its own operational complexity.

Factor 1: Application Scaling

Define Resource Requests and Limits

The foundation of application scaling in Kubernetes is making your pods resource-aware. By default, if you do not specify CPU and memory requests in your pod spec, the Kubernetes scheduler treats the resource needs as zero. This means it may schedule far too many pods onto a single node, overloading it and causing instability.

Before you can set accurate resource requests, you need to profile the application in a realistic environment. Observe actual CPU and memory consumption under normal and peak load, then encode those observations into your pod spec:

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

The requests values tell the scheduler how much capacity to reserve on a node. The limits values cap what the container can actually consume. Setting these correctly is the single most impactful thing you can do to make application scaling predictable.

Horizontal Pod Autoscaler (HPA)

Once resource requests are defined, you can use the Horizontal Pod Autoscaler (HPA) to automatically scale the number of pod replicas in response to observed metrics. The HPA can act on CPU utilization, memory utilization, or custom metrics exposed through the Kubernetes Metrics API.

A basic HPA targeting CPU utilization looks like this:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

Running at least two replicas of a pod also enables rolling upgrades: Kubernetes can update pods one at a time while keeping the application available, allowing you to maintain uptime close to 100% through deployments. The official Kubernetes documentation on scaling deployments covers manual scaling as a starting point before you introduce autoscaling.

Factor 2: Cluster Scaling

Application scaling handles the distribution of workload across the pods and nodes that already exist in your cluster. But what happens when the cluster itself runs out of capacity? Kubernetes has no built-in mechanism to provision new virtual machines—it is only aware of the resources already registered with it.

Cluster Autoscaler

The answer is the Cluster Autoscaler, a separate component that monitors the cluster for pending pods that cannot be scheduled due to insufficient node capacity. When it detects this condition, it requests additional nodes from the underlying infrastructure provider—a public cloud API, a private cloud like OpenStack, or a virtualization platform. When nodes are underutilized for a configurable period, the Cluster Autoscaler can also scale them back down to reduce cost.

All major cloud providers—Amazon Web Services, Microsoft Azure, Google Cloud, and IBM Cloud—offer native integration between their managed Kubernetes services and their node auto-provisioning APIs. The open-source kubernetes/autoscaler project supports multiple cloud backends if you are not using a fully managed service.

OpenShift and Hybrid Cloud Scaling

Red Hat OpenShift is a Kubernetes distribution that includes built-in machine management and autoscaling capabilities through its Machine API. OpenShift can manage resources across on-premises infrastructure and public cloud environments simultaneously, making it a practical option for organisations with hybrid-cloud requirements who want cluster autoscaling without assembling the components themselves.

Factor 3: Managing Multiple Clusters

Once you operate Kubernetes in a serious production context, a single cluster is rarely enough. The need for multiple clusters emerges from several independent pressures:

  • Environment isolation: Separate development, staging, and production clusters prevent a load test from competing with or destabilising production workloads.
  • High availability: Distributing workloads across clusters in different availability zones or regions protects against zone-level outages.
  • Geographic distribution: Routing users to a cluster in their region reduces latency and may satisfy data-residency regulations.
  • Organisational boundaries: Different business units or teams may require separate clusters for security, billing, or compliance reasons.

These requirements multiply quickly. A multinational organisation that applies each of these constraints across its business units can end up managing dozens of Kubernetes clusters. Each cluster may have its own version, configuration drift, and resource utilisation profile. Getting a unified operational picture across all of them is a significant engineering challenge—let alone managing costs at scale.

Multi-Cluster Management Tooling

To manage its own large-scale Kubernetes infrastructure, IBM developed Razee, a continuous delivery and multi-cluster configuration management tool that it later released as open source. Razee is designed to push configuration and deployments across many clusters consistently. It is available at razee.io.

Other tools in this space include the CNCF project Argo CD for GitOps-based delivery, Fleet from Rancher for large-scale cluster management, and the emerging Open Cluster Management project. The multi-cluster management tooling ecosystem was still maturing at the time the original article was written and has continued to evolve.

When Managed and Specialised Services Make More Sense

Configuring all three layers of Kubernetes scaling—application, cluster, and multi-cluster—requires substantial engineering investment. For many organisations, fully managed Kubernetes services from cloud providers offload the cluster-scaling and infrastructure-management concerns, reducing the problem to application-level configuration.

For specific workloads, specialised managed services may be a better fit than a general-purpose Kubernetes cluster. Database-focused providers, for example, offer managed services built on Kubernetes operators that handle the operational complexity of running stateful workloads at scale—including automated failover, backup, and vertical or horizontal scaling—in a way that a general Kubernetes configuration would require significant custom work to replicate.

The relevant question is not whether to use Kubernetes, but which layers of the stack your team should own versus delegate to a managed service. The answer depends on your team’s size, operational maturity, and whether the workload in question is a differentiator or a commodity for your business.

Summary

Scaling LayerMechanismKey Concern
ApplicationResource requests/limits, HPACorrect profiling of workload resource needs
ClusterCluster Autoscaler, managed node groupsInfrastructure API integration and cost control
Multi-clusterFederation tools, GitOps, Razee, Argo CDConsistency, visibility, and cost across clusters

Kubernetes scaling is not a single dial to turn up. It is a layered system where each layer depends on the one below it being configured correctly. Getting application resource requests right is the prerequisite for the HPA to work. Having the HPA drive pod counts up is the prerequisite for the Cluster Autoscaler to need to add nodes. And managing multiple clusters is impossible without visibility tools that span all of them. Work through the layers in order and your cluster will scale the way Kubernetes promises it can.

]]> https://www.bestdevops.com/how-to-scale-kubernetes-3-factors/feed/ 0 Why AWS, Google, and Microsoft Kept Building Data Centers During COVID-19 https://www.bestdevops.com/coronavirus-wont-stop-aws-google-microsofts-datacentre-spending/ https://www.bestdevops.com/coronavirus-wont-stop-aws-google-microsofts-datacentre-spending/#respond Tue, 31 Mar 2020 05:55:24 +0000 http://www.bestdevops.com/?p=11476 This article draws on analysis and figures published by Synergy Research Group in March 2020, as reported by CRN Australia.

Hyperscale Spending Hit a Record High Before the Pandemic Struck

Even as the COVID-19 pandemic began disrupting enterprise IT budgets in early 2020—delaying hardware purchases, canceling events, and freezing discretionary spend—the world’s largest cloud and internet companies showed no signs of pulling back on data center investment. According to Synergy Research Group, hyperscale capital expenditure (capex) on data centers reached an all-time high of over US$120 billion in 2019, with a record-breaking fourth quarter alone exceeding US$32 billion.

The top five hyperscale spenders in 2019 were Amazon, Google, Microsoft, Facebook, and Apple, whose data center budgets dwarfed all other operators. Other significant spenders included Alibaba, Tencent, IBM, JD.com, Baidu, and Oracle.

Data Center Spend Rose 11% Even as Overall Capex Stayed Flat

A notable nuance in the Synergy data: while total hyperscale operator capex grew only 1% year-over-year in 2019, spending specifically directed at data centers jumped 11% compared to 2018. This distinction matters—it signals that these companies were actively prioritizing physical infrastructure investment even when tightening spending in other areas.

As of the end of 2019, Synergy counted 512 hyperscale data centers in production worldwide, with further growth anticipated through 2020 despite the pandemic.

Why Cloud Giants Are Better Insulated Than Other Industries

John Dinsdale, Chief Analyst at Synergy Research Group, explained the reasoning directly:

“While there are many unknowns, what is clear is that the hyperscale operators generate well over 80 percent of their revenues from cloud, digital services and online activities. The radical shifts we are seeing in social and business behavior will actually provide some substantive tailwinds for many of these businesses. These hyperscale firms are much better insulated against the current crisis than most others and we expect to see ongoing robust levels of capex.”

John Dinsdale, Chief Analyst, Synergy Research Group

The logic is straightforward from a DevOps and infrastructure perspective: the mass migration to remote work, video conferencing, online collaboration, e-commerce, and digital entertainment all run on cloud infrastructure. Demand spikes across these categories directly benefit providers like AWS, Google Cloud, and Microsoft Azure—and justify continued investment in capacity.

What Hyperscale Data Centers Actually Look Like

For context, the majority of hyperscale capex goes toward building, expanding, and equipping hyperscale data centers—massive facilities housing tens of thousands of physical servers alongside millions of virtual machines. These aren’t typical enterprise data centers. They are purpose-built campuses designed for extreme density, power efficiency, and redundancy, often spanning hundreds of thousands of square feet.

Synergy’s analysis tracked the capex and physical footprint of 20 of the world’s largest hyperscale operators across SaaS, e-commerce, social networking, IaaS, and PaaS categories. In aggregate, those 20 companies generated nearly US$1.4 trillion in revenue in 2019, up 13% from 2018.

The Broader Industry Picture: COVID-19’s Uneven Impact on IT

Not every segment of the technology industry was as well-positioned. Dell Technologies CEO Michael Dell, speaking to CRN at the time, acknowledged the unprecedented nature of the disruption:

“Having done this for 35 years or so, I’ve seen a lot of things. There’s been nothing really like this. So the whole work-from-home movement is something our customers need a lot of help with. Customers and partners need us more than ever.”

Michael Dell, CEO, Dell Technologies

Traditional IT hardware vendors, on-premises data center equipment suppliers, and event-dependent businesses faced steep headwinds. The contrast with hyperscale operators was stark: the same pandemic conditions that hurt one group provided demand tailwinds for the other.

Key Takeaways for DevOps and Infrastructure Teams

  • Cloud demand is crisis-resilient. Workloads that depend on cloud infrastructure tend to accelerate during disruption events—remote work tooling, video, streaming, and e-commerce all surge when physical movement is restricted.
  • Hyperscale investment signals long-term capacity planning. Data center construction cycles are measured in years. Continued 2020 capex commitments meant these providers were building for 2022 and beyond, not reacting to a single quarter.
  • Revenue diversification across cloud service tiers matters. Providers spanning SaaS, IaaS, and PaaS have multiple revenue streams that collectively absorb economic shocks better than single-segment businesses.
  • The hyperscale footprint keeps growing. With 512 hyperscale facilities already in production as of end-2019 and more planned, the physical backbone of modern cloud infrastructure was expanding regardless of macroeconomic turbulence.

Original reporting by CRN Australia, citing Synergy Research Group data published March 2020.

]]> https://www.bestdevops.com/coronavirus-wont-stop-aws-google-microsofts-datacentre-spending/feed/ 0 The expansion of FaaS in edge: How it’ll merge IT with DevOps https://www.bestdevops.com/the-expansion-of-faas-in-edge-how-itll-merge-it-with-devops/ https://www.bestdevops.com/the-expansion-of-faas-in-edge-how-itll-merge-it-with-devops/#respond Sat, 22 Feb 2020 05:19:43 +0000 http://www.bestdevops.com/?p=10786 Source:-itproportal.com

With more enterprises continuing to integrate FaaS capabilities into both edge and cloud, we’ve seen big changes in the developer community.

]]> https://www.bestdevops.com/the-expansion-of-faas-in-edge-how-itll-merge-it-with-devops/feed/ 0 Kubernetes is booming, but consolidation is coming https://www.bestdevops.com/kubernetes-is-booming-but-consolidation-is-coming/ https://www.bestdevops.com/kubernetes-is-booming-but-consolidation-is-coming/#respond Tue, 24 Dec 2019 06:02:54 +0000 http://www.bestdevops.com/?p=9736 Source:-zdnet.com

The crowded halls of the official Kubernetes conference Kubecon reflect a nascent but important technology whose best future might be to disappear into the background.

Kubernetes is an important part of the future of computing infrastructure, because containers are an important new tool for the way we build applications.

CLOUD
Microsoft acquires cloud file-migration specialist Mover
Red Hat OpenShift 4.2: Kubernetes for the hybrid-cloud developer
Top cloud providers 2019: AWS, Microsoft Azure, Google Cloud
Adobe’s cloud pivot: What we’ve learned (ZDNet YouTube)
Buy a Google Pixel 4, get 3 free months of Google One (CNET)
How to calculate AWS costs and avoid paying too much for cloud services (TechRepublic)
What we often call ‘cloud-native’ applications are designed to handle failure by just restarting and retrying rather than having enormous fault tolerance and resilience built in – replacing hardware with software but still keeping the rather brute-force nature of turning things off and on. The distributed microservices that make up cloud-native applications help with that, as well as allowing small pieces of the application to be built and updated independently.

That doesn’t mean abandoning all the other technologies that have been useful, and the introduction into Linux of Intel’s KATA isolated containers is validation of Microsoft’s opinion that the security isolation provided by virtual machines is still important. Kubernetes is still catching up in some fairly critical areas; support for combined IPv4 and IPv6 networks has only just been introduced in Kubernetes 1.16. Windows support is only just maturing – with Microsoft’s LCOW (Linux Containers on Windows) work now part of the containerd runtime – and Active Directory service account support still only in beta. Kubernetes isn’t in any sense what you’d call complete.

SEE: Cloud v. data center decision (ZDNet special report) | Download the report as a PDF (TechRepublic)

That’s because rebuilding all the tools and concepts we had before, in Kubernetes, is a lot of work; it may be worth it to get the benefits of containers, but it’s important to keep things in perspective.

To look at Kubecon this year, with its 10-12,000 attendees, you’d think that Kubernetes was well on its way to comprising the entirety of compute infrastructure, from enterprise apps to mobile networks to edge computing to serverless to databases to machine learning to networking to development tools to literally everything else.

Putting all of that together with the on-going developments in Kubernetes itself makes it hard to find any one topic and dig deep on it, because there’s just so much noise. Not only were there more attendees at one session covering a new Special Interest Group than the 550 people who went to the first Kubecon in Seattle in 2015, but there are almost as many organizations who have joined the CNCF as the attendees at that first Kubecon.

Some of that is about the way Kubernetes is becoming a common piece of infrastructure, and some of it is about the millions of dollars sloshing around the Kubernetes ecosystem. Kubernetes has become so significant that large enterprise IT companies from Microsoft to VMware to IBM have hired key developers and made contributions to key projects, either to get the expertise to deliver their own Kubernetes products and services or to move the ecosystem forward in a way that meshes with their existing products and services. The CNCF certification program for Kubernetes distros has allowed the number to proliferate without succumbing to the OpenStack problem of incompatibility between distributions from different vendors.

Some of it is even part of the way that Kubernetes is one of the healthiest open-source projects in recent years, in both senses of the word. The community building Kubernetes is particularly helpful, welcoming, diverse, self-aware and supportive, and while progress on some features like dual-stack support has been slower, regular releases bring new features at a fairly respectable clip. An organized process for rotating who’s working on the launch team stops the same few people from being overburdened, keeps enthusiasm high – and brings a continual stream of new people from more companies into the process.

Kubernetes is still booming, still growing and still producing new projects at a speed that says the ecosystem is still in its pre-Cambrian explosion of species diversity. But every pre-Cambrian explosion is followed by an Ediacaran die-off and if you squint carefully enough you might see the glow from the meteorite plummeting towards you. The explosion of multiple products (five service meshes! Multiple service catalogs!) will get curated down to a more manageable set of choices and ideally, much of Kubernetes will disappear into the infrastructure that most people in technology don’t have to think about any more than they think about the way an OS filing system, a database engine or a hypervisor works.

SEE: Just how popular is Kubernetes?

Kubernetes evangelist Kelsey Hightower noted recently that “The cloud made the hypervisor disappear. Kubernetes will be next.” That doesn’t mean either Kubernetes or the hypervisor is going away (see KATA containers where the oh-so-important isolation is provided by a hypervisor), any more than serverless magically works without anyone having any servers: just that all these trends are about not having to care about that infrastructure to get something done.

For Kubernetes, that might mean caring more about the Kubernetes API that handles the ‘getting things done’ part than the nodes and pods and other Kubernetes concepts that actually do the thing.

There are lots of ways of delivering that – cloud Kubernetes services, virtual kubelets and ephemeral containers and a half dozen other ideas – so there will be multiple projects and vendors springing up like mushrooms in the forest to deliver that abstraction, and infrastructure admins will get to care and worry about all of those. And Kubecon probably won’t get any smaller or more manageable unless it splits into a couple of more focused conferences.

But however ubiquitous the Kubernetes API might get, it’s not going to displace everything else. It might become the new IaaS where workloads run, but there’s still going to be plenty of more specialised PaaS options as well as ways to piece together cloud native applications out of PaaS pieces.

SEE: Serverless Kubernetes containers: Amazon EKS on AWS Fargate

And while Kubernetes itself is fairly new, many of the concepts it delivers aren’t. So yes, Kubernetes can be a big part of the future of computing without anyone apart from the infrastructure team knowing how to work with it directly or maybe even knowing it’s there. But the tools to do that need to shape up and stop treating Kubernetes as some special new thing.

It’s the latest crank of the wheel in computing platforms. It’s the latest abstraction for delivering a platform, likely itself to get abstracted away by some new layer.

It might be more useful to think of Kubernetes as the new Linux kernel rather than the new hypervisor. But whichever layer of infrastructure you think of it as, fast forward a couple of years and the focus will be much more on what you do with Kubernetes than how you do Kubernetes. And maybe Kubecon will be a little more targeted and manageable to go with that progression.

]]> https://www.bestdevops.com/kubernetes-is-booming-but-consolidation-is-coming/feed/ 0 How Kubernetes Changed the Face of Hybrid Cloud https://www.bestdevops.com/how-kubernetes-has-changed-the-face-of-hybrid-cloud/ https://www.bestdevops.com/how-kubernetes-has-changed-the-face-of-hybrid-cloud/#respond Wed, 18 Dec 2019 05:52:26 +0000 http://www.bestdevops.com/?p=9644 This article is based on reporting originally published on Forbes.com in December 2019, authored by Janakiram MSV.

The Long Road to True Hybrid Cloud

Ever since public cloud platforms became mainstream, the industry has chased one goal: genuine parity between on-premises infrastructure and cloud infrastructure. The ability to develop an application in a private data center and run it at scale on a public cloud — with no rework — has been the holy grail of enterprise architecture.

Early open-source projects took a serious run at this problem. OpenStack, CloudStack, and Eucalyptus all aimed to become universal hybrid cloud platforms, offering enterprises a way to extend private infrastructure outward to public providers. Despite significant investment from vendors and operators, workload portability remained elusive. The core issue was the hypervisor gap: the virtual machine managers (VMMs) running in on-premises data centers — VMware ESXi, Microsoft Hyper-V, and KVM variants — were fundamentally different from what powered AWS, Google Cloud, and Azure under the hood. Moving a workload between environments meant re-imaging, reconfiguring, or re-testing. Cloud bursting, the ability to seamlessly overflow on-premises workloads into the public cloud during peak demand, stayed largely theoretical.

Two Trends That Changed Everything: Containers and Kubernetes

Starting around 2015, two related but distinct technologies began reshaping this landscape: Linux containers and Kubernetes.

Containers as the Common Runtime

The container runtime became the lowest common denominator for running workloads across physical machines, private clouds, and public clouds. A container image bundles the application binary, its dependencies, and its runtime configuration into a single, portable artifact. Once built, a containerized application can run on any host that supports the container runtime — whether that host is a developer’s MacBook, a bare-metal server in a colocation facility, an Amazon EC2 instance, a Google Compute Engine VM, or an Azure Virtual Machine — with no changes to the application code or configuration.

In this sense, Docker and compatible container runtimes became a practical alternative to hypervisors for application portability. Where hypervisors virtualize hardware, containers virtualize the operating system environment, delivering a lighter and more consistent execution unit for modern software.

Kubernetes as the Universal Orchestration Layer

If containers replaced the hypervisor as the deployment unit, Kubernetes replaced the proprietary virtual machine manager as the orchestration and lifecycle management layer. Kubernetes provides a declarative API for scheduling containers, managing networking, handling storage, enforcing policies, and recovering from failures — consistently, regardless of the underlying infrastructure.

The industry converged on this combination quickly. With containers as the packaging format and Kubernetes as the orchestration engine, infrastructure teams finally had a standard infrastructure layer that worked across environments without vendor lock-in at the runtime level.

The Role of the CNCF in Ensuring Interoperability

Kubernetes being open source was necessary but not sufficient. An ecosystem of incompatible forks would have reproduced the same fragmentation problem that plagued earlier hybrid cloud efforts. The Cloud Native Computing Foundation (CNCF) — the governance body that oversees the Kubernetes project — addressed this directly through the Certified Kubernetes Conformance Program.

The conformance program requires every vendor distribution of Kubernetes to support the required upstream APIs. This means that a workload running on Red Hat OpenShift, VMware Tanzu, Rancher, or a managed service like Amazon EKS, Google GKE, or Azure AKS can be expected to behave consistently at the API level. For enterprises, this translates directly to freedom of choice: they can move between vendors or run across multiple vendors without rewriting application manifests.

The CNCF also governs containerd, the container runtime standard. As long as a container runtime adheres to the containerd specification (and the broader OCI standards), Kubernetes can schedule and manage those workloads. Together, containerd and Kubernetes form the foundation of what the industry now calls the cloud-native stack.

Vendor Adoption: Everyone Went All-In on Kubernetes

The combination of standardization and broad conformance drove rapid adoption across every tier of the market. Platform vendors including Red Hat, VMware, Canonical, Mirantis, and Rancher built commercial Kubernetes distributions capable of running in both enterprise data centers and major public clouds. Hyperscale cloud providers — Alibaba Cloud, AWS, Google Cloud, IBM Cloud, Huawei Cloud, Microsoft Azure, and Oracle Cloud — all launched managed Kubernetes services to meet enterprise demand.

Perhaps more significant was the emergence of Kubernetes-native hybrid cloud control planes — platforms that can manage Kubernetes clusters regardless of where those clusters run:

  • IBM Cloud Paks (formerly IBM Cloud Private) — IBM’s hybrid cloud platform built on top of Red Hat OpenShift and Kubernetes.
  • Google Anthos — announced at Google Cloud NEXT 2019, Anthos allows organizations to deploy and manage applications across on-premises environments, Google Cloud, and other public clouds from a single control plane.
  • VMware Project Pacific and Tanzu Mission Control — announced at VMworld 2019, these offerings integrate Kubernetes natively into vSphere, allowing vSphere administrators to manage containerized workloads alongside traditional VMs from familiar tooling.
  • Microsoft Azure Arc — extends Azure management capabilities to Kubernetes clusters running outside of Azure, including on-premises and on competing public clouds, alongside Azure Kubernetes Service (AKS).

What these platforms share is that Kubernetes sits at the center of their hybrid strategy. Rather than abstracting Kubernetes away, they expose and extend it. Workload portability and cross-environment scaling are delivered by leveraging the same Kubernetes primitives — Deployments, Services, ConfigMaps, RBAC policies — across every target environment.

Why This Matters for DevOps Teams

For platform and DevOps engineers, the practical implication of this shift is significant:

  • Consistent developer experience: A developer writing a Kubernetes manifest on a local cluster (using tools like kind or minikube) can deploy that same manifest to a production cluster in any conformant environment. The API contract holds.
  • Portable CI/CD pipelines: Build pipelines that produce container images and apply Kubernetes manifests are inherently portable across cloud providers. There is no proprietary deployment agent to swap out.
  • Unified policy and observability: Platforms like Anthos and Azure Arc allow teams to apply consistent RBAC policies, network policies, and monitoring configurations across clusters running in different environments from a single pane of glass.
  • Reduced vendor lock-in risk: The CNCF conformance program provides a contractual API baseline that limits the risk of being stranded on a proprietary runtime.

Kubernetes as the Universal Control Plane

The trajectory of Kubernetes points toward an even broader role than container orchestration. Projects within the cloud-native ecosystem are extending Kubernetes to manage virtual machines (KubeVirt), serverless workloads (Knative), bare-metal provisioning, and legacy stateful applications. The Kubernetes API — with its extensible Custom Resource Definitions (CRDs) and operator pattern — is increasingly used as a universal control plane that can manage almost any infrastructure resource declaratively.

What OpenStack attempted to achieve through a purpose-built API surface, Kubernetes is achieving organically through ecosystem extension. The original promise of hybrid cloud — write once, run anywhere, manage consistently — is no longer aspirational. For organizations that have standardized on Kubernetes, it is operational reality.

Key Takeaways

  • Early hybrid cloud platforms (OpenStack, CloudStack, Eucalyptus) failed to deliver workload portability because hypervisor heterogeneity was too deep to abstract.
  • Containers solved portability at the application runtime level; Kubernetes solved it at the orchestration and lifecycle management level.
  • The CNCF Certified Kubernetes Conformance Program ensures API consistency across all major distributions and managed services, enabling genuine vendor interoperability.
  • Major infrastructure vendors (IBM, Google, VMware, Microsoft) have all launched Kubernetes-native hybrid cloud control planes that manage clusters across on-premises and multi-cloud environments.
  • Kubernetes is evolving beyond containers toward a universal, extensible control plane for all infrastructure types.
]]> https://www.bestdevops.com/how-kubernetes-has-changed-the-face-of-hybrid-cloud/feed/ 0 VMworld 2019: VMware Bets Big on the Convergence of Virtual Machines and Containers https://www.bestdevops.com/at-vmworld-vmware-bets-big-on-convergence-of-virtual-machines-and-containers/ https://www.bestdevops.com/at-vmworld-vmware-bets-big-on-convergence-of-virtual-machines-and-containers/#respond Fri, 30 Aug 2019 07:00:11 +0000 http://www.bestdevops.com/?p=7392 This article is based on announcements made at VMworld 2019 in San Francisco and reporting originally published by SiliconAngle. Analyst commentary is attributed to Wikibon.

VMware’s Strategic Pivot: Kubernetes Meets vSphere

VMware used VMworld 2019 in San Francisco to make a sweeping set of announcements aimed at strengthening its position in multicloud computing. At the centre of those announcements was a move that analysts have characterised as a classic “bet the business” gambit: Project Pacific, the architectural core of the forthcoming VMware Tanzu Portfolio.

Announced during the Day One keynote, Project Pacific will embed Kubernetes directly into the control plane of a future release of vSphere, VMware’s flagship server virtualisation platform. Beyond a simple integration, the project adds a container runtime into the vSphere hypervisor itself. A new construct called ESXi native pods combines the properties of Kubernetes pods and traditional virtual machines (VMs), with the stated goal of improving security and performance for mission-critical workloads — without forcing teams to choose between one runtime model and the other.

What Is the VMware Tanzu Portfolio?

At the time of VMworld 2019, the Tanzu Portfolio was available only in limited preview. Its core promise is a single control plane from which platform and DevOps teams can monitor, manage, and enforce policies across all Kubernetes clusters — regardless of which cloud or on-premises environment those clusters run in.

Key capabilities described at launch include:

  • Tanzu Mission Control: A centralised console allowing developers to use familiar vSphere tooling to deliver applications to Kubernetes clusters, while also exposing Kubernetes API constructs inside vSphere.
  • Kubernetes API access to VMware SDDC infrastructure: The tooling exposes VMware’s software-defined data centre (SDDC) virtualisation infrastructure via standard Kubernetes APIs, enabling consistent operations across hybrid and multicloud environments.
  • Unified DevOps view: Operators see Kubernetes constructs rendered consistently within vSphere’s interface, reducing the cognitive overhead of managing two distinct runtime environments.

VMware did not announce a general availability date for Tanzu at VMworld 2019, leaving customers reliant on the limited preview to assess real-world readiness.

The Business Logic: Why Kubernetes Migration Is Central to VMware’s Growth

Kubernetes alone is not a differentiator for any vendor — it is open-source infrastructure available to everyone. VMware’s wager is more nuanced: if it can make migration from VM-based workloads to Kubernetes-backed, multicloud-ready architectures fast and low-risk for its enormous enterprise customer base, it creates significant cross-sell opportunities for premium services built on top of that Kubernetes backplane.

At the time of the announcements, VMware reported that more than 70 million workloads ran on VMware infrastructure, with approximately 10 million already in the cloud. VMware Cloud provided a consistent hybrid cloud platform spanning AWS, Microsoft Azure, Google Cloud, and IBM Cloud, along with more than 60 VMware Cloud Verified partners worldwide.

The competitive urgency is real. Rival VM/container convergence approaches were already emerging, including:

  • AWS Firecracker and Fargate: Lightweight micro-VM runtimes from Amazon Web Services.
  • CNCF KubeVirt: An open-source project enabling traditional VM workloads to run alongside container workloads on Kubernetes.
  • Google gVisor: A user-space kernel providing container isolation with VM-like security boundaries.
  • Intel Kata Containers: Containers that run inside lightweight VMs to provide stronger isolation.

Each of these approaches addresses the same fundamental tension: containers offer density and speed, while VMs offer stronger isolation. VMware’s answer with Project Pacific is to converge the two at the hypervisor level rather than at the orchestration layer.

Key Kubernetes-Related Announcements at VMworld 2019

Project Pacific and Tanzu were not VMware’s only Kubernetes moves at VMworld 2019. The following announcements collectively show a strategy to make every layer of the VMware stack Kubernetes-aware:

  • Pivotal Acquisition: VMware’s agreement to acquire Pivotal deepened its stake in VMware Enterprise PKS (now VMware Tanzu Kubernetes Grid), the Kubernetes platform the two companies co-developed. The acquisition gave VMware direct control over a commercially supported Kubernetes distribution with an existing enterprise customer base.
  • Cloud Migration Services: A new console experience designed to simplify migration of VM workloads to hybrid clouds, initially focusing on VMware Cloud on AWS. Future support for VMware Cloud on AWS Outposts and VMware Cloud on Dell EMC was indicated. The new VMware CloudHealth Hybrid tool added per-workload optimisation for Kubernetes migrations, factoring in cost, performance, and security requirements.
  • Bitnami Acquisition and Project Galleon: VMware’s acquisition of Bitnami brought a large catalog of pre-built, scanned, and maintained application content for Kubernetes clusters, serving a developer community reported at 2.5 million users. Building on that, VMware launched Project Galleon (in beta), enabling enterprise IT departments to deliver pre-validated, multicloud-ready Kubernetes application stacks to their developers. ISV partners building on the Bitnami Community Catalog were also highlighted.
  • vSphere 6.7 Update 3: This release added support for high-performance containerised AI workloads powered by multiple NVIDIA GRID virtual GPUs per VM, acknowledging that a significant share of new containerised workloads are AI and machine learning applications.
  • vSAN 6.7 Update 3: Updated to provide container-ready storage infrastructure, enabling AI and next-generation containerised applications to operate consistently across multiclouds.
  • VMware Hybrid Cloud Operations Enhancements (AIOps): New AI-driven capabilities for deploying and managing containerised Kubernetes applications across multiclouds, covering cost management, resource governance, security, performance monitoring, and closed-loop remediation.
  • Wavefront Enhancements: Updates to Wavefront by VMware added automatic service discovery and monitoring for Kubernetes environments, including the ability to track health and performance of workloads running across more than 200,000 concurrent containers.

The Strategic Risk: VMs May Have a Longer Shelf Life Than Expected

VMware’s Tanzu strategy contains a structural tension worth understanding. By enabling VMs and containers to coexist indefinitely through ESXi native pods and Project Pacific, VMware may inadvertently reduce its customers’ urgency to migrate fully to a Kubernetes-native application backplane — which is the very outcome its cross-sell strategy depends on.

Evidence from VMworld suggested this tension is already playing out. Mark Lohmeyer, then Senior Vice President of VMware’s Cloud Platform Business Unit, noted in a theCUBE interview that customer adoption of VMware Cloud on AWS had grown sharply: a 4x increase in customers on the service and a 9x increase in VM count. That growth was being driven by lift-and-shift migrations — moving existing VMs to the cloud without re-architecting them — rather than by Kubernetes-native deployments.

Lohmeyer framed this as a feature, not a bug: “We could help them migrate to the public cloud very quickly without requiring any changes if they don’t want to. And then when they’re there, they can modernise at their own pace based on the needs of the business.”

For DevOps teams, this is a practical operating reality. Organisations with large VM footprints are unlikely to perform a “big bang” migration to containers. A platform that supports both — and allows phased modernisation — is more likely to see adoption than one that demands immediate re-architecture.

The risk for VMware is the inverse: if VM workloads remain economically and operationally viable for years, the incentive to purchase Kubernetes-native premium services from VMware is reduced. KubeVirt and similar projects further complicate the picture by offering open-source paths to VM/container coexistence that do not require VMware’s commercial stack.

What This Means for Enterprise DevOps and Platform Teams

The Wikibon analyst team offered the following guidance for VMware customers at the time of the VMworld 2019 announcements:

  • Evaluate Project Pacific through the limited preview: The primary criterion should be whether ESXi native pods genuinely improve security and performance for workloads that mix containers and VMs — not just whether the integration is technically functional.
  • Assess the broader Tanzu announcement set together: The individual announcements — Pivotal, Bitnami, Wavefront, vSAN, CloudHealth Hybrid — are designed to work as a suite. Evaluating them in isolation misses the strategic intent.
  • Do not assume full Kubernetes migration is imminent: VMware’s own data suggests that VM lift-and-shift remains the dominant motion for most enterprise customers. Plan for a multi-year coexistence phase rather than a near-term cutover.
  • Track competing convergence approaches: KubeVirt, Firecracker, Kata Containers, and gVisor are all maturing rapidly. Organisations with the engineering capacity to evaluate open-source alternatives should do so before committing to a proprietary convergence platform.

Summary

VMworld 2019 marked a clear inflection point in VMware’s positioning. By embedding Kubernetes into vSphere’s hypervisor through Project Pacific, acquiring Pivotal and Bitnami, and extending Kubernetes-awareness across its storage, monitoring, and cloud management portfolio, VMware made a co-ordinated bet that the enterprise path to Kubernetes would run through its existing infrastructure — not around it.

Whether that bet pays off depends on two variables: how quickly VMware can demonstrate that the Tanzu platform genuinely simplifies VM-to-Kubernetes migration at scale, and how long enterprise customers continue to invest in their existing VM-based workloads. As of VMworld 2019, both variables were moving in VMware’s favour — but the competitive landscape, from AWS to the CNCF ecosystem, was narrowing the window.

]]> https://www.bestdevops.com/at-vmworld-vmware-bets-big-on-convergence-of-virtual-machines-and-containers/feed/ 0 Container-Based Database Platforms: Fueling DevOps https://www.bestdevops.com/container-based-database-platforms-fueling-devops/ https://www.bestdevops.com/container-based-database-platforms-fueling-devops/#respond Tue, 02 Oct 2018 04:58:53 +0000 http://www.bestdevops.com/?p=4447 Source- containerjournal.com

Database systems traditionally have relied on rather complex, OS-specific clustering technology to provide high availability. Depending on vendor and configuration, these technologies included shared storage devices, transaction-based replication, storage replication or some combination thereof. In many cases, these configurations required complex storage and network configuration supported by multiple teams at significant cost.

As the use of virtualization became more widespread, virtual machines offered a degree of high availability, and many hypervisors offered some form of disaster recovery provided by storage replication. The database files were contained within a virtual file format, which made it easy and cheaper to implement; however, since the hypervisor was not aware of the transactional state of the database, it meant failing over could return a database in an inconsistent state.

The vast majority of early container deployments were web and application servers. This was for a couple of reasons, the biggest being the challenges of data persistence in an ephemeral container environment. When Google introduced Kubernetes, databases got both consistent storage and namespaces. This provided a couple of major benefits: It introduced high availability into the solution and separated the storage tier from the compute plane. These factors enabled administrators to have a high degree of flexibility in changing the compute resources for the database tier.

Containers offer many benefits over virtual machine deployment, since they run closer to the system and share operating system binaries. The first of these benefits is performance. Compared to a virtual machine, a database container will have better I/O response time. Secondly, containers allow for simplified deployment using their infrastructure as code model and higher density over virtual machine solutions. Also, since all of the containers on a given host share the same base operating system, the amount of patching is reduced.

Another major benefit is the ability to containerize a gold image or use a vendor-supplied image of an RDBMS. While an RDBMS such as MySQL has a very simple installation process, Oracle and SQL Server both require a fairly complex install, patching and post-installation configuration.

While most of the initial support for database containers was in the open source community for relational databases such as Postgres and MySQL and NoSQL solutions such as MongoDB, Redis and others, commercial database vendors including Oracle, Microsoft and IBM have introduced support for both Docker and Kubernetes in recent years. Kubernetes, via its persistent volumes and service configuration, allows for these databases to be highly available and perform actions such as rolling upgrades for RDBMS patches. Separating data and compute also allows for easier DevOps deployment workflows because of fewer moving pieces.

While implementing a new platform such as Kubernetes can be challenging for many enterprises, the “container as a service” offerings in the major public clouds (Amazon, Google and Microsoft) have made it easier to get started. There are still some challenges around maturity, security and integration with existing third-party applications.

Microsoft has made a big investment into SQL Server and the Kubernetes platform, recently introducing SQL Server 2019 at the Ignite conference. This release includes a new group of services called SQL Server Big Data Clusters, which combine a SQL Server database engine with Spark for machine learning and flexible compute and data pools that take advantage of the underlying Kubernetes infrastructure. This kind of commitment to the platform from a major vendor shows both its early maturity and significant future.

It will be several years before the deployment platform of choice for database servers is containers, and the biggest remaining challenge is disaster recovery. While the Kubernetes platform itself is highly available within a given data center, disaster recovery still requires the database platform to supply a mechanism to perform replication. Some platforms already support this, and I would envision more support to come from all the major vendors in the next year. The advantages of containers are very clear both from DevOps deployment scenarios as well as simplified administration, and this will ultimately drive more database workloads in this direction.

]]> https://www.bestdevops.com/container-based-database-platforms-fueling-devops/feed/ 0