4K Migrates Workloads To GKE With CI/CD Automation

Overview

4K is the world’s first and largest digital marketplace for crypto collectibles and non-fungible tokens (NFTs). The US based incentive-aligned peer-to-peer marketplace offers users all the features of a traditional marketplace but with significantly lower fees, faster settlement times than any Web2.0 incumbents, and increased safety for both the buyer and seller. They achieve this by pre-authenticating and storing the items offered on their marketplace before sellers find buyers so that buyers can shop with confidence knowing that what’s listed online is available and authentic.

4K partnered with D3V to optimize and migrate their containerized application hosted on Google Compute Engine VMs to Google Kubernetes Engine (GKE), thereby improving their infrastructure’s scalability and ability to meet traffic demands while also reducing operational costs.

The Challenge

Being the largest digital marketplace for crypto collectibles and non-fungible tokens (NFTs) meant that 4K’s application workload was increasing by the day. The marketplace’s application was already running on Google Cloud VM instances but with growing demand and updates, the VM instances were getting complicated because for each update to the application developers were required to make manual changes on the VM instance. This impacted the team’s Developer Velocity and resulted in increased time to market.

In order to maintain their competitive edge, 4K needed a CI/CD pipeline to automate part of their application lifecycle to deploy changes and update applications rapidly with a 1-click deploy. Additionally, having VM instances wasn’t the most ideal solution for scalability as more instances and storage would be required, resulting in increased costs and operational overhead. To top it all off, 4K was using standalone GCE instances and not part of a Managed Instance Group which would have allowed them to scale.

To prepare for continued growth and to ensure that customer experience remains enjoyable, 4K decided to update their existing cloud-native architecture to better handle future growth while also reducing operational overhead.

Our Solution

After sorting through a thorough assessment of options and weighing the pros/cons of each, D3V guided 4K in its decision to migrate to Google Kubernetes Engine (GKE) as its solution to provide a managed environment for deploying, managing, and scaling containerized applications using Google infrastructure. The GKE environment consists of multiple machines grouped together to form a cluster.

The D3V team was prepared to overcome the challenges faced by 4K by assessing their current architecture and revamping their whole setup to have a new microservices based architecture for maximum efficiency. The main challenge was to automate the build process using a CI/CD Pipeline. CI/CD pipeline introduces automation to improve the process of application development, particularly at the integration/testing phases and during delivery and deployment. Although it is possible to manually execute each of the steps of a CI/CD pipeline, the true value of CI/CD pipelines is realized through automation.

We used the GitOps style which is key to automate Environment Repo and App Repo. A key part of GitOps is the concept of “environments-as-code”: describing your deployments declaratively using files (Kubernetes manifests) stored in a Git repository.

First, all the GKE Manifests were created and pushed to Github Repository (i.e., Environment Repository). So you already have an Application Repository for updating code changes. We have three App Repos and four Environment Repositories. The three App Repos consists of:

• Frontend
• Timed out errors when users attempted downloading certain PDFs
• Backend
• Account
• Mesh

The Application Repositories are used for the Continuous Integration (CI) as we need to build the application image from the Dockerfile present in the Repository. After the build, the image is pushed to Google Container Registry (GCR) while the Environment Repositories that have the k8s Deployments and Manifest files consists of:

• Frontend Environment Repository
• Backend Environment Repository
• Account Environment Repository
• Mesh Environment Repository

Each App Repository has an associated Environment Repository (1:1 mapping) as shown above and includes all the GKE Manifests. The Continuous Development (CD) part consists of 2 files, cloudbuild.yaml and a script file. The build file issues a command to run the script file and connects with the GKE cluster to deploy the updated manifests/templates.

The Build Config File is referred to in the cloud build and it reads the scripts to run the file. Once the code changes are made, those changes are pushed to the repository and the CI process pushes the Image in the Google Container Registry (GCR). Then once the Image tag is updated, It will run the CD process that runs the script file to pull the image from GCR and update the deployments with the changes that reflect in the updated container image. The developers only need to update their code and the CI/CD pipeline handles the rest of the work.

All of this means that everytime developers need to update the application, they can just push changes and the rest will be taken care of by the CI/CD pipeline, giving developers more time to focus on core development of the application. Additionally, developers need not wait for the DevOps team to update the file and deploy the manifests. Instead, they can always keep running tests on the application giving them more time to work on their features.

Finally, D3V kept the 4K’s own development team informed on the weekly targets and overall progress. In addition to this, 4K’s team was demoed in the meetings scheduled. Several tasks that needed internal testing were done before the deadline to ensure the platform was 100% ready without delays.

Key Accomplishments

Developed a CI/CD Pipeline to automate the whole process by just a Trigger Button

D3V applied the best practices for GCP and came up with a CI/CD Architecture that automates the deployment process with just a Trigger Button using a combination of GCP services such as Google Kubernetes Engine, Cloud Build, and Cloud Monitoring.

D3V leveraged cloud Build triggers for following the GitOps Style based on the given architecture. Cloud Build is a service that executes your builds on Google Cloud Platform’s infrastructure. It can import source code from a variety of repositories or cloud storage spaces, execute a build to your specifications, and produce artifacts such as Docker containers or Java archives. Our goal was to follow GitOps style using Cloud Build to have a seamless automated build process.

This architecture uses two Git repositories:

• app repository: contains the source code of the application itself
• env repository: contains the manifests for the Kubernetes Deployment

Less workload for the Developers

The CI/CD pipeline automates all the steps and updates the files in the GKE manifests and all the changes are reflected in the application, significantly reducing the operational overhead for developers. Now, 4K developers only need to work on code development and make changes and update those changes in their App Repositories. Then DevOps (CI/CD) will automate all these changes and update during the build process.

Interested in implementing DevOps?

Good news! D3V Tech is holding one-on-one workshops for DevOps where we:

• Discuss DevOps tools on GCP
• Identify challenges and potential DevOps solutions
• Develop a roadmap
• Develop a workforce/workload analysis
• Breakdown the costs involved
• Hold a general q&a
  and much more