Jump right into Kubernetes development with career-focused lessons and hands-on practice.

DevOps for Developers

Kubernetes is a powerful container management tool that's taking the world by storm. This detailed course will help you master it.

In this course, you'll start with the fundamentals of Kubernetes and what the main components of a cluster look like. You'll then learn how to use those components to build, test, deploy, and upgrade applications, as well as how to achieve state persistence once your application is deployed. You'll also learn how to secure your deployments and manage resources, which are crucial DevOps skills.

By the time you're done, you'll have a firm grasp on what Kubernetes is, as well as the skills to deploy your own clusters and applications with confidence.

A Practical Guide to Kubernetes

# The beginning
In the beginning, there were no package managers, because there were no other package formats (like JAR, WAR, RPM, and DEB). **Package managers** maintain a database of software dependencies and version information to prevent software mismatches and missing prerequisites.  The best we could do at that time was to zip files that formed a release by manually copying files from one place to another. When this practice was combined with bare-metal servers, which were intended to last forever, the result was disastrous. After some time, no one knew what had been installed on the servers. Constant overwrites, reconfigurations, package installations, and mutable types of actions resulted in unstable, unreliable, and undocumented software running on top of countless OS patches.

# Configuration management tools
The emergence of configuration management tools (e.g., CFEngine, Chef, and Puppet) helped to decrease the mess. They improved OS setups and maintenance more than deployments of new releases. They were never designed to do that, even though the companies behind them quickly realized that it would be financially beneficial to extend their scope.

Even with configuration management tools, the problems with having multiple services running on the same server persisted. Different services might have different needs, and sometimes those needs clashed. One might need JDK6 and the other JDK7. A new release of the first one might require JDK to be upgraded to a new version, but that might affect some other services on the same server. Conflicts and operational complexity were so common that many companies would choose to standardize. As we discussed, standardization (with clear isolation) is an innovation killer. The more we standardize, the less room there is for coming up with better solutions. Even if that's not a problem, standardization with clear isolation means that it is very complicated to upgrade something. Effects could be unforeseen and the sheer work involved in upgrading everything at once is so significant that many choose not to upgrade for a long time, if ever. 

Learn about the history of deployment processes.

A Short History of Deployment Processes

The beginning