Case study: Container orchestration for dating website
The story how dating website managed to overcome the downtimes after having the chosen technology for container orchestration changed
increase in availability
Increase in rollback speed
DevOps consultant, co-founder
About dating website
Dating Website(DW) is a dating service that connects people all around the world. Everyday this website maintains over 3 000 users.
In its difficult mission DW utilizes a laravel app and relies on docker as both production and local development environment.
DW has went a long way in it's journey towards operational excellence. In order to resolve issues with local environment and ease the process of CI/CD implementation, they decided to try container orchestration. DW heavily relies on AWS, which at that point hadn't had a Managed Kubernetes Service yet.
As a result, the decision was taken to move to Docker Swarm instead, as a solution that requires less effort to be configured and deployed. Also it always sounds reasonable to stick to the solution maintained by the Docker authors themselves. Right?
Even though dockerization has taken the development to the new level, production environment was far from ideal. DW uses 2 docker containers - nginx and php-fpm. In order to keep images as small and efficient as possible and still have the ability to flexibly rollback to any version, it was decided to place the website code in the php-fpm container and then mount the code to nginx container from the fpm.
Docker Swarm has shown its unsuitability for such environments. Each deployment DW was facing a small downtime which occurred when a new fpm container has already spun up but nginx hasn't. During that time, nginx was losing the access to the old volume with code whilst the new one wasn't available for it. It was an architectural limitation.
Docker Swarm is perfectly suitable for a complete microservice architecture where containers aren't tied up so close. DW was struggling to bypass this limitation until the day EKS has been released.
Unlike Docker Swarm, Kubernetes has a number of additional layers of abstraction, which, despite the complexity, makes it easier to configure, manage and deploy applications. Kubernetes atomic unit, called Pod, allows to create a tightly coupled set of containers that behaves as a whole.
As a result, it allowed DW to release and rollback to the specific version of a pod and deployment instead of containers itself and solved the issue of a downtime during the release