Modern cloud providers offer compelling opportunities to modernize IT infrastructure and gain operational efficiency through cloud-native design practices, DevOps, containers and more. However, moving to the cloud isn't easy.
Those who join the cloud movement soon learn that there are a lot of moving parts to be managed and coordinated in different ways in order to achieve the desired results. This usually leads to the realization that although cloud provides the ability to implement a lot of interesting techniques, it is ultimately a tool, and not a solution. And as it is for every solution that leverages new technologies, careful planning and design of your future platform is the key to success.
In this blog we will detail the steps you can take to migrate from Pivotal Cloud Foundry (now called VMware Tanzu) to AWS in a matter of days using the PCF (Pivotal Cloud Foundry) Kubernetes Migration Starter Kit we developed.
So, what is a microservices platform, really? As a first step toward understanding, let's say that we want to accomplish the goal of going mainstream by running containerized applications in the cloud. The most popular platform for doing this nowadays is Kubernetes, available in many flavors as a managed service offering from all major cloud providers. However, as we sometimes joke within our company, "One cannot simply put a container in Kubernetes and expect it to work". As soon as you try to facilitate such a simple “container drop”, you will be faced with dozens of questions that need to be addressed, and answering them one by one slowly reveals the target state of your cloud environment before deploying a single application with business logic:
The interesting thing about a microservices platform is the fact that there is no “holy grail” technology-wise for every placeholder. Instead, the market offers multiple solutions which can be chosen based on workload specifics, required external integrations, adoption complexity, or sometimes even team preference. But the general architecture always stays the same, and can be implemented on top of any modern cloud, or even on-premise system. With a careful choice of technologies, it can even be made portable enough to fulfill the concept of a true multi-cloud solution, although this is rarely required in practice.
The process of cloud migration requires a lot of steps, including the creation and implementation of a platform blueprint with technology choices for each box, which can typically take anywhere from 1 to 3 months based on a particular toolset and the development team's capacity. It is only after that, finally, that you can start to move applications over. And then you get a new client and have to repeat this process from scratch again. Not an exciting or efficient approach is it? Especially when you consider that we haven’t even factored in the plan for the platform to become a live system, which requires additional features like IaC and CI/CD pipelines, deployment orchestration, and more.
Surely there must be a better way? Thankfully, there is! Building a reusable reference implementation for our platform, which includes all the "plumbing", makes it possible to focus on business applications from day 1, while opening up additional time to revisit, fine-tune, or even replace some components as required later on. The result is a vastly accelerated time-to-market with little to no disruption to the wider business ecosystem, and much simpler change management control.
On our quest to find a practical use-case for implementation of our microservices platform, we developed the idea of using it for particular migration scenarios; in this case, migrating from PCF to AWS EKS. As we have observed, many of our customers do not start from the ground up, but instead, want to leverage modern-day technologies for their legacy workloads. One of the more popular platforms many of our customers use today is Pivotal Cloud Foundry, now known as VMware Tanzu Application Service. As a platform, it offers many great pre-configured components which deservedly increased its popularity; however, some customers do find it to be quite restricted in terms of customizability and scalability, and want to future-proof themselves, as well as cut down on the licensing costs.
While PCF has a very static view on application development and deployment, Kubernetes provides a robust but flexible platform. In our Kubernetes migration experience, our developers reveled in their newfound increased agility, greater sense of control, and the ability to deploy applications without having to involve support teams. This ultimately led to improved productivity, fewer defects during deployments, and a better DevOps culture.
Speaking of DevOps culture, in 2021, as toolchains moved from scripts or “Only infrastructure management tools” to widely used programming languages and libraries, we began to observe the assimilation of this culture into the DevOps and Application engineering teams - two completely separate units in the past, now operating more cohesively and efficiently.
Now that we have defined our Kubernetes and open-source stack migration goal, let's take a look at the technology choices and some details of the implementation.
Grid Dynamics has a long history of implementing various solutions with AWS, ranging from custom application development (both tooling and code), leveraging cloud-native and AWS-specific technologies, and working together with Amazon as development partners. Along with our customers, we have gained significant confidence in the platform and the vision behind its roadmap.
Some of the common reasons to make a choice in favor of a cloud-based platform, and AWS in particular, are:
EKS Blueprints is a new open-source framework from Amazon aimed to ease and simplify some commonly used configuration patterns. It provides a level of abstraction on top of the AWS Cloud Development Kit (CDK: framework for provisioning cloud application resources using familiar programming languages), and helps to translate reference architecture into infrastructure building blocks. More importantly, it incorporates Amazon's best practices and methodology and provides necessary guardrails in order to help build well-architected EKS-based environments with built-in security enforcements. It can also easily be extended with the help of add-ons, which already include a couple of well-known AWS-backed and open-source technologies, and it is relatively easy to add new ones should the project requirements call for it. You can find more information and examples in the official EKS Blueprint quick start documentation.
We leveraged a CDK-based implementation for our exercise, however, it is also available as a Terraform module, which we intend to try out in the next version of our starter kit.
Pivotal Cloud Foundry has a few core mechanisms relevant to the scope of migration:
The general structure of the resulting solution, based on top of AWS-backed services, can be described as follows:
Core components of the starter kit include:
Probably the most challenging and interesting aspect of the migration is supporting simultaneous deployments to both the old PCF environment and new cloud platform using the same codebase without code changes in PCF native apps - buildpacks, services (also their credentials) management and manifests.
At a glance, the migration process using the starter kit can be distilled into the following steps:
Of course, a lot of action happens behind the scenes. For example, if we dig deeper into the implementation of CI/CD pipelines which are provisioned as a part of the migration, we would see the following picture:
If you’re thinking about moving from Pivotal Cloud Foundry to AWS Kubernetes, our PCF Kubernetes starter kit leverages AWS EKS Blueprints and Grid Dynamics’ microservices platform to:
If you're interested in a more in-depth review of the implementation or specific features of the starter kit and technology, get in touch with us to start a conversation!