1. Little Money, Lots of Work, and Everyone Pushes You Around
The operations department is a cost center. There is a phrase for it: cost optimization. When a CXO sees how low machine utilization is, they think about cutting machines β spend as little as possible β and that means more work for operations. Optimizing cost is one of the responsibilities of operations.
Operations is a service team for R&D. Being unable to generate revenue means having no say, and you can imagine the standing operations has in a company. More often than not, R&D files requirements and operations fulfills them, with little room for negotiation.
A telling sign is that there are far more companies outsourcing operations than outsourcing R&D. This is easy to understand: operations is usually a long-tail project β once the initial setup is done, there are not many ongoing requirements. But as long as a business system has users, R&D has to keep iterating on the system to support the company’s revenue business.
Also, R&D is finely divided β Web R&D, App R&D, Golang R&D β and you cannot just hire any developer and expect them to be productive quickly. Operations is different: a Shell script can basically solve the problem, and knowing Python makes you quite good indeed.
2. Virtual Containers Rise from the Ground
The low resource utilization, high operations cost, and difficult disaster recovery and backup of physical-machine-based IT infrastructure accelerated the development of virtualization technology and container technology.
Virtualization appeared very early, used in the 1980s to solve the problem of time-sharing on mainframes. Technologies like chroot, cgroup, and lxc gradually emerged. Actually, virtualization comes in full virtualization and paravirtualization. Paravirtualization is more efficient but requires modifying the guest OS kernel. Many IaaS cloud vendors today use the full-virtualization QEMU-KVM stack.
IT infrastructure built on virtual machines freed operations staff from the physical data center β no need to spend much time on hardware. The scope shrank, and operations quality went up.
But that was not the end of it. There was still the need to deal with differences among CentOS, Ubuntu, Red Hat, and various other systems, and even then a virtual machine could not run many applications. Whereas a virtual machine has its own complete kernel, a container is just a set of processes running on the host, using technologies like lxc to achieve isolation from the system. It looks like a good technology, but not many people used it, because the thing is hard to understand.
With the arrival of Docker in 2013, that situation changed. Docker’s greatest contribution was defining the container image specification and popularizing container technology. Today when people mention containers, they easily think of Docker, but there are also containerd, cri-o, and isula β all of which follow the OCI specification. Docker’s slogan is “Build once, Run anywhere, Configure once, Run anything.” That is right: Docker hides away the differences of the underlying layer, a bit like the JVM, providing a middle layer.
The popularization of Docker meant that spring was not far off for operations. Virtualization technology freed operations from worrying about hardware; Docker freed operations from worrying about applications. Operations only needs to carry out its work on top of Docker β collecting monitoring metrics and logs, configuring alerts, and so on.
3. Agile Development Is Indispensable
Agile development grew out of Extreme Programming and is a very important methodology. DevOps has been generalized to the point where a thousand people may have a thousand different interpretations; it can be understood as an IT cultural movement. For more on agile development, see another document, The R&D Process of Agile Development.
DevOps formally appeared in 2009. It developed gradually thereafter, and more than a decade later it is still very much in the spotlight.
The emergence of a technology may be quite accidental, but the development of a technology requires market cultivation. In the earliest days of software application development, you needed a deep understanding of computers, the relevant tools were lacking, complexity could not be brought down, and development cycles had to be measured in months or years. Things are different now: internet companies release several times a week, and each release covers no small number of applications.
This shift on the demand side drove the evolution and development of technology and culture, and all of it rests on container technology. Container technology provides isolation, elasticity, and the ability to be created and destroyed at any time. Compared with the hard-to-understand behavior of the Linux system, Docker’s related concepts are far simpler β easy to use and easy to learn, and the ship is big too. This is simply a godsend for engineers.
To make management and monitoring easier, we usually adopt a one-application-one-container model. But under a microservices architecture, hundreds of applications mean hundreds of containers. Managing those containers β controlling their startup order, where they run, how many replicas there are β poses enormous challenges. For this reason, container orchestration became a very strong need.
After the container orchestration wars, Kubernetes became the de facto cloud native infrastructure, a distributed operating system for applications. Subsequently, related technologies sprang up like bamboo shoots after rain: Istio for microservice governance, Tekton for orchestrating tasks, Knative for providing serverless, and so on.
Once one flower blooms, a hundred flowers bloom. With Docker clearing the way ahead, we entered an era of all-around, large-scale development of IT infrastructure.
4. Perched on a Branch, Chirping Away
Having said all this, it seems we have not talked much about cloud native. A technology in a phase of rapid development is always a bit hard to pin down conceptually. According to the CNCF definition, a cloud native application is one built using technologies such as containers, service meshes, microservices, immutable infrastructure, and declarative APIs. Put simply: use the projects within the CNCF.
I have never seen an industry love sharing as much as the IT industry does, especially one led by operations people who once had little standing and that nobody wanted to do. Every year CNCF holds the cloud native technology summit, KubeCon.
Many of the topics revolve around Kubernetes. Kubernetes, as the infrastructure, replaces OS\VM, which means all the previous foundational applications need to be migrated onto Kubernetes. Beyond that, using Kubernetes itself also gives rise to new scenarios.
Only by walking on cement that has not yet set will you leave footprints that last forever. The ecosystem around Kubernetes is exactly such a road surface. And all you may need to do is write an operator, connecting it to the domain you are good at.
