Why Go Became the Standard for DevOps Engineers

Sometimes things find their use unexpectedly and not in what they were intended for.

In the 1960s, Ken Thompson, a programming legend, wrote the Space Travel computer game for the Multics operating system. The system was a Bell Lab project where he worked with Denis Ritchie. The project was later closed, and in order to continue playing his Space Travel, Thompson decided to port it to the PDP-7 computer. The tools he created for the port then formed the basis of the Unix operating system.

Thompson wrote the first three versions alone. Unix needed a system language – that’s how B appeared. Later, Denis Ritchie, a colleague and friend of Thompson’s, picked up the development and wrote the C language. This is how almost everything that modern technologies are based on was the desire to play a computer game and pet projects for fun.

Ken Thompson has built a brilliant career as a computer science researcher. In the mid-2000s, he got a job at Google, where, together with Rob Pike and Robert Graismer, he created Golang – one of the most popular languages ​​of recent times.

---

Go was invented as a simple language for everything

By that time, Google was already growing into a giant corporation, problems began with the speed of development. There was a lot of C ++ code, and it was getting harder to maintain. The task that the company set itself seemed almost naive – to invent a very simple language in which it would be possible to do very complex things.

We all agreed that we hate C ++, and decided that not a single feature gets into the language until each of us three is convinced of its necessity – and then the language will not become overgrown with unnecessary garbage that has appeared for some unknown reason.

Ken Thompson

The creators wanted to solve the problems of slow build programs, uncontrolled dependencies, complex tool development, and cross-language problems. They took C, Pascal and Oberton as the basis of the language and tried to collect the best out of them. As a result, they began to make a language with very simple syntax, strong static typing, automatic garbage collection, and simple tools for managing multithreading.

Golang was announced in 2009 and released in 2012. The language quickly began to gain popularity, but it also faced criticism. The key feature of the language – simplicity – was considered by many developers to be the main disadvantage.

“Due to the desire for simplicity, Go lacks constructs that are perceived as something natural in other languages. It may seem like a good idea at first, but in practice, verbose code comes out, ”wrote Gary Willoughby. – Go was designed to be simple, and it succeeds in that goal. It was written for weak programmers, using the old language as a template. It comes complete with simple tools for doing simple things. It’s easy to read and easy to use. It is extremely verbose, lackluster and bad for smart programmers. “

But such criticism was not really a criticism for the creators of the language. Rob Pike himself described the language in almost the same way, but unlike critics, he did not speak of inexpressiveness as something bad:

The key point here is that Google isn’t a researcher. They are usually young, go to work after graduation, where they may have studied Java, or C / C ++, or Python. They will not be able to immediately understand the fancy language, but at the same time, we want them to create good software. That is why the language must be easy to understand and learn.

However, as early as 2012, many developers saw the promise of Go in areas for which it was not originally conceived. In his twitter Derek Collison wrote:

* Forecast: Over the next two years, Go will become the dominant language for IaaS, PaaS, and orchestration.

This is exactly what happened – almost at the same time when the language was being created, the DevOps culture began to develop rapidly in IT, in which Go almost immediately became the standard.

---

DevOps was invented as agile for infrastructures

For many years, a strict hierarchy reigned in the software development cycle – programmers wrote code, system administrators made sure that what was written worked fine on hardware – everyone was responsible only for their own area. When bugs surfaced somewhere, a battle of professions began. The programmers argued that the problem was somewhere on the servers and that it was not their business; the administrators assured that everything was fine with the servers, they just put a crooked code on them.

Sooner or later, the error was eliminated (or not), and everything started anew.

But everything changed very quickly in the industry, it grew at a terrible pace. The delivery time of features to users was reduced, the number of constant updates increased, the very uncertainty of product development became more obvious – some things were literally collected and refined on the fly with regular updates.

Under these conditions, divisional disunity began to hurt a lot, and even agile — a manifesto of uncertainty and flexibility — that had been around for almost a decade — didn’t help much.

In 2008, database administrator Patrick Debois went to the Agile Toronto conference, where he met another admin, Andrew Clay Schafer. Both were interested in agile and how to better implement it in the sysadmin business. At the same conference, they saw a speech where one of the speakers talked about how developers and admins in his team are trying to work together.

From all these discussions, Debois and Schafer came up with the idea of ​​holding a separate conference dedicated only to these issues.

At that time, the term Devops did not exist yet – there was only an idea. I tweeted that it would be great to have a conference in Europe and discuss the idea itself. Agile System Administrators is not a name for the event, so I was asked to name it DevOpsDays – and this is how the Devops movement began.

A year later, the conference was held in Belgium. Literally, the name immediately became the name of a new approach to work, which over the years turned the idea of ​​the roles of developers and administrators in IT.

The bottom line was that developers participate in the deployment, administrators write scripts, everything is automated. From this began not only a shift in philosophy and attitude towards roles in the team, but also software changes. New practice required new tools. Docker, Kubernetes, Terraform and other things that are now closely associated with the work of a devops engineer – appeared on this wave. And almost all of them were written in Go.

---

Why Go and DevOps were perfect for each other

When Google started developing Kubernetes, the team already had a huge legacy of containerization tools. But Coober started writing from scratch, so the question arose of choosing a language. Joe Beda, the main developer of the service, said that Google uses many languages ​​- not only their own development – and they chose between C / C ++, Java and Python.

C was not accepted because it is a rather “frightening” language for many developers, which has acquired a colossal huge infrastructure. It is becoming more and more difficult for the community to agree on what, where and how to use it correctly.

Java didn’t work because the developers wanted to make installation easy on as many platforms as possible. Python was dropped due to dynamic typing.

But Go, according to Beda, was “not too high-level, and not too low-level.” The list of reasons why the Kubernetes team chose it is quite wide:

• All libraries are out of the box for almost everything they need.

• Fast tools. “With them we got hooked on the speed of development,” writes Bede.

• There is no complex code in Go. “Nobody writes factories of factories on it. It is quite possible to understand any part of the system just by looking at it. “

• Anonymous functions.

• Garbage collection you don’t need to think about.

• Strong typing.

But these are pluses for tool development. When ordinary devops engineers talk about why Go has become the standard in their field, they are most often called

Three main reasons

• It’s really very easy to learn and read. Many developers and devops say that it is enough to read the general documentation to go and use the code in production without any problems.

• It has the easiest multithreading to use. Goroutines and Channels are features that are praised even by those who don’t like Go.

• It’s incredibly easy to operate. And this is perhaps the main reason why the language is so good for infrastructure engineers.

“Compared to Python, Ruby or Node.js, installing a single executable is a field engineer’s dream. Of course, this is not such a big problem with the increasing use of Docker, but individual executables also reduce the size of containers, ”writes Sylvian Vallez.

The source code is compiled into a binary file. Because of this, when deploying an application, you do not need to install the necessary dependencies in advance, you can simply transfer and run it anywhere.

What do you think about Go? How and why do you use it? Visit our community – there we constantly analyze various problems and tasks from the field of Devops, discuss things that will be useful both in interviews and in work.