Our path towards Kubernetes

Kubernetes is an enterprise production-ready container orchestration system. We were first introduced to Kubernetes in July 2015 when v1.0 was released. At that point in time, we had considered using it to divide and conquer some of our workloads but didn’t end up using it as we weren’t at the stage of needing multi-node or better orchestration. However, we did migrate our development environment to containers (Docker).

When we first came across Docker, it was almost a no-brainer for us to adopt it as part of our development toolchain, as it allowed us to easily create and replicate exact configurations for each developer on the team using a relatively simple one-liner command.

DevOps transformation to date

As with any tech startup, the ability to move faster, reduce release cycle, and build software that is able to handle constant requirement changes were crucial. We went through DevOps transformation and cloud adoption over the last few years. And we managed to achieve the following:

• Containerized environments — 20+ Docker repositories and docker compose for orchestration of dev environment.
• Micro frontends — monolith UI to 50+ micro frontend repositories.
• Microservices for new projects (still need to migrate legacy applications)
• CI/CD pipeline — 2–4 weekly deployment to multiple deployments per day.
• AWS Cloud adoption — shift from ec2 only, to utilise tools such as API Gateway, Lambda, SQS, SNS, ElasticBeanstalk, IAM, S3, etc.
• Monitoring — Some metrics with alerts and logging.

We have made much progress, but we’re not done yet and there are still many problems unsolved.

Kubernetes revisited

In 2017–2018 Kubernetes has really grown in terms of adoption and community, particularly around the concept of Service Mesh. I have recently attended the inaugural KubeCon China 2018 in Shanghai. And I’m impressed with the breadth and depth of capabilities Kubernetes now supports. They have a large active community of developers and have some of the biggest names in tech as their end-users, such as JD.com, Pinterest, eBay, Netflix, Uber, Lyft to mention a few. Many enterprise vendors are building application and software suite around this whole ecosystem, trying to carve out a piece of the cake. It has certainly become a mainstream system.

Why, why now?

As a startup, this is a question I constantly ask myself when making decisions around whether something should be done. As we have decided to adopt the practice of microservices, through a step by step approach. I realised that we are missing something to manage and control them. This missing management piece is preferably as-code (so it’s repeatable). Some criteria I was looking to solve:

• Discovering services
• Microservices version dependencies
• Application snapshot
• Mutual TLS communication
• Removing toil
• Observability — Metrics with alerts, tracing, logging

And as an added benefit, this moves towards Infrastructure as Code and vendor agnostic, which sets us up for easier expansion cross-continents when the need arises.

What’s next?

Rearchitecting from monolith application to microservices is time-consuming and difficult! I will be working towards moving some if not all, of our infrastructure into Kubernetes as a lift and shift migration. The thinking is to get familiar with the environment and start with running with some of the features that come with Kubernetes, such as observability, self-healing, mass updates (for security patches), etc. And as a second phase, start to refactor towards microservices across the stack.

Stay tuned for updates on our journey towards Kubernetes!

Let me know your thoughts in the comments below, or connect with me directly on Twitter @kcjl519.

Let us know in the comments below what you think and if there are any tips you have yourself. And don’t forget to give this article some claps!