Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Getting to zero downtime: How containers drive continuous operations

public://pictures/davidl.jpg
David Linthicum Chief Cloud Strategy Officer, Deloitte Consulting
Containers can help drive zero downtime goals in continuous operations, but having the right skills, tools, and processes is key. Here's what you need.
 

When a new technology comes along, those who operate continuous operations systems may have little understanding of the value it can bring or how it should be managed and maintained. The use of containers is a prime example.

The place to start is with a full understanding of the value containers offer and how the technology affects continuous operations, also known as zero downtime operations. You need to understand what emerging special skills, tools, and processes you'll need. Organizations that pursue the use of containers in continuous operations may face challenges with existing platforms and tools, lack of skills, and cultural resistance. In some instances, continuous operations may even be the wrong choice, depending on the amount of change that needs to occur and the willingness of the organization to change.

When you need continuous operations

The research firm Gartner defines continuous operations as "those characteristics of a data processing system that reduce or eliminate the need for planned downtime, such as scheduled maintenance." It is, Gartner says, "One element of 24-hour-a-day, seven-day-a-week operation." The idea behind continuous operations is that operations never stop. You put hardware and software solutions in place to eliminate planned maintenance, and applications will continue to service customers until they're switched over to newer versions once you've deployed and tested the new applications.

If you think this requires new approaches to platforms, you're correct. Organizations that want to pursue continuous operations should expect to invest in many dual, redundant platforms. While the use of public cloud providers is a clear cost advantage in provisioning servers to support continuous operations, you'll still pay for more resources than if you deployed on a single platform during a scheduled period of maintenance.

That said, the value of continuous operations can be largely determined by the cost of downtime. If core systems are unavailable for a certain period of time, either planned or unplanned, that downtime can cost the company as much as $1 million per hour, depending on the business. What's more, as more companies move to 24-hour global operations, the cost will shift upward, making it easier to cost-justify continuous operations.

Consider, for example, a tire manufacturer that has been in business since the 1960s and traditionally operated from 8 a.m. to 6 p.m., five days per week. That availability schedule allows plenty of time for planned outages. But now the company needs 24/7 systems to support online sales, for access to retail story inventory and to support mobile applications that monitor the status of tires on cars. A company with these demands is a candidate for migration to continuous operations, as having no downtime has a clear business benefit.

Where containers fit

The architecture of containers offers a direct benefit in continuous operations because the technology gives you a standardized way to divide applications into separate containers. In this way, applications can be isolated within a platform into what is, in essence, a sub-platform. By breaking applications up into containers, you have the ability to place them on different physical and virtual machines, in the cloud or on premises. This flexibility is great for workload management and lets you more easily build fault-tolerant systems.

This ability to use containers to easily create and manage fault-tolerant systems means you can also create container-based isolated systems for testing, deployment, and production environments. Thus, you're able to operate the systems and applications, including new and previous versions, on different systems within a container or, more likely, within clustered containers. At any time, you can redirect users to the newer version of the application, data, or even the platform, and you can do this in a way that's completely transparent to the user.

Some organizations are already using containers to support continuous operations. Google has been exploiting container technology as the core architecture for its operational systems for years. As a result, Google can support an operational level that approaches zero downtime. Any business can now exploit the same technology.

By separating concerns around things such as developers from machine instances, applications from operating systems, and even data from applications, you can manage containers using cluster management systems that let you schedule and scale containers.

Since containers provide isolation, you're also able to delegate work to different operational teams. One team might focus on the kernel and machine maintenance, another on cluster operations, another on data, and still another on applications. The ability to isolate these architectural components means that the teams will be more productive, and you won't need to coordinate work taking place with other groups. This ability to focus means your team will make fewer mistakes within the continuous operations processes. Even when you do make mistakes, it's unlikely that they'll affect your other architectural components because they're also isolated, and you'll be performing testing on non-production systems.

Moreover, when leveraging container cluster management systems such as Kubernetes or Swarm, you can monitor the health of a cluster of containers, rather than every application. Again, those who specialize in operating cluster managers will deploy and maintain these containers.

Cluster management systems also provide an abstraction layer that lets you manage containers and clusters of containers without dealing with individual machines. That makes the use of containers even more valuable. Here you're dealing with management APIs provided by cluster managers, rather than the complexities of the underlying hardware, whether in the cloud or on premises.

Best practices

Best practices in continuous operations are just beginning to emerge, and combining continuous operations with containers is a new and evolving science. If you're doing continuous operations using containers, you're on the leading edge and part of a very small group.

That said, interest in DevOps and the exploding value of continuous operations is driving a great deal of interest in using containers, not only for its application portability advantages but also for its operational advantages. If they're not using them already, enterprises that are moving new applications into a DevOps process or refactoring existing applications for a DevOps process clearly have containers on the radar.

One core best practice of continuous operations is to focus on the architecture of the containerized application to determine how it can be effectively put into continuous production. Zero downtime doesn't happen automatically when you move applications into continuous operations. Developers and application architects must think about how applications should be structured within containers and how those containers should be managed as clusters. Isolation and loose coupling are keys to the continuous operations kingdom, and your applications must support those concepts.

Another best practice is to make continuous operations an automated and seamless part of your DevOps processes. As you move from continuous development, integration, testing, deployment, and operations, you'll need highly automated processes that can manage the movement of code from development to operations. Without highly repeatable and automated operations, you're not going to see value from your DevOps investment.

The largest stumbling block that enterprises encounter on the move to DevOps and continuous operations are the manual operations that must occur as part of the processes. While the idea is that developers can kick off automated processes to test, deploy, and place their code into production, the majority of those moving toward DevOps still count on manual processes to fill in gaps they've not yet filled with automated tools.

The key to continuous operations is automated everything, with everything repeatable. Thus, everything that goes into production remains consistent.

The need for consistency drives teams further toward containers, because they can isolate applications and keep them consistent in terms of management of operations. This structure removes the complexities of the applications and data that exist inside the container and lets you manage them using a consistent interface at the container and cluster levels.

Skills and culture are also big issues. Make sure that your culture is ready for continuous operations and ready for DevOps in general. Those who are deeply rooted in traditional operations approaches will have the toughest time changing. In fact, in many cases, they won't be able to change effectively.

Having the right skills is yet another requirement. Your team needs to have some experience with containers, as well as new approaches to application architecture and the use of cluster managers. Again, those who are deeply rooted in traditional approaches may be less willing to learn and change. The people aspect of all of this is, by far, the toughest problem to solve.

Finally, use container clustering to keep containers running and to seamlessly update applications encapsulated inside of containers without having to shut down production systems. Cloud providers such as Google are getting better at this process, and in the world of public cloud computing, zero downtime is an expectation that is no longer negotiable.

It's not that containers are a requirement for continuous operations; you can certainly move to continuous operations without using containers. But containers bring a set of capabilities that promote the use of continuous operations.

The big picture

In your move to continuous operations, make sure to first define the entire DevOps processes, as well as automation. Keep in mind that the value of continuous operations will be a direct result of the overall value of DevOps. A change-oriented culture and the ability to define effective processes and the required skills to support DevOps will give you the best chance for success.

Keep learning

Read more articles about: Enterprise ITIT Ops