Get best of the week

Kubernetes, Microservices, CI / CDs and Dockers for Retrogrades: Learning Tips

It seems that the topic “why do we need Kubernetes” is already annoying. I want to say: “everyone who needs it has long understood”, but I would divide the technical (and near-technical) workers into those who “understood and know how to use”, and those who “understood, but want to know how to make knowledge relevant ".

Perhaps you are a manager who has been working on the same stack for the past 10 years; you may be a developer who supports the old solution or writes in a familiar language in a familiar environment. Perhaps you just switched from technical to organizational management and suddenly found out that everything that you knew was no longer relevant, and I want to understand if there is any relatively simple scenario of how this can be caught up. I will try to give advice based on my own experience - from a person who realized that being in organizational management will soon be expressed by the words “Kubernetes is an effective technology, we must strive for its application”, not fully understanding what lies behind with these words and behind all the technical culture that has developed recently.

Why do I find it important to be able to change the paradigm of technological thinking?

The most difficult thing for those who have been working in technology for a long time is to accept that the new trend has become permanent. Over 20 years of work, I saw how different technologies came and went, and some of them were “super-relevant” for several months.

I read Joel Spolsky about how Microsoft systematically invents a new stack for developers in order to generally prevent them from looking at something else. Like SRE, I was doubly afraid of every new technology: everything new is raw, everything raw is unstable. Well, everything unstable will lead to problems in production, and production stability is the main thing.

