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

Kubernetes 1.15: Extensibility and Continuous Improvement

Kubernetes 1.15: Extensibility and Continuous Improvement

We’re pleased to announce the delivery of Kubernetes 1.15, our second release of 2019! Kubernetes 1.15 consists of 25 enhancements: 2 moving to stable, 13 in beta, and 10 in alpha. The main themes of this release are: Continuous ImprovementProject sustainability is not just about features.

Read More
Rate Limiting at the Edge

Rate Limiting at the Edge

I’m sure many of you have heard of the “Death Star Security” model—the hardening of the perimeter, without much attention paid to the inner core—and while this is generally considered bad form in the current cloud native landscape, there is still many things that do need to be implemented at edge in order to provide both operational and business logic support. One of these things is rate limiting. Modern applications and APIs can experience a burst of traffic over a short time period, for both good and bad reasons, but this needs to be managed well if your business model relies upon the successful completion of requests by paying customers.

Read More
Server Name Indication (SNI) Support Now in Ambassador

Server Name Indication (SNI) Support Now in Ambassador

We’ve discussed many interesting use cases for SNI support within the edge proxy/gateway with both open source and commercially supported users of Ambassador. In a nutshell (and with thanks to Wikipedia), SNI is an extension to the TLS protocol which allows a client to indicate which hostname it is attempting to connect to at the start of the TCP handshaking process. This allows the server to present multiple certificates on the same IP address and TCP port number, which in turn enables the serving of multiple secure websites or API services without requiring all those sites to use the same certificate.

Read More