Two Models for DevOps – Rockets and Airplanes

DevOps is harder than rocket science

More and more, agile enterprises require software development to function at supersonic, even interstellar speeds, turning around changes fast, yet safely. DevOps pipelines offer the best way, but what will you really need to fulfill that promise?

Having a good way to understand the impact of CI/CD processes, and the role that container technologies like Docker and Kubernetes play in DevOps, will help. From there, why you need  Artifactory as a binary repository manager to complete it can be seen clearly.

The truth is, running a complete and reliable DevOps pipeline isn’t rocket science.

It’s much, much harder than that.

Blasting off for DevOps

We often think of the continuous integration process as a simple left-to-right, linear process: Code is written, submitted, built, tested, deployed, and delivered for production. Software is created to be “shipped,” meaning that it has a clearly defined place to go.

In this model, creating an application is like sending a mission to Mars. You have to plan, review, test, and verify everything before allowing the mission to go ahead.

To prepare for a rocket launch, teams have to collaborate closely. You only get one chance to launch a single rocket, and after liftoff, there’s no opportunity for changes or updates. From the pad to the stars, a rocket’s abilities are fixed, and immutable.

Rockets are also expendable. Each test requires building a new rocket, with its own unknown risks, until all systems are “go” to commit to the final launch that completes the mission.

DevOps is harder than rocket science

It’s a clean, classic engineering model. But that’s not the way DevOps works.

Running DevOps Fleets

What the rocket model gets right about DevOps is the way development and operations teams collaborate closely through all stages of the development lifecycle when creating and operating a service.

But DevOps isn’t a simple left-to-right process toward a single high stakes launch. Instead, it’s a frequent and unending cycle, where every take-off brings its own risks to quell.

Rather than a mission to space, DevOps is more like the modern airline system. Airlines execute very frequent — in fact, continuous — launches of airplanes, with the trust of more than a million people in the air globally at any given time.

An airline’s procedures to manage its fleet and routes turns out to be very much like the ways a DevOps pipeline keeps your applications current and reliable. Like your enterprise, airlines need to keep up with technology, swiftly respond to security issues, and adapt as customer needs change, all while the overall system runs uninterrupted.

As an ongoing practice, an airline inspects (tests), maintains (patches), and rotates in and out of service each of its airplanes. This process is very much like continuous integration, delivery, and updates of each of your applications.

Unlike rockets to Mars, airplanes have to land and fly again, and again, and again. The plane that is put into service is the same vessel that passed its test flights.

Now that you understand the difference, how do you get your DevOps process to operate less like a rocketeer and more like an airline?

Clearing for takeoff

Rockets and airplanes are each the product of many sources. Different internal departments have responsibility for the structure, mechanics, and controls of the vessel. Similarly, multiple teams across an organization contribute to your applications.

Yet, it’s different vendors who provide most of a vessel’s components, from mundane elements like latches, seats, and carpet, to the complex navigation systems. So too is most of the code your application runs, like the OS and language framework, typically sourced from outside the enterprise through remote repositories.

Developers can control what parts of their own code goes into their builds. But what about your remote packages, like npm and Maven, that are downloaded from public repositories? Those might change at irregular intervals that are outside of your control.

If your DevOps process is like building rockets, each new build for testing or release is an opportunity for a stowaway to sneak on board.

Without some way to assert oversight, things you don’t want can slip into your builds, and you might never be able to build the exact same result more than once.

DevOps is harder than rocket science

Getting to the runway

Docker images are your vessels, whether they’re rockets or airplanes. They’re what you build, and encapsulate the functionality that the application will perform. From launch to landing their capabilities remain the same.

Docker, with its registry of the images, helps get the vessels to the pad or gate by turning them into containers, where an orchestrator like Kubernetes gets those containers into flight.

Treated like rockets, each Docker image you build as you develop, test, or release to production — a new rocket each time — might be a bit different from the last.

DevOps is harder than rocket science

Treating them like airplanes means ensuring greater certainty of what you are putting into the sky. Airlines don’t build a new plane for each takeoff, they test them, and then run them on routes reliably until they need to be replaced.

Building one Docker image that you promote, rather than rebuild, through your pipeline to test and release, assures that what Docker brings to the gate will fly safely, on time, every time.

DevOps is harder than rocket science

Ground control

As we hope you see, real DevOps procedures aren’t cleanly left-to-right, but complex, iterative, network processes of design, factoring, and refactoring.

To run your DevOps pipeline more like an airline, Artifactory can be the ground crew that keeps everything running smoothly and on schedule. Artifactory empowers developers to control the Docker images they build from code, and gain the reliability and speed that comes from always putting into flight the same craft.

To start, Artifactory solves a key developers’ challenge of being able to create stable, deterministic builds using external dependencies like npm and Maven. With Artifactory, developers can maintain a local cache of the remote repository, to keep code changes from sneaking into builds before they’re ready for them. Keeping dependencies near also helps speed those builds, improving developer productivity.

Using Artifactory as your Docker registry also makes it easier to promote immutable build outcomes through test and release phases of your DevOps pipeline, rather than rebuild for each. And if you need to, you can create deterministic builds from the exhaustive information Artifactory stores about each build.

Airplanes fly on fuel, but airlines — like all modern enterprises — operate on data. Knowing more about their fleet, their customers and their personnel helps maximize their return on investment.

When Artifactory serves as your Docker registry for Kubernetes, it provides the data you need to streamline and secure your operations. More than a list of container images, it grants visibility into what is in them, and how they got there.

When you add image scanning with JFrog Xray, you can acquire more data about how safe the code in those images really is, further protecting your enterprise.

Fly the Friendly Skies

Don’t just take it from us that true DevOps is like a modern airline. DevOps has become a crucial practice for most airlines in their own operations.

United, Southwest, Alaska Air and JetBlue are among the many airlines that have made huge investments in DevOps and CI/CD to help serve customers on web and mobile platforms for ticketing, check-in, boarding and more.

Many of them have included Artifactory in their environments, finding the full benefits of DevOps at global scale along the way.

As these high-stakes enterprises show, just getting your Docker containers onto the runway isn’t enough for true DevOps. It takes the support that Artifactory brings to CI/CD that keeps these birds safely in the air.

Want to give Artifactory a test flight? Get a free, 30-day trial from JFrog.