Escaping Vendor Lock-in Jail (How Kubernetes Set Us Free) | A Four-Part Series

Background

HumanGov is a Model Automated Multi-Tenant Architecture (MAMA) that is meant to be used by the 50 states for personnel tracking. Currently the architecture is based upon containers orchestrated using Amazon Elastic Container Services (ECS). The architecture is not ready for go-live. All actions so far are for a proof-of-concept that is presented to the Chief Technical Officer (CTO) for review.

During the weekly team meeting Kim (Team Lead) reports that the current architecture cannot be easily migrated to another cloud provider. Woo (Chief Technical Officer) requires that whatever solution you move to should not increase the management overhead of the team. Ko (Lead User Experience Tester) reports that connecting via IP addresses is cumbersome. Lee (Security Lead) reported that packet captures of web site test traffic revealed employee information.

You first get the team to agree on the set of problems (and root cause):
Problem 1: The current architecture cannot be easily migrated to another cloud. (Elastic Container Services (ECS) only exists on AWS, creating a cloud vendor lock-in risk.)
Problem 2: Any solution presented should not increase the management overhead of the team. (Team hiring plans are based upon the reduced management overhead of running Elastic Container Services (ECS)).
Problem 3: It is difficult for the testers to keep track of what they are testing. (The systems can only be connected to using IP addresses, which is not user-friendly.)
Problem 4: Employee data can be seen in web site test traffic. (The application is transmitting data in plain text.)

After some thought, you propose solutions to (the reported issues):
Use Kubernetes instead of Amazon Elastic Container Services (ECS). (Kubernetes will avoid cloud vendor lock-in risk.)
Use Amazon Elastic Kubernetes Service (EKS) to provide a managed service for Kubernetes clusters. (EKS maintains the reduction in management overhead the team became accustomed to via ECS.)
Use Amazon Route 53 to assign domain names to the application resources. (Tracking names is more user-friendly than tracking IP addresses.)
Use AWS Certificate Manager (ACM) to manage certificates for the application. (Implementing certificates will enable the end user to securely transmit data to/from the application.)


This will be a four part series of articles where you implement a proof-of-concept of your proposed solution to use Kubernetes to set us free and escape the vendor lock-in jail :

1 of 4: Escaping Vendor Lock-in Jail (How Kubernetes Set Us Free)
In part 1, you will set up the Kubernetes Cluster on Amazon Elastic Kubernetes Service (EKS).

2 of 4: Escaping Vendor Lock-in Jail (How Kubernetes Set Us Free)
In part 2, you will install an AWS Application Load Balancer.

3 of 4: Escaping Vendor Lock-in Jail (How Kubernetes Set Us Free)
In part 3, you will use Kubernetes to deploy the HumanGov application for California.

4 of 4: Escaping Vendor Lock-in Jail (How Kubernetes Set Us Free)
In part 4, you will use Amazon Route 53 to name the application and AWS Certificate Manager to secure access to the application. You will also use Kubernetes to deploy ingress controller, so that Internet users can connect to the application. After testing, you will decommission the infrastructure.

Highlighting some of the aforementioned technologies:

Kubernetes

Kubernetes is an opensource container orchestration engine. Kubernetes can be used to automate the deployment, scaling, and management of containerized workloads. We are using Kubernetes in this example to move away from Amazon Elastic Container Services (ECS).

Amazon Elastic Kubernetes Service (EKS)

One thing you need when you run Kubernetes is a control plane. What if you could have a managed service that handles the control plane for your Kubernetes? Guess what? You can. Amazon's managed service for the control plane is EKS.

Amazon Route 53

If you want to connect to Internet resources by something other than addresses, then you need to setup some kind of resource naming service. That is what Domain Name System (DNS) provides. You can buy a domain from a domain registrar. After you have a domain, you then need to manage the records in that domain. Amazon Route 53 provides a DNS management service. Amazon Route 53 includes features that can help you route traffic to endpoints based on latency, geography, and endpoint health. For purposes of this proof-of-concept, we are primarily using Amazon Route 53 to manage DNS records.

AWS Certificate Manager (ACM)

If you desire to secure your website, then you will go down the road of purchasing certificates from a third party, uploading certificate requests (often manually copying/pasting text all over the place), fumbling around with uploading responses (this also often involves wrangling text), and then repeating this dance every so often when it is time for a renewal. What if there was a managed service that would handle all of this within your cloud provider and present it in a more user-friendly way? Well, there is. In the case of AWS, this service is ACM.

References

Amazon Route 53 FAQs

https://aws.amazon.com/certificate-manager/faqs/

Domain Names - Concepts and Facilities

Domain Names - Implementation and Specification

Kubernetes Documentation | Kubernetes

What is Amazon EKS

What Is AWS Certificate Manager? - AWS Certificate Manager

What is DNS? – Introduction to DNS - AWS


Lewis Lampkin, III - Blog

Lewis Lampkin, III - LinkedIn

Lewis Lampkin, III - Medium

Comments

Popular posts from this blog

Containing the Chaos! | A Three-Part Series Demonstrating the Usefulness of Containerization to HumanGov

Orphaned No More: Adopting AWS Lambda