Kubernetes, Microservices, CI/CD and Docker: Learning Tips for Old School People

It seems some people are fed up with the topic of why we need Kubernetes. You might say that everyone who needs it has long understood the importance of Kubernetes, but I would divide IT specialists, IT managers, etc. into two categories: those who understand Kubernetes and know how to use it, and those who understand its importance but wonder how to fill in the gaps in their knowledge.

Perhaps you are a manager who has been working with the same technology stack for the past 10 years; or you are a developer who supports an old product or writes in the same old language in the same old environment.

Maybe you just switched from technical to organizational management and suddenly found out that your skills are no longer relevant, and you want to find a relatively simple learning scenario to catch up.

Having worked in organizational management, I know that it can be difficult to keep up with trends in IT culture, and one might start saying “Kubernetes is effective, and we must implement it” like an incantation, not quite understanding what it means. That’s why I will try my best to give you advice based on my own experience.

Why do I think it’s important to be able to change the paradigm of technological thinking?

The most difficult thing for those who have been working in IT for a long time is to accept that some new trends are there to stay. Over 20 years of working in IT, I’ve seen how various technologies appeared and disappeared, and some of them were “super relevant” only for a few months.

Joel Spolsky wrote that Microsoft systematically creates new stacks for developers in order to prevent them from considering other technologies. As an SRE, I was doubly suspicious of each new technology, since everything new is raw, and everything raw is unstable. All unstable things lead to problems in production, and production stability is the most important thing.

As a programmer and entrepreneur, I wanted to develop my product faster. However, since I had to learn all those new technologies and change my usual approach to development, it took me longer to roll out new features. While some new technologies were easy to apply, others related to microservice-oriented development (that's how I'll be referring to the whole current stack) required more thorough examination. Every year you have to spend more and more time studying, so it’s much easier to write programs in the good old way and deliver your product faster.

But the fact remains that sometimes new technologies stay and completely change the whole paradigm. In this case, you either remain true to the old paradigm or move on to the new one. COBOL programmers can still get a job, Perl developers can expect to work for booking.com, but there are fewer and fewer job opportunities for them. Eventually, commitment to the old ways in the name of stability becomes a hindrance. If you don’t want to limit your options, then hurry and start researching the current technology stack ASAP in order not to lag behind even more. If you don’t want to get stuck in the past with Perl, you need to learn new things. Yes, it takes a lot of time, but I think I can help you by sharing my learning experience, step by step.

Things to research, understand and accept

First, you need to understand how to run applications in Docker containers. Old school people should understand that the way to store and run applications has changed forever. A new developer most likely has no idea how to run an application in production without Docker. They probably don't even think of storing files locally, except in rare cases with shared storage. However, IT veterans need to concede that the Docker container is the new EXE. Although EXE was just one of the executable file types and it has its drawbacks, it was the only way to run an application — just like Docker containers now.

Yes, the microservice architecture has also become the standard, like object-oriented programming in its time. OOP was created in order to make it easier for large teams to develop large software projects; now microservices serve the same purpose. The same people are behind both of these projects too (see Fowler). This is reasonable: if the API is versioned, it is easier for self-contained teams to write small independent applications than a large monolithic one. It is worth arguing whether we need to use microservices for small projects too, but at some point everyone started writing them in OOP style, just because it’s so familiar (see about EXE above). Of course, interprocess communication (especially if it uses the TCP stack) has some disadvantages in terms of performance (one application connects to another via TCP instead of just calling a function which would accomplish the same goal — can you imagine the difference in throughput performance?), but the fact remains that microservices allow us to develop medium and large projects faster and, moreover, they have become the standard. You also have to understand how microservices interact with each other (HTTP API, grpc, asynchronous communication with queues, etc.).

Optionally, you can also learn more about service mesh. (First they start dividing applications, then they realize that service-to-service communication is so darn complicated! So they add an extra layer in order to fix that mess. Why, just why?)

Understand how to manage a stack of microservices running in Docker containers. So, we have resigned ourselves to running applications in Docker containers and breaking up an application into microservices. Now we need to somehow manage our running Docker containers. You can do it yourself on dedicated servers (for example, with Docker Swarm, or you can set up Kubernetes), or you can use cloud provider services, for example, by AWS.

