Introduction
There has been a large number of posts recently about Kubernetes and a particular one from the team at Stackoverflow actually advocates about building on kubernetes from day one.
Their post is very well-written down and provides good arguments on why it can pay off to keep it top of the mind when building things. I will offer my perspective on this as a developer in a company that is adopting kubernetes and as a maintainer of a personal side project where I use kubernetes to manage my backend code deployments.
Are you ready for Kubernetes?
Most projects I've worked with, both professionally and personally, in the last 5 years, have all leveraged Docker in some shape or form: Some used it for actual deployments in very manual, simple ways: think _rsync_ing files into a container after a compile step and then starting it up. Others used it for several stages of the SDLC from testing all the way to production, and, others yet, simply used it as a way to "package your code to make it ready to run somewhere else the world can see" - yes, this last piece is my side project :)
If you are using Docker, and, equally important, if you are structuring your workflows and code organization around your usage of Docker, for e.g, by building modular code in a microservices style, or using Docker to run pipelines with integration tests that give you quality assurance, or simply, if you are keeping your code dockerized and storing the images in a container registry, then, you are most likely ready for Kubernetes.
Leveraging your readiness
Okay, cool, so you're already using Docker, you know a bit about Kubernetes, what it promises to do and how many companies are shifting towards adopting it. Time to leverage your readiness and really jump into it. But how?
Well, as defined in the stackoverflow post above, the rise of managed Kubernetes services, like Google Kubernetes Engine, EKS, etc, make it easier than ever to actually have a cluster ready to be used. Or do they?
In my personal experience, these services are really invaluable in allowing me as a developer, whether I'm working on my own side project, or my company, to experience Kubernetes usage from a practical perspective, i.e the perspective of a developer who wants to simply deploy code into a cluster and make it run there. But, there are a lot of nitty-gritty details that still need to be resolved whether with the help of platform teams or devOps folks or simply tight collaboration with your senior colleagues. Some examples of things (technical and non-technical) that can be really tricky and need handling:
permissions in AWS to manage/create, deploy to, or configure an EKS cluster. These are hard to hand out and create, and hard to get right from the get go. There has to be a designated person as the ´cluster owner´ that can facilitate such tasks;
configuring things like Ingresses, Load Balancers and memory and CPU usage limits. Yes, these things can be used out-of-the-box in these managed services, but, to really adapt them to your own needs, like, for your company's proxy rules, several docker images, metrics collection, etc, are the hard things nobody talks about it, and these take time and effort;
manage your databases properly and keep your database out of the cluster and out of containers. Databases should be managed separately as they are of a different nature than that of your application code. It's not a pick all, mix all kind of approach. This requires some infra work to get right though!
bring people into it. Yep, these days it's surprisingly tricky to navigate an environment with the idea to convince people to "join you". You need to do real devRel advocate work inside your own team (first), and collaborating teams (after) if you want the adoption to succeed. It needs to really be a team effort;
How to empower people to try it out
Part of the success when leveraging the readiness to go into Kubernetes is in ensuring that everyone is on the same page. For this, there are several online workshops from many different cloud vendors that can ensure that everyone in your team is looking at the same concepts with a very similar level of exposure. This, in turn, will bring more confidence to everyone in the team to try these things out and see what the hype is all about!
You can even push the envelope when suitable and, well, remember that cool side project where you used Kubernetes on your own for the first time? Maybe talk about it at your work! You may be surprised by the positive reception and feedback that these initiatives can have. Sometimes, a nudge in the right direction is all it takes!
You, as an individual
For you as an IC, the best way to really learn, is to commit to a simpler managed Kubernetes service (eg. DigitalOcean) and just...build something! A small project for you to get exposure to some of the basic things that are available to you, while, at the same time being exposed to some "real world" complexity that comes with you having to manage the pods, namespaces, ingresses, etc, all on your own. It's exactly what strikes the right balance between complexity and learning, in my opinion. From there you can keep building more knowledge, contribute to real things inside your work and keep ramping up!
Conclusion
Hopefully, after reading this post you will feel more ready to start looking into bringing Kubernetes into your organization or to simply start using it yourself! It's an exciting time to be on top of the wave of Kubernetes and it's not THAT hard to at least make a jumpstart for its adoption and to see the benefits! Keep sailing!!
Top comments (0)