In years past, think about how often development teams wanted to be involved in operations deployments – if for no other reason than to get an inside look at the black magic being practiced.
Developers, operations teams, and business users have always been nervous about deployments because maintenance windows had a tendency to expand, causing unwanted downtime. It’s no surprise then that developers have always wanted visibility into deployments. After all, it’s their sweat and pride on the line. Operations teams, in turn, have traditionally guarded their territory so no one would interfere with their ability to get their job done.
But the days of secret back-office deployments are gone (mostly). Why? Because tools like Kubernetes enable seamless deployment and give teams a clear, real-time window into each other’s worlds.
From a business point of view, deployments can and should be frequent, without fear of hitting a point of no return. In the past, software teams sometimes delivered features that were backwards incompatible – if something went wrong during the deployment, there was trouble. Kubernetes solves this problem with deployment rollbacks.
Since Kubernetes ecosystem 1.2, the deployment object is a declarative manifest containing everything that’s being delivered, including the number of instances being deployed and the version of the software image. These items are abstracted and contained within a deployment declaration.
Deployments can also control scaling of the application. You can tell a deployment object to increase or decrease the desired number of instances; the scheduler then modifies the ‘ReplicaSet’ and the ‘ReplicaSet’ asserts the state across the cluster. Scaling of an application can be defined and controlled via the deployment object manually or via horizontal pod autoscaling, based on metrics like CPU usage of the pods declared in the ‘ReplicaSet’.
No Downtime? No Problem.
Teams of ops engineers used to handle deployment efforts manually or via scripting, a live process that could take hours, if not all night. The revolutionary Kubernetes deployment object, on the other hand, has built-in features that automate this operations effort.
With high-traffic applications, there is no need to worry about keeping uptime during a deployment. Deployment objects can define a deployment strategy where
.spec.strategy.type==RollingUpdate is specified in the manifest. By default,
.spec.strategy.rollingUpdate.maxUnavailable is set to 1 so that no more than one of the pods in the ‘ReplicaSet’ is unavailable during the ‘RollingUpdate’. During the switch from one version to another, Kubernetes makes sure at least one instance is available to take requests.
Worried about a surge in traffic during the ‘RollingUpdate’? That’s also not a problem since the deployment object has
.spec.strategy.rollingUpdate.maxSurge – an optional field that provides more than the default pods defined in the replica set.
Real-Time Source of Truth
Another key feature of Kubernetes is that the Kubernetes API provides a real-time source of truth about deployment status(es). With a few keystrokes, any developer with access to the cluster can find out what’s happening with the delivery or see all commands issued. This permanent deployment activity audit log is kept in one place for security and historical purposes. Kubernetes provides this capability via
describe deployment and
Kubernetes also provides an unlimited deployment history (
kubectl rollout history). You can easily learn about previous deployments, roll back to any of the listed versions, or simply see the delta between deployments. No more keeping a folder of old jar files or tarballs and praying the changes aren’t backwards-incompatible.
With a microservices architecture, you can develop applications as a suite of independently deployable, modular services. Your DevOps partner can prepare your apps for a microservices architecture by redesigning your software delivery pipeline so that the primary software artifact is a docker image.
In sum, once your system’s ready to run on Kubernetes, you:
Gain a deployment rollback capability that eliminates large maintenance windows and associated anxiety about downtime deployment. No more software unavailability and issues related to backwards incompatibility.
Eliminate the need for multiple artifact repositories and associated infrastructure. Now all you need is the docker image registry.
Eliminate complex dependencies across systems. Converting systems to a microservices architecture means that development teams can easily run images on their machines.
Enable engineers to focus on mission-driven coding, not on providing desktop support.
Breaking Development/Operations Barriers
Manual and scripted releases used to be extremely stressful. You had one chance to get it right. With the built-in deployment power of Kubernetes, anybody can deploy and check on the delivery status.
Kubernetes’ zero-downtime deployment relieves anxieties about maintenance windows, making deployment delays and downtime a thing of the past – and saving money in the process. It also keeps everyone in the loop while meeting the needs of development, operations, and business teams. No more black magic – and no more passing code from development to operations on a wing and a prayer.