Solution Details

Developing a modern application is a lot of work, often by a large team of people. 

We often focus on the effort of writing and testing the code to launch the application (Day1). 

However, the app will only launch once, but then needs to be operated and upgraded many times for years to come (Day2). 

Without careful planning, the cost of Day2 can be just as high as Day1, keeping expenses high or increasing forever, and consuming top talent for the long term.

We often think of these upgrades as just a change to application code, but there are dependencies on the environment and tooling versions that will need to be upgraded over time, as well. 

For example, the EC2 servers the apps run on will need hardware or operating system upgrades.  The EKS Kubernetes version will need to be upgraded to stay supported by AWS.  The open source tools supporting the applications, for security, observability, networking, etc versions will need to be upgraded.  All of these upgradeable components need to work with each other, and can’t be upgraded in a vacuum, without considering the dependencies on the other components.

Solution requirements:

• EKS Production and Canary clusters

• Cluster comparison for app and tools version difference

• Testing in the Canary EKS cluster

• Migrating traffic to the Canary EKS cluster

• Possible reversion to old production EKS cluster

KAOPS enables you to:

• Reduce AWS EKS-based EC2 bill 20-60%

• Reduce cloud operations cost by 60%

• Optimize workload performance

• Green energy savings

How KAOPS does it

Nethopper KAOPS is a cloud native management platform that works with any cloud and Kubernetes, which uses GitOps blueprints to simplify cloud operations and deploy container workload and open-source tools.  

KAOPS has a blueprint for cloning a production EKS cluster into a Canary EKS cluster, where the new tools and application workload versions are deployed and tested. 

Once the user verifies that all the dependencies are met and the applications pass their test, application traffic can be re-routed (using AWS Route53) from the production to Canary EKS cluster. 

If any problems occur, the user can simply route the traffic back to the previous production EKS cluster, which remains unmodified. 

Once the Canary EKS cluster is in production, you can remove all workloads running on the old production EKS cluster and/or turn it off.