Incremental App Migration from VMs to Kubernetes: Planning and Tactics

Incremental App Migration from VMs to Kubernetes: Planning and Tactics

  • August 3, 2019
Table of Contents

Incremental App Migration from VMs to Kubernetes: Planning and Tactics

One of the core goals when modernising software systems is to decouple applications from the underlying infrastructure on which they are running. This can provide many benefits, including: workload portability, integration with cloud AI/ML services, reducing costs, and improving/delegating specific aspects of security. The use of containers and orchestration frameworks like Kubernetes can decouple the deployment and execution of applications from the underlying hardware.

In the previous article of this series I explored how to begin the technical journey within an application modernisation program by deploying an Ambassador API gateway at the edge of your system and routing user traffic across existing VM-based services and newly deployed Kubernetes-based services. This second article builds on this journey, and provides an overview of how you can plan the migration, and also provides guidance on containerising workloads and some networking gotchas to watch out for. The next article in the series will look at using a service mesh, like HashiCorp’s Consul, to route service-to-service traffic seamlessly across all platform types, regardless of whether your applications have been containerised or not.

Source: getambassador.io

Share :
comments powered by Disqus

Related Posts

Introducing Volume Cloning Alpha for Kubernetes

Introducing Volume Cloning Alpha for Kubernetes

Kubernetes v1.15 introduces alpha support for volume cloning. This feature allows you to create new volumes using the contents of existing volumes in the user’s namespace using the Kubernetes API. Many storage systems provide the ability to create a “clone” of a volume.

Read More
Future of CRDs: Structural Schemas

Future of CRDs: Structural Schemas

CustomResourceDefinitions were introduced roughly two years ago as the primary way to extend the Kubernetes API with custom resources. From the beginning they stored arbitrary JSON data, with the exception that kind, apiVersion and metadata had to follow the Kubernetes API conventions. In Kubernetes 1.8 CRDs gained the ability to define an optional OpenAPI v3 based validation schema.

Read More