At IBM, the IBM Cloud Container Service is updated an average of 40 times per day. This may seem like a shockingly high number of updates, but there is good reason. Built on top of microservices and deployed globally on the IBM Cloud, we want to provide our users with a continuous drumbeat of new features and capabilities, high performance, and the most updated security possible against emerging cyberthreats.
What does updating a container service 40 times per day entail? It means iterating and deploying additional features, rolling out our service in new locations, updating for security in response to the latest operating system patches, improving Kubernetes and the container engine at the core of our service, and fixing any performance or availability issues. It also means constantly adding maintenance features and expanding the service in response to market and technology demands.
While this number of daily updates may seem daunting, it is achieved through the tried-and-true complement to any cloud-native, container, or microservices strategy: devops.
Incorporating devops into our culture and development practices has helped us overcome one of the largest hurdles teams face today: security. As moving to cloud-native enables apps to be built and updated at a breakneck pace, it’s critical that security be baked in and continuously updated at this same rate—no matter how many times an app’s features or components may change.
of sorts. More moving parts often means a greater risk of letting cracks open. However, when implemented correctly, the opposite is true.
Continuously updating container-based software with devops can create heightened security. This is because cloud environments, such as managed container platforms, are constantly kept up to date and moved to the latest patch levels, which are rolled out globally via the cloud. This has helped us stay on top of the latest threats and address them immediately. In turn, this makes the entire environment more secure, as a major source of insecurity within apps is outdated software.
Practicing devops while enabling it
The rise of containers has been a huge enabler for devops, because you need continuous delivery for container architectures to be both secure and effective. To get continuous delivery to work, you need repeatable software deployment. You also need to deploy to an environment that can tolerate changes (including rolling updates and rollbacks).
can be used to control updates for each individual cluster.
This enables control, at a granular level, for who’s running what and where updates are flowing around the world, simply by changing configuration in LaunchDarkly. The systems respond to that instead of needing complex coordination logic to identify where to push updates.
A piece of advice
If you’re thinking about implementing a continuous delivery approach or even bringing cloud services such as containers, microservices, and devops into your software development practice, it can seem like a daunting task. While improvements and returns will be immediately seen, it takes time to build the mature processes that help organizations truly realize the value in these technologies and processes.
If you’re beginning your journey, my advice is simple: stop worrying about the theory and focus on the practice. Devops with containers is a proven path—don’t separate them. Most teams will want to come up with separate strategies for both containers and implementing devops. They should come as a package deal.
So, pick a project and do them together. Many technologists learn best by doing, while some of us learn best by doing and failing. Luckily, this approach allows you to fail fast and innovate faster.
This article is published as part of the IDG Contributor Network.