Innovate and Migrate: A Forward-Thinking Journey from On-Premise to Kubernetes Engine

Setting the Stage

Our Warehouse is a crucial part of the business. All delivered orders in Boozt had been packed and sorted in the Warehouse. Some services responsible for packing and sorting orders ran on on-premise servers. In this article, I’ll describe how we migrated these services from the on-premise server to the Google Cloud Kubernetes Engine (GKE).

Our initial point was ten months before the end of the server’s warranty, applications written on Python 2, C, and the old version of Golang. The persistent layer for those apps was MongoBD 4, which was as old as the virtualization platform we used VMware.

All these things cause the following problems:

• Cost of server ownership. To replace the hardware is only the tip of the iceberg. You need somebody to maintain servers and someone with the expertise to maintain the virtualization platform. And this person should be available 24/7.
• Nobody wants to maintain and work with the legacy codebase.

Those things push us to consider the option to migrate to the cloud. Initial estimation showed that the cost of running all our services in the GCP is acceptable. After the network speed and latency test, we decided to migrate to the cloud.

The Pre-Migration Phase: Planning and Preparation

The first step in the migration process was to make the code maintainable. For this purpose, we removed all legacy code written in Python 2 and C programming language and rewrote those services on Golang.

The second step was to provide continuous integration and delivery. In the Boozt, we use Gitlab as a version control and CI/CD. From a technical point of view, we’re building binary files in CI docker runner, establishing a connection via VPN from the docker image to the Warehouse network, uploading files via SFTP, and restarting the service with Systemctl via SSH.

At the end of this phase, we had a maintainable application. We solved some performance issues, and if you have a maintainable and easy-delivering application, it is hard to resist the temptation to provide new features. These new features positively impacted Warhouse’s performance during the last Black Friday season.

Regarding planning, during this phase, we clarified what bottlenecks we have and what we want to achieve with this migration.

The easiest way to migrate to the cloud was to move virtual machines to the cloud. The apparent cons of this approach are difficult horizontal scalability and non-optimal resource utilization. The second option was Kubernetes. We chose the second option.

The Cloud’s Call

You can’t just migrate to the cloud. Your applications should be cloud-ready. Cloud-ready applications sound shiny and fancy, but what does it mean for us? During migration, we focused on the most essential characteristics to us:

1. Containerization: Cloud-native applications are often packaged as containers, encapsulating the application and its dependencies. This ensures consistency across different environments and simplifies deployment.
2. Resilience: Cloud-ready applications should be fault-tolerant and resilient. They can continue to operate smoothly even if there are failures in the underlying infrastructure.
3. DevOps Practices: Cloud-ready applications embrace DevOps practices, promoting collaboration and communication between development and operations teams. Automation and continuous integration/continuous deployment (CI/CD) pipelines are commonly used.

We started with containerization. We removed an application’s config file, moved settings values to environment variables, wrote docker files, updated our CI/CD pipelines in GitLab to build images, and put them into the artificial registry.

Regarding resilience, we fixed many bugs, and some app refactored parts are responsible for connection with other systems.

One of the challenges was related to the parcel sorting system. We have a conveyor belt in the warehouse for sorting packages by destination. On this belt are placed cameras that read barcodes from packages and send this data to PLC(Programmable logic controller). We utilized the OPC protocol and TCP socket with these Programmable Logic Controllers (PLCs). For TCP socket connections, it establishes a bidirectional connection. In this setup, the client connects to the server; conversely, the server connects to the client. Bidirectional communication in that manner is a problem by itself, especially in Kubernetes, in a world with a dynamic environment. So, we solved this by replacing these PLCs on OPC and refactoring our services, which fixed some old communication bugs.

Elevating DevOps Excellence: A Symphony of FluxCD, GitLab, and Helm Charts

In our migration odyssey to Google Cloud Kubernetes Engine, FluxCD, GitLab, and Helm Charts emerged as our triumvirate of innovation, shaping our DevOps practices into a masterpiece of continuous deployment and collaboration.

1. FluxCD: Enabling GitOps Mastery

FluxCD, our linchpin in the GitOps landscape, empowered us to synchronize our Git repository with our Kubernetes cluster effortlessly. As the silent sentinel, FluxCD ensured that every change committed to Git was automatically propagated to our cluster, orchestrating a harmonious deployment dance. GitOps, epitomized by FluxCD, became our guiding principle, ensuring our infrastructure mirrored our version-controlled configurations.

2. GitLab: The Epicenter of Collaboration and CI/CD Brilliance

GitLab, our nexus of collaboration, elevated our DevOps symphony to new heights. Its version control prowess provided a sturdy foundation, allowing developers and operations teams to collaborate seamlessly. Like a virtuoso performance, GitLab’s CI/CD pipelines meticulously orchestrated our testing and deployment endeavors. With GitLab’s collaborative environment and automated pipelines, our applications evolved and thrived in the ever-changing landscape.

3. Helm Charts: Crafting Artful Deployments

Enter Helm Charts, the artisan artisans of our Kubernetes deployments. With Helm, we encapsulated our applications into versioned, shareable packages, enabling consistent and repeatable deployments. Helm Charts, akin to a well-composed score, defined the structure and configuration of our applications. The ability to templatize our deployments ensured flexibility, allowing us to navigate the nuances of different environments seamlessly.

4. The Symbiotic Harmony: FluxCD, GitLab, and Helm Charts

Our DevOps practices found their peak in the seamless blend of FluxCD, GitLab, and Helm Charts. FluxCD’s GitOps mastery effortlessly connected with GitLab’s collaborative strength, creating a system where code changes triggered automated deployments orchestrated by Helm Charts. This perfect collaboration ensured that every application release was not just a deployment but a well-organized performance, where version control, collaboration, and deployment intricacies blended seamlessly.

5. A Future Symphony of Continuous Innovation

Our reliance on FluxCD, GitLab, and Helm Charts remains unwavering as we navigate the ever-evolving cloud expanse. Together, they have sculpted our migration journey into a saga of continuous innovation. What was once a migration endeavor has transformed into a perpetual symphony, where the orchestration of code, collaboration, and deployment intricacies composes the anthem of our DevOps excellence.

In this ongoing symphony, FluxCD, GitLab, and Helm Charts are not just tools; they are our artistic instruments, guiding us toward a future where continuous innovation is a practice and a way of life.

Conclusion: Embracing the Future

Our migration from legacy servers to Google Cloud Platform signifies more than a technological shift — it’s a testament to adaptability and innovation. Through meticulous planning and innovative tools like FluxCD, GitLab, and Helm Charts, we transformed our approach to technology.

We stand at the brink of limitless possibilities as we conclude this migration. The cloud isn’t just a destination; it’s a canvas for our ideas to flourish.