How to become a DevOps engineer in six months or even faster. Part 6. Launching the application

How to become a DevOps engineer in six months or even faster. Part 1. Introduction
How to become a DevOps engineer in six months or even faster. Part 2. Configuration
How to become a DevOps engineer in six months or even faster. Part 3. Versions
How to become a DevOps engineer in six months or even faster. Part 4. Software packaging
How to become a DevOps engineer in six months or even faster. Part 5. Deployment

The photo above shows the speed of traditional application deployment. And if you spent a month on training, now you are at stage 5 of the roadmap:

Ready to launch?

So, we have our code written, packaged and deployed somewhere. I decided to ignore code deployment as immutable machine artifacts (like EC2) and focus on containers. Why?

Because baking an immutable AMI in the source code, copying it everywhere and then running it is very difficult. This is a good template, but only if absolutely necessary. Therefore, I urge you to consider whether you really need to do just that, and if not, then try to reorganize your microservices into containers or serverless functions.

In case containers are not possible, since you decide to write, package and deploy your software as a monolithic application, then consider the immutable AMI template. Do the same if you need to run your own non-cloud applications or commercial software delivered as-is (as is). However, this is not the main topic of this article.

If we have neatly packed containers, how do we launch them?

Truly working containers

The simplest thing you can do is simply run the docker run myImage command and end it. But this is not a good idea, because such a solution does not work if:

  • this container will suddenly “die”;
  • you need to have more than one container to handle the load
  • you need to implement a deployment with zero downtime;
  • You want complete control over your microservices
  • you want to use the CI / CD conveyor to quickly deliver the product to customers

In other words, what happens when you need to create a true distributed enterprise-level application? Obviously, this is such a complex process that the primitive docker run command simply cannot handle it.

Note that docker-compose command technology suffers from a very similar set of problems. Docker-compose, which allows you to run many services with a single command, is not intended for production deployments. Its purpose is local prototyping, rapid functional testing, or very small-scale (for example, personal home) deployments. In short, it is a tool for user workloads that do not generate business revenue.

So, container orchestration hurries to the rescue!

An overview of container orchestration methods

As with everything else in life, there is more than one way to solve the problem. The first and most obvious is Kubernetes. Born from a Google internal project, Kubernetes is the de facto standard for container orchestration.

Also, this is the only option if you run your application in:

  • private data center;
  • Google Cloud
  • Microsoft Azure
  • any other public cloud.

However, if you work in AWS, you have one more option – ECS. Although, strictly speaking, this is not entirely true: you have Nomad from Hashicorp (these are the same people who gave you Terraform) and you have Docker swarm from Docker. The problem is that there are a lot of niche platforms with minimal implementation, so for the sake of rapid career growth, we ignore them.
Anyway, back to AWS Elastic Container Services (ECS). It is a fully managed container orchestration service, quite simple to get started, that is tightly integrated with the rest of the AWS ecosystem. He does just a few things, but he does them well. In short, this is pretty much the opposite of Kubernetes, and if ECS was good enough for McDonald’s, then it’s probably good enough for you too.

However, purely in terms of immediate career advancement, there is no doubt that Kubernetes is the best choice. Although I bet that 99% of enterprises working in AWS will perfectly satisfy ECS as well.

So now you can make a choice. If you are a complete noob in this area, you can temper yourself with Kubernetes, because outside the team of like-minded DevOps engineers who can support you on your journey is no easy task! The image below shows how a future DevOps engineer is exploring an access system based on Kubernetes roles.

However, this is definitely possible, especially with Google and AWS free offers, YouTube / Udemy tutorials, and AWS spot prices. If you chose this route, I recommend that you start with the free Google Cloud Platform Free Tier or kops level, which launches spot AWS instances. Kubernetes (EKS) running on Amazon costs money and, although suitable for prod workloads, is not a good way to start learning how to run applications correctly. And I don’t know enough about Azure to recommend it.
However, if you are not new to this area and really work within the AWS ecosystem, my advice is as follows. Make your microservices containerized and deploy them to ECS to sleep peacefully at night and work in parallel to create a world-class Kubernetes platform. The fact is that immersing yourself in Kubernetes is like “shaving yaks,” which you cannot even imagine, and will inevitably distract you from your true mission – to quickly and efficiently deliver products to customers.

Note: “Yak shaving” is a programming term that means a series of tasks that must be completed before a project can advance to its next milestone. It was coined by Carlin Vieri, inspired by the episode “The Ren & Stimpy Show”. The name of the term hints at the seemingly futility of the tasks performed, even if they may be necessary to solve a larger problem.

Do you really need Kubernetis? No. And if you really want to work with him? Then yes”. Clear? The market says: “either Kubernetes or go home.” So let’s take a quick look at what you are subscribing to by contacting this thing.

First, despite the impression of cutting edge technology, the idea of ​​Kubernetes is relatively old. When Google removed wrappers from Borg (the predecessor of Kubernetes) in 2015, it was already a pretty old idea then.

Read this: “We provide a brief description of the architecture and features of the Borg system, important design decisions, a quantitative analysis of some of its political decisions, and a qualitative analysis of lessons learned from ten years of experience working with it.” Read it again! In 2015 (!), Google shared the details of launching a system similar to Kubernetes, which at that time was over ten years old.

However, they themselves are not shy. Here is the first sentence on the Kubernetes homepage: “Kubernetes (K8s) is an open source system for automating the deployment, scaling, and management of containerized applications. It groups the containers that make up the application into logical blocks for ease of management and discovery. Kubernetes builds on its 15 years of experience with Google’s workloads, combined with the best ideas and practices of the community. ”

So the next time you hear someone presenting Kubernetes as a new “hot” idea, ready to take over the world, just remember that he stands for technology that is now at least fifteen years old. Isn’t that a little innovative?
Secondly, think about the target audience. Google is creating tools to solve Google’s and Google’s problems. Again, the Kubernetes homepage says this quite clearly: “Planetary scale: Developed on the same principles that allow Google to launch billions of containers per week, Kubernetes can scale without increasing your ops team.”

Finally, one of the original Kubernetes developers and his most active supporter, Kelsey Hightower, also highlights this point: “Kubernetes is for people building entire platforms. If you’re a developer creating your own platform (AppEngine, Cloud Foundry or a Heroku clone), Kubernetes is what you need. ”

Thus, if you work on a planetary scale, or launch billions of containers per week, or create a cloud for other users, Kubernetes is the right choice. And if not, then this is not the end of the story. And I don’t care that your grandmother read a bunch of Kelsey tweets during the lunch break and then converted her flower shop website to Kubernetes in a week using CI / CD and Automated Canary Analysis. This is not the right tool for you, unless the nature of your product requires you to use it.

But does it really matter? Kubernetes = $$$. So level up, enjoy your journey into the DevOps world and share your experiences with me.
Translator’s Note: Article # 7 on monitoring applications based on ELK Stack has not yet been published.

To be continued very soon …

A bit of advertising 🙂

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to your friends, cloud VPS for developers from $ 4.99, A unique analogue of entry-level servers that was invented by us for you: The whole truth about VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps from $ 19 or how to divide the server? (options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

Dell R730xd 2 times cheaper at the Equinix Tier IV data center in Amsterdam? Only here 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV from $ 199 in the Netherlands! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – from $ 99! Read about How to Build Infrastructure Bldg. class c using Dell R730xd E5-2650 v4 servers costing 9,000 euros for a penny?

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *