Unpopular opinion: no we won’t go with K8s
We want managed containers
We received a few questions after publishing that we’ve chosen Amazon ECS with AWS Fargate as our platform to run our containerized Spring MVC app. They were all about why we didn’t choose the obvious solution: Kubernetes (K8s). Indeed, AWS provides Amazon EKS, a managed K8s service. So why didn’t we chose this option?
TL;DR; K8s is a beast we choose not to fight with.
Don’t get me wrong, I’m not saying K8s is not a good platform. The vibrant ecosystem around it proves it is a good one. I’m just saying it is not for us. Let me explain you why.
Disclaimer
I Love My Local Farmer is a fictional company inspired by customer interactions with AWS Solutions Architects. Any stories told in this blog are not related to a specific customer. Similarities with any real companies, people, or situations are purely coincidental. Stories in this blog represent the views of the authors and are not endorsed by AWS.
Know your force
Our engineering org is a software development org at its core. Inès, our CTO, was our first software development engineer and our first IT ops too. But she was definitely more a software development engineer than an IT ops. Of course, over the course of the years, we build an awesome IT ops team to operate our IT infrastructure. I truly value their work because they saved my nights and week-ends more than I did. However, it has always been a company choice to invest no more money than required in our IT infrastructure. It has sometimes been at the price of outages when traffic peaks occurred Nevertheless, it was assumed by the leadership team.
It is the same with headcounts. Our leadership team considers our software development workforce as an asset that produces values for the company. On the other hand, our leadership considers our IT infrastructure and our IT ops workforce as a cost. You may find this unfair but it is how it goes here. It has very concrete impact on how things are managed. While most our software development engineers are in-house employees, most of our IT ops employees are contractor employees. We also have more headcounts in our software development teams than in our IT ops teams.
So when it comes to make technology choices that engage the company on the long-term, we favor technologies that simplify the life of our software development teams while minimizing infrastructure investments and IT operations.
Know what you’re looking for
We already discussed in previous posts (post 1, post 2, post 3) that our senior leadership team has asked us to accelerate our release cadence to increase our customer outcomes and our business outcomes and keep up with our new competitors. After due diligences and first two successful projects, they also decided to move all-in on AWS to give us all the flexibility required to transform how we develop and operate our systems.
They made very clear that we couldn’t afford to waste time anymore. All our efforts must be geared towards improving the experience of our customers: both consumers and farmers. We are not an IT company building technologies or operating technologies for others. We are an online marketplace selling the produce of farmers to consumers using technologies to support our business.
Considering this, they asked us to prefer SaaS or managed services for everything that is not related to our core business. Let me give you a quick example. We operated Jenkins server farms for years to manage our continuous integration pipelines. While it is important to build our homemade applications, it is not a business differentiator. Our customers don’t care about what continuous integration software we are using. They care about the user experience our online marketplace offers.
We must reduce all the efforts for operating yet vital systems but not business critical. It applies to CI/CD systems, monitoring and alerting systems, etc.
Finally, choose your battle
So, let’s talk now a few about Kubernetes. From what we read on internet and we heard in online conferences, when you chose K8s, it is just the beginning of the journey. Kubernetes is a very flexible platform. You will need to make other choice:
- which service mesh you wanna use? Istio, LinkerD, Consul, etc..
- which monitoring solution you wanna use? Promotheus, Grafana, DataDog, Dynatrac, NewRelic, etc…
- which load balancer you wanna use? Nginx, Traefik, etc…
Selecting the appropriate tools for us in each category would have required some times to evaluate them. It would have also required some skills that we didn’t have in our IT ops teams. It would have required to train people or would have required to hire new contractor employees with the right skills. The learning curve seems quite long and hiring is always a long process even for contractor employees. So being ready to operate applications in production on our own K8s clusters would have take time. Do you remember what I wrote a few lines before? We don’t have time anymore.
So let’s go back to what we really need. We need to deliver quickly new outcomes to our customers. Regarding this requirement, the delivery project has been a success. In a few weeks, we have been able to add a completely new feature to our e-commerce platform using AWS Lambda serverless compute service and Amazon RDS managed relational database service with very low prior knowledge about the platform. Thanks to the Cloud Development Kit, development teams can even define the infrastructure that their applications need as code with their preferred language. So, it is very likely that most of our new projects will go through this path. And from my read of Matt Asay’s article about serverless in InfoWorld on November 8th, it seems that we are not alone on this path.
That’s fine for new projects, but what about existing applications? There’s no doubt for us that using containers to package our existing applications and their dependencies in a secure and reliable way is a must in 2021. But does running containers really means running K8s? Hopefully, no. Cloud providers offer more opinionated services to run your containers. They already made some choices for you and you offload cluster management tasks on them. So you can focus on your applications and just package them into container images. Then you just have to deploy these container images into the service. You don’t have to be an expert of how the service is built.
That’s why we decided to go with AWS Fargate to run our containers and with Amazon ECS to orchestrate them. AWS Fargate is a serverless compute engine that runs your containers so you don’t have to care about server management and update. Amazon ECS is a fully managed container orchestration service. It is an opinionated service so every technical choices have been made for us and we are fine with that because we just want to run our applications.
Some could argue that choosing K8s would have ensured us to be able to move back to our corporate datacenter or onto another cloud provider. It may be a valid argument for larger companies. At our size, moving from our corporate datacenter onto AWS is a kind of one-time-in-a-life event.
Through the years, we already avoided to use some features of products or services we were using in the eventuality we would change providers. It never happened. At the end of the day, we just avoided to be more effective. So, this time, we choose to be more effective and outcomes oriented.
We know that it is probably an unpopular opinion but we wanted to explain why we made this choice and why we are comfortable with it. I hope it could help you to make your own decision.
If you have comments, questions or feedback, feel free to reply to this post and follow us on Medium or Twitter to be notified of next posts.
