We can hardly contain our excitement (but we can contain your apps)

If you had any doubts about the role of containers in enterprises, day one of Red Hat® Summit definitely dispelled that rather quickly. From Paul Cormier’s morning keynote--featuring Macquarie, Optum, and Barclays--to the general sessions led by Red Hat engineers: Containers have arrived.

Get down with the app-down perspective
Daniel Riek, senior director of systems design and engineering at Red Hat, kicked things off with a bit of a history lesson. He spoke of the changing role that the LinuxⓇ OS has had over the years, from commoditizing the mainframe and killing UNIX to its role as the development liberator. As a self-described “greybeard” of the Linux world, Daniel has seen these changes first-hand. He’s also lived through the days of dependency, highly fragile applications, and inflexibility. Now, he sees the Linux OS very differently--the opposite of how it used to be. Rather than looking at it as the thing that makes hardware light up, Linux is the provider of a consistent runtime for applications. It’s working for and with the apps, instead of being the thing that got in the way--an app-down perspective.

Daniel also spoke of three major use cases for containers:

• The fully orchestrated multicontainer app
• The loosely orchestrated container app
• The pet container

Each of these turn out to be very different from each other, using key technologies in different ways (or not at all). But that’s the point, isn’t it? Get out of the way and let developers develop and get their apps out there--fast.

Boring is the new black
Daniel teamed up with Clayton Coleman, consulting engineer and OpenShift lead architect for Red Hat, for his second session, which was a walkthrough of Red Hat’s container technology strategy. Here’s the thing about that title: It’s not exactly accurate. The real story here isn’t containers. It’s the apps they hold. That’s what all of this technology is really about. So, let’s call it Red Hat’s application technology strategy. And, because everyone loves a metaphor, they came prepared. Think of an ice cream cup or cone without the ice cream. Not very interesting, is it? The ice cream is the thing you want--it’s the applications that make your business valuable. Not to imply the container for that ice cream isn’t important. It needs to be there and it’s what makes the ice cream able to be enjoyed. Same thing with Linux containers.

“Your business should be exciting, not your infrastructure.”

Clayton and Daniel then gave away a huge Red Hat secret: We’re here to make technology boring. (Don’t tell anyone.) That means making containers boring. But it makes sense. You want to be able to use your technology stack without wondering what might go wrong. You need it to be stable and reliable. That’s boring. And boring is good.

So what’s Red Hat’s strategy? Well, Kubernetes will play a huge role in applications (and containers) going forward. From where Red Hat sits, Kubernetes has won--it’s the technology that’s really making containers work. And since no container stands alone, Kubernetes is quickly becoming the glue that holds everything together. It's about apps, community, patterns, and technology. It’s about true open source. It’s the thing that orchestrates all the extras that really make containers work. Addressing security concerns will feature heavily, of course, as will services to extend the Red HatⓇ OpenShift platform. More on that next.

Red Hat’s vision is centered around the app, being able to:

• Run any service, anywhere, through a common abstraction and integration layer.
• Augment the vertically integrated cloud to commoditize all infrastructure.
• Empower developers everywhere and standardize the app dev life cycle.

Verizon shares how they used containers to modernize search functionality on their website.

Shifting into high gear
The folks from OpenShift are fun. They’re having a great Summit so far, and attendees are excited by the advancements and demos taking place. And what better way to have fun than make fun? Diogenes Rettori, the OpenShift product manager at Red Hat, played the role of the hipster, modern developer as he tortured his ops counterpart, played by Steve Speichter, also an OpenShift product manager. This was some seriously cool stuff. The dev is needy, wants to try new things, get resources provisioned, and changes his mind over and over. The ops guy, as a result, spends entirely too much time making this happen for him, answering tickets, then doing it all over again.

There’s got to be a better way.

The OpenShift team showed off some new features that allow the developer to get what he wants (and needs) quickly. And the ops team never has to lift a finger. True self-service. OpenShift is running all of these services and this example covered integration, messaging, and microservices--all made available directly to the developer. They also showed off OpenServiceBroker API, a simple way to get services to apps running on OpenShift, and introduced automated OpenShift deployment through Ansible playbooks.

We then looked to the future of Kubernetes (they won, remember?) and the federation capabilities coming soon, as well as a list of other future features that covered cluster reliability and resiliency, persistence, security, and workload diversity. Things are moving fast over on OpenShift. You should also check out the general availability of Red Hat OpenShift Online and OpenShift.io.

App modernization is a big deal right now. It’s hard. It’s expensive. And it takes a lot of time. But it’s necessary because you can’t keep dumping resources into legacy apps. There are 3 approaches to getting this done:

• Lift-and-shift
• Augment/refactor
• Completely rewrite

A lift-and-shift approach takes your well-architected app with mostly separated services and puts it into containers. The augment/refactor approach tackles the legacy apps that are difficult to break down and does just that to the existing code. A complete rewrite is exactly how it sounds: throwing away the legacy app and writing it with a microservice/container approach from the start.

Each of these approaches has a cost. Lift-and-shift has the lowest financial impact, but can be more time intensive than augmenting. Augmenting usually has a much higher cost, but lower time commitment. The complete rewrite is expensive and time intensive.

We can hear you now

Verizon needed to modernize their search function on their website. This was a strategic change to enable customers to find answers to problems more easily--lowering the number of support calls and cases. Their app was built on a monolithic platform, and they had lots of challenges with scaling (as their platform was proprietary), unsustainably large releases, quality, and environment lockdown. On top of that, there was little to no automation for development and deployment.

With a little innovation and some good, old-fashioned hard work, Red Hat was able to help Verizon by isolating pieces of the app into containers, built from dockerfiles. Then they moved all of that onto OpenShift (I told you they’re having a great Summit) via pod templates. And best of all: This was all done with open source technologies. So, vendor lock-in is avoided.

They also gained disposable nonproduction environments, autoscaling, self-service to eliminate wait times, and integrated continuous integration / continuous delivery (CI/CD). Oh and they did all of this, from scratch, in less than 2 months. Start to finish. Proprietary to open. Legacy to modern. Bad to great. Now their app is also portable across  many environments and public and private clouds. Such a great story.

That was a lot in one day
This is just the start of containers at Red Hat Summit. The next few days will no doubt give us many more stories. But, what a way to start. A history lesson. Proof of successful implementation in enterprise environments happening right now. And a glimpse into the future.

Here’s to tomorrow.