Consumer products company moves from Kubernetes to cloud-native DevOps

The project

This large multinational consumer products company was developing and hosting hundreds of applications deployed to half a dozen Kubernetes clusters managed with Helm. The clusters and their Jenkins pipelines had grown significantly over the years, and the IT department wanted out: the Kubernetes learning curve was too steep, and maintaining the infrastructure behind a self-managed DevOps architecture had become a job of its own. The company brought in Winmill as trusted advisor and implementer for the transition to cloud-native, serverless, managed services in a native AWS DevOps architecture.

The challenges

• A demanding pilot. The pilot application was the company’s largest and most complex microservice architecture to date, and the new architecture had to support native cloud development and iterative deployment inside a completely locked-down hosting environment.
• No disruption. The existing Kubernetes DevOps architecture had to keep running while the new pipelines were built.
• A monorepo problem. Each microservice needed its own build and deployment pipeline, but shared libraries and interdependent build definitions kept all the source code in a single git repository, and AWS-native DevOps tools can’t trigger individual pipelines based on a change to a directory. The solution had to close that gap using native tools only.

The solution

Winmill extended AWS’s native capabilities with a serverless Lambda function triggered by a JSON POST from GitLab. The function parses the payload to determine which directory received the commit, and therefore which microservice pipeline to trigger. It’s externally configurable through DynamoDB and runtime environment variables, so the same function can be reused for any future microservice project without a rebuild.

The pipelines are built on AWS CodePipeline and deploy to scalable Elastic Beanstalk instances running on a private network behind a DMZ. Microservices are reachable from the outside world only through the AWS API Gateway, connected over a VPC link so no deployment is exposed to the internet. No third-party tools are required anywhere in the architecture: every piece is native to AWS, covered by AWS SLAs, billing, and support, and the entire architecture can be captured and redeployed with CloudFormation as infrastructure as code.

The results

• A smooth transition. The new architecture went live while the legacy Jenkins, Helm, and Kubernetes pipelines and production clusters kept running.
• Easier to maintain. The team spends far less time troubleshooting Helm charts and obscure Kubernetes and Docker configuration issues, and the gentler learning curve has increased developer adoption and engagement.
• More reliable. Mysterious Jenkins outages and deployment failures gave way to smooth builds and reliable deployments, thanks largely to the fully serverless DevOps support infrastructure. The only servers left to think about are the Beanstalk deployment instances themselves.
• More secure and more scalable. The entire hosting infrastructure sits behind a DMZ with no public IPs on any microservice server, the DevOps tooling is no longer an attack surface, and Beanstalk environments scale to whatever limits the company chooses rather than the fixed capacity of a Kubernetes cluster.