As a programmer and an entrepreneur, I wanted to create a product faster - I need to learn everything new, change the usual approaches, which means - roll out features more slowly. If some new technologies were adopted quickly, then everything related to microservice-oriented development (let's call it the whole modern stack) needed to be taught. And every year to learn longer; it’s much easier to write in the old familiar way and deliver the product faster.

But the fact remains: sometimes new technologies remain and change the whole paradigm entirely. And here a choice arises: to remain in the old paradigm or to move into a new one. Cobol-programmers can still get a job, perl-developers remember about booking, but alternative ways for these people are becoming less and less. And then “retrograde” in the name of stability becomes a limitation. With the whole modern stack, if you don’t want to limit yourself, the time is not what has come, but we are already behind. And, if we do not want to get stuck in perl, we need to learn. It takes a long time. I will try to tell my step-by-step experience in learning.

Diving directions


Understand how to run applications in docker. First of all, veterans should understand that the way to “store” and “launch” applications has changed forever. Most likely, a developer who has learned to develop in recent years has no idea how to run an application in production without a docker. In the head of such a developer, there is probably no concept of “store files locally”, except for rare cases of shared storage, but the main thing that a “veteran” needs to understand is: docker is a new exe. The exe format may have its drawbacks, but no one really thinks about it.

Yes, the microservice approach has become the standard. As once OOP appeared to make it easier for large teams to write large software; now microservices have become the same standard. They are even cultivated by the same people (see Fowler) This is reasonable: if the application API is versioned, it is easier for individual teams to write stand-alone applications than one large one. One can argue why small applications should be written microservice, but at some point everyone began to write them in OOP-style - it’s just so familiar (see exe above). There is much to argue that interprocess communication (especially that built on the TCP stack) has a million performance flaws (one service will go to the other over TCP instead of just making an assembler-call - you can imagine what the difference is in productivity?), but the fact remains that microservices have the advantages of developing medium and large projects, and they have also become the standard. Understand how microservices interact with each other (HTTP API, grpc,asynchronous interaction through the queue - a million ways), as a bonus - understand what a service mesh is. (A moment of angry humor: God, guys, they came up with the idea of ​​sharing the application, and it turned out that the communication between the divided applications is a difficult joke, so they added another layer to ease interprocess horror, what is this for us?)

, .So, we reconciled that we are now launching the applications in the docker and that we share the application into microservices. Now we need to somehow manage the running dockers. You can do it yourself on dedicated servers (and steer, for example, Docker Swarm, or build Kubernetes), or you can use the services that clouds provide - container services from AWS or Kubernetes. There is one very big advantage to using clouds. You, in fact, stop thinking about the layer running below the container manager (SRE now laughs, but let's admit - when everything is stable, we don’t climb on GKE nodes in most cases). Thus, in fact, the container manager, whose standard Kubernetes has become, is turning into an operating system. It has package managers, you can “install software” in it, you can run “exe-shniki” in it - dockers,it has kronjoby. Kubernetes is a new OS.

Understand how docker containers will need to be delivered. Layout of a simple site now takes 5 minutes, and people consider this the norm. We need to collect the docker, test it, put it in the registry and put it in the docker manager (let's talk more about Kubernetes). This is the savagery (?) That everyone is used to, it is optimized and this is the standard. CI / CD systems have become the standard layout, and you need to figure them out. Just like with GitOps.

Understand that on-premise hosting for most applications will be a thing of the past (in the West - already gone).Once upon a time, it was the norm to buy servers, assemble them, bring them to DC, put in colocation and switch. Even for a small project. Then came Dedicated servers. How many people are now thinking of tormenting, buying and collecting iron on small and medium-sized projects? Dedicated - in the West now, and in the Russian Federation soon - will be replaced by clouds. This has been talked about for a hundred years, I have been using AWS since 2008, and it has problems, but when we talk about the service that takes over the management of Kubernetes (EKS, GKE, Kubernetes from Yandex or Selectel), I don’t understand why to manage Kubernetes and Dediks themselves, if other guys do it? I don’t change coolers in Dediks anymore ... The question of the prevalence of on-premise Kubernetes distributions in the Russian Federation is a question of the dollar exchange rate,the law on persdans and "youth" of Russian cloud hosting. Sooner or later, this will be decided and on-premise will become the wildness that enterprises and large loaded projects want. With bases the same. If we are talking about most applications that do not require super-high load or super powerful tuning, then cloud-based PostreSQL / MongoDB / MySQL provides a huge number of advantages. No need to think about tuning, no need to think about backups. Create a dev server from a production server - a couple of commands in the cloud console. I understand that this whole idea can cause anger in the admin: guys, I’m the admin myself, but for most non-bad tasks, database management, however, is not needed. Perhaps AWS and GKE are expensive and inaccessible to us because of the Persian law, but this is only additional time to lag: sooner or later, Yandex or Selectel will have the same features,and the paradigm will change.

Understand what infrastructure is now written. I did not like IaaC when he was Chef and Puppet, but, thank God, they were replaced by more adequate Terraform and Pulumi to describe what you want to raise in the cluster, and Ansible to work inside. Go in and put something in the shell - now absolute savagery. Yes, it’s faster and more convenient, but in the new paradigm it’s wildness: remember about exe.

Deep dive course


How do I see a specific technical way in order to understand how to work with a modern stack?

1) Make a trial account on cloud hosting. All hosting providers provide them. I started with GKE, but you can, for example, take an account on Russian hosting services, if you expect that you will work, most likely, in this territory.
If Terraform / Pulumi supports your cloud, describe the infrastructure that you want to create in them. If you have programming skills, I recommend Pulumi: instead of your own Terraform SDL, you can write in familiar languages ​​and constructs.

2) Find the application and pack it in the docker. What is there to pack - the choice is yours. I suddenly discovered for myself how NodeJS became widespread, and decided to take a deep study of its operation, so I continue to work with the node. Here, for example, is a blog on NodeJS , which can be raised, but in general everything is at your discretion.

3) Deal with the basic constructs (for, deployment, service) of K8S and deploy the application with your hands in the K8S cluster.

4) Deal with Helm, write a Helm chart, deploy a Helm application.
Take a free plan on CircleCI as a CI-ke, which does not need to be set, and configure: the configs will be similar to other systems.

5) Fix the application through CI-ku.
Separate CI (what the application builds) and CD. Make a CD by GitOps (see, for example, ArgoCD).

What's next


Somewhere from now on, you, in principle, will be aware of the main bases of the modern stack.
Where can I go digging further?

  • If you are looking for a job / want to work in the West, you can go to a deeper knowledge of cloud computing: submit a Google certificate or equivalent from AWS to Cloud Architect (we recently received 3 of these certificates at ITSumma ). This will give an idea of ​​the features that give Cloud, and help them navigate. Good course on linuxacademy .
  • Hand over to CKA: this is a difficult topic, but worth it. Preparation for the exam will provide a huge package of knowledge.
  • Learn to program if you do not know how. Now I went to study the front and am amazed at how everything has changed. My knowledge ended somewhere in 2012 or even earlier, back in jQuery, people laugh. The front has now become more complicated than the backend, there is a huge amount of application logic and at the same time paradigms that are completely unusual for me. Very interesting!

And I’m a little more regular than the blog here, I keep my telegram channel , subscribe :-)

More articles:


All Articles