Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Elizabeth White, Liz McMillan, Pat Romanski, TJ Randall

Related Topics: @DevOpsSummit, Microservices Expo, Containers Expo Blog, @CloudExpo

@DevOpsSummit: Blog Post

Air Traffic Control for Agile Enterprise By @Plutora | @DevOpsSummit [#DevOps]

The two disciplines are very similar both deal with a delicate transition between two states

Plutora is the necessary "Air Traffic Control" for an increasingly Agile Enterprise

By Dalibor Siroky

I keep coming back to this analogy because it's the most apt description of what Plutora provides for the Enterprise.

We provide the software that you need to manage a busy release schedule.  Without Plutora you are forced to use manual methods to orchestrate releases and manage resources, and the analogy that connects with most of our customers is that Plutora is the necessary "Air Traffic Control" for an increasingly agile enterprise.

The two disciplines are very similar both deal with a delicate transition between two states.  Air Traffic Controllers deal with the transition being in-flight and on the ground, and Release Managers deal with the transition between in-development and running on production.  Both disciplines involve a highly orchestrated sequence of operations to minimize risk and manage these transitions, and both jobs involve managing several competing inputs at once.  While an Air Traffic Controller needs to guide 10 airplanes onto a busy runway, a Release Manager has to guide 10 projects onto a busy set of environments.

In terms of risk, both disciplines are also similar. Air Traffic Controllers are responsible for an incalculable amount of risk both in terms of hardware and lives, and Release Managers are responsible for the smooth operation of multi billion-dollar production networks.  In this post I'm developing this analogy to demonstrate that our current, reactive approach to release management is reminiscent of the way we landed planes in 1929 (yes, we landed planes in 1929.)

A Quick Tour through the History of Air Traffic Control:

1920s: Flashlights - Guidance on Landing and Take-off Only

In the 20s airplanes were guided to landing by people holding "flash lights." Planes only received direction when they approached an airport. Terrifying, right?

1930s: Pushing Figurines Around a Map

With the advent of radio communications controllers could now communicate with pilots, but radar had not yet been invented.  Controllers talked to pilots and pushed boat figurines across a map.

1950s: More Planes + Disaster Spurs Installation of Radar

After a disastrous mid-air collision the US Congress created the FAA and funded a real radar system to track planes. More radar coverage allowed controllers to track planes as they made progress toward a destination.

1975: Computerized Flight Plans, "Modern" Air Traffic Control

While technology has improved in four decades the modern approach of filing flight plans and passing planes between regional control centers has remained in place since the mid-70s.

A Quick Tour through the History of Release Management

2000s: Flashlights - Guidance only during a Release

This is the current state for most enterprise release managers.  There is no visibility into project lifecycle until a project shows up as ready to deploy to production.    For many release managers the earliest warning they will get that a project is ready for a release is, "Hey, can we do a production release tonight?"

There are only a few environments available and there is often little room for schedule slippage or error.   If too many projects show up at once, a release manager is in serious trouble. These risks were manageable when there were only a few projects in the landing sequence.

2010s: DevOps - A Collection of Tools, No Transparency

With busier skies, release management has started to take a more proactive approach to tracking projects on a release trajectory, but most release managers are still disconnected from the development groups that drive activity.

Release Managers in this decade are often left with a series of unrealistic release plans spanning entire departments.  It is up to the release and environment management group to pick up the phone and ask projects if they are still on track to delivery software.  While release managers aren't pushing boat figurines across a physical map, we are often updating wholly inaccurate Gantt charts that drive flawed estimates of capacity and over-budgeted hardware spend.

And, that's where the story ends.  When you compare the history of Air Traffic Control to the history of Release Management  you'll realize that we still lack the predictability and control that Radar brought to Air Traffic Controllers.  While most Release Managers will tell you they can predict activity in a week or two, many will express frustration when they try to extend plans further in the future.

Release managers are often just waiting for the next emergency.  The next close call when one business-critical application needs to land on the same environment as another business-critical application and they are asked to perform last-minute miracles to make up for the fact that the modern Enterprise hasn't invested in the necessary tools to track multiple projects as they progress toward a software release.

Most Enterprise Release Managers are Stuck in 1929

Release management is still viewed as process that begins at the end of the software development lifecycle and very few organizations have a release management function that tracks project progress from inception through implementation to delivery.  In many cases, the release manager is standing there, at the end of the runway pointing colored flash lights at approaching planes and while this approach worked in previous decades it doesn't work today.

Software releases are more frequent and involve significantly more risk, and every now and then Release Managers have to avoid colliding initiatives.   It's time to upgrade to a modern release management "Radar,"  and that radar is the Plutora Release Manager.

With Plutora:

  • You can connect to all of your project's JIRA issues and track multiple projects as they progress toward a software release.
  • You can visualize the conflicts that may arise between project release schedules and reroute projects that are on a collision course for an environment or QA resource.
  • You can understand what the current capacity of your team is and quickly identify if critical resources such as QA or release engineering are in danger of burn out.

Just like an ATC controller can call up an airliner in transit and ask them to either speed up or slow down to anticipate traffic jams hours ahead of time, with Plutora your release managers will be able to look far into the future to understand how projects need to adjust to ensure that business initiatives are not blocked for lack of resources.   You can forecast what your IT environment budget will look like months in advance.

When we compare Release Management with Air Traffic Control it's clear that it is time for Release Management to move into the 1950s or even the 1970s.

Would you land at O'Hare if there was just a guy standing on the edge of the runway with a set of flashlights?  If the answer is no then why would you expect your release manager to manually track software releases with spreadsheets during the final phase of software delivery? For many of our customers there's considerably more risk involved in managing an efficient release pipeline.

When you have billion-dollar software initiatives in the air, you should invest in tools that give you the ability to manage the transition from development to production with ease and efficiency.

More Stories By Plutora Blog

Plutora provides Enterprise Release and Test Environment Management SaaS solutions aligning process, technology, and information to solve release orchestration challenges for the enterprise.

Plutora’s SaaS solution enables organizations to model release management and test environment management activities as a bridge between agile project teams and an enterprise’s ITSM initiatives. Using Plutora, you can orchestrate parallel releases from several independent DevOps groups all while giving your executives as well as change management specialists insight into overall risk.

Supporting the largest releases for the largest organizations throughout North America, EMEA, and Asia Pacific, Plutora provides proof that large companies can adopt DevOps while managing the risks that come with wider adoption of self-service and agile software development in the enterprise. Aligning process, technology, and information to solve increasingly complex release orchestration challenges, this Gartner “Cool Vendor in IT DevOps” upgrades the enterprise release management from spreadsheets, meetings, and email to an integrated dashboard giving release managers insight and control over large software releases.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


@DevOpsSummit Stories
The Kubernetes vision is to democratize the building of distributed systems. As adoption of Kubernetes increases, the project is growing in popularity; it currently has more than 1,500 contributors who have made 62,000+ commits. Kubernetes acts as a cloud orchestration layer, reducing barriers to cloud adoption and eliminating vendor lock-in for enterprises wanting to use cloud service providers. Organizations can develop and run applications on any public cloud, such as Amazon Web Services, Microsoft Azure, Red Hat OpenShift and Google Cloud Platform.
Because Linkerd is a transparent proxy that runs alongside your application, there are no code changes required. It even comes with Prometheus to store the metrics for you and pre-built Grafana dashboards to show exactly what is important for your services - success rate, latency, and throughput. In this session, we'll explain what Linkerd provides for you, demo the installation of Linkerd on Kubernetes and debug a real world problem. We will also dig into what functionality you can build on top of the tools provided by Linkerd such as alerting and autoscaling.
With container technologies widely recognized as the cloud-era standard for workload scaling and application mobility, organizations are increasingly seeking to support container-based workflows. In particular, the desire to containerize a diverse spectrum of enterprise applications has highlighted the need for reliable, container-friendly, persistent storage. However, to effectively complement today's cloud-centric container orchestration platforms, persistent storage solutions must blend reliability and scalability with a simple, cloud-native user experience. The introduction of Elastifile's CSI driver addresses these needs by augmenting containerized workflows with highly-available, scalable NFS file storage delivered via Elastifile Cloud File System...and with no complex, manual storage provisioning required.
Applications with high availability requirements must be deployed to multiple clusters to ensure reliability. Historically, this has been done by pulling nodes from other availability zones into the same cluster. However, if the cluster failed, the application would still become unavailable. Rancher’s support for multi-cluster applications is a significant step forward, solving this problem by allowing users to select the application and the target clusters, providing cluster specific data. Rancher then initiates deployment to those clusters.
Implementation of Container Storage Interface (CSI) for Kubernetes delivers persistent storage for compute running in Kubernetes-managed containers. This future-proofs Kubernetes+Storage deployments. Unlike the Kubernetes Flexvol-based volume plugin, storage is no longer tightly coupled or dependent on Kubernetes releases. This creates greater stability because the storage interface is decoupled entirely from critical Kubernetes components allowing separation of privileges as CSI components do not need full privileges of Kubernetes components. With the implementation of Container Storage Interface (CSI), persistent data layer for Kubernetes and other Container Orchestration (CO) tools, such as Mesos and Docker Swarm are now future-proofed.