There is one very big advantage to using cloud environments: you don’t have to think about the layer below your container manager.

(SREs are probably laughing right now, but we all know that we do not tinker with GKE nodes when things are stable.) In fact, as we see in the example of Kubernetes, container managers turn into operating systems.

Kubernetes, which has become the standard container manager, has package managers and CronJobs. You can install software on Kubernetes clusters and run Docker containers (sort of like EXE files). Kubernetes is pretty much a new OS.

Understand how to deliver Docker containers. Now deploying a simple website takes 5 minutes, and people consider this the norm. You need to build a Docker image, test it, and push it to your registry and your container manager (we’ll use Kubernetes as an example). Everyone is used to this process, it can be optimized, and it is the standard. You'll also need to understand CI/CD and GitOps.

Understand that on-premises hosting for most applications is already a thing of the past. Some time ago, it was OK to buy and assemble servers, bring them to a data center and get them collocated, racked, stacked and connected in a network. Then dedicated servers became popular. Since then, it is unlikely that someone will want to actually buy and assemble hardware for small and medium projects.

I have been using AWS since 2008 and, of course, it has its problems. But I don't see why we need to manage Kubernetes and dedicated servers ourselves if someone else can do it for us. (I mean services such as EKS, GKE, etc.) This is also true for databases.

For most applications that are not designed for very high loads or require extensive performance tuning, cloud-based PostgreSQL/MongoDB/MySQL is much better: you don't have to think about tuning or backups.

You can create a dedicated server from a production server using just a couple of commands in a cloud console. Admins, you might feel less than excited about it, but, being an admin myself, I learned from experience that database management is mostly required only for high-load projects. Perhaps AWS and GKE services are expensive or even inaccessible for some of us due to legal restrictions, but sooner or later, other similar services will provide the same capabilities, and the paradigm will change.

Understand that Infrastructure as Code is a thing now. I didn’t like IaC when it was represented by Chef and Puppet. Fortunately, they were replaced by the more suitable Terraform and Pulumi for describing what you want to set up in a cluster and Ansible for working with your infrastructure. Using the shell is faster and more convenient, but it does not fit into the new paradigm.

Steps to learn the modern stack

I think I see a suitable specific technical way to figure out how to work with the modern stack.

1. Create a trial account on any cloud hosting platform. I started with GKE, but you may prefer an account provided by another hosting service. If Terraform/Pulumi support your cloud provider, use them to describe the infrastructure that you want to create. If you have programming skills, I recommend Pulumi: in this case you can use familiar languages and constructions instead of Terraform’s configuration language.

2. Put an application into a Docker container. What application you choose is up to you. For example, I suddenly discovered that NodeJS is very common now and decided to research its uses, so I work with it. Here is a NodeJS blog that you can set up.

3. Understand the basic constructs (pod, deployment, service) of Kubernetes (K8S) and manually deploy your application to your K8S cluster.

4. Understand what Helm is and how to use it, create a Helm chart and deploy your application using Helm. Get the free plan on CircleCI as a Cl/СD tool which you do not need to install. As for configurations, they are similar to the ones in other systems.

5. Deploy your application using Cl. Separate CI (which builds applications) from CD. Handle the CD part with GitOps (e.g., ArgoCD).

What’s next?

After going through these steps, you will know the basics of the modern stack.
But how else can you pump up your skills?

If you are looking for a job in Europe or North America or want to work there in the future, you can deepen your knowledge of cloud environments by passing the Google Cloud Architect Certification exam or its equivalent from AWS. (Our team recently got three such certificates.) As you prepare for certification, you gain a better understanding of cloud features. You can try this training course at linuxacademy.

Pass the CKA exam, which is tough but worth it. Preparing for this exam will help you to learn a ton about Kubernetes administration.

Learn to program. Personally, I’m learning frontend development. I was surprised how much it has changed since 2012, as I only got to JQuery. (Ridiculous by today's standards.) Frontend has become more complicated than backend. The former includes a lot of application logic plus paradigms that are completely unusual for me. It’s very interesting!