The best demos are live demos. They’re intense, fast-paced, and full of excitement–for the audience, of course. The presenters never want excitement. They want everything to work as expected. And the keynote demo this morning delivered all of that and more.
“Think of this as our flying trapeze act.”
Burr Sutter, Red Hat’s director of developer experience, gave a demo that spoke to the core of Red Hat Summit: The developers. The operations teams. Those that do. This demo built on the concepts that Paul Cormier addressed earlier in the morning. Developers feel many pains in their day-to-day lives and need resources to make apps work, then into production. Even getting their environment set up properly can be a chore. File tickets. Wait. Hope. Get resources. Code. Rise and repeat.
On the other side, operations teams are constantly getting barraged with requests from developers. Ticket after ticket comes in requesting resources. But developers don’t understand all that ops have to deal with. Dependencies, requests, patches, updates, more tickets, more requests, more updates. It’s impossible to keep up with.
DevOps to the rescue
The power of DevOps is that these teams can be linked together in culture, processes, and tools. What if you had a way to automate all of this? A single place for everyone to work together and cast aside the madness. A way to get to production faster, using containers, and continuously integrating and delivering. And what if you could see it live at the Red Hat Summit? Yeah, that’d be cool…
Burr brought a team of developers, engineers, and ops folks on stage to show you live. None of that behind-the-scenes stuff flies at Red Hat Summit. And why should it? These are the people that make things. Just like the audience. Let’s show them off.
On stage, we had Burr along with some other fantastic Red Hatters: Kyle Buchanan, Joshua Wilson, Kevin Conner, and Jason DeTiberus. Everyone acted as part of a full DevOps team, from front-end developer to back-end, ops, and business analyst.
The architecture was built on the platform of OpenShift by Red Hat. This allows the developers to spin up resources they need–when they need them. It allows the ops team to manage and constrain those capabilities to maintain control of the underlying infrastructure. No more tickets–just what people need when they need them.
I won’t go into great depth on the rest of the technology that made the demo possible. The team had Jenkins to monitor and push via Git, Red Hat JBoss EAP 7, Red Hat BPM Suite for business rules management, the upstream Wildfly Swarm to embed Java architecture in .jar files, Node.js, and Vert.x to glue everything together.
This particular demo was a game. The game is simple. Balloons fly on your screen. You pop them. You earn points. Sometimes simple gameplay is the most addictive gameplay. Burr then showed the power of all of these tools working together. We visited each piece along the step of making the app, working in Red Hat JBoss Developer Studio 10 on top of Red Hat Enterprise Linux and OpenShift by Red Hat. We then shifted to the ops side to see a beautiful pipeline visualization tool. And, as one side of the stage modified the code and committed it, we could visually see the push going through testing to staging and, finally, production.
Let me stop for a second. There’s a lot going on here. It’s very attractive stuff and, frankly, exciting to see this kind of interaction for something that isn’t usually that pretty. We can see, visually, a blue-green deployment–in real time and watch as the teams switch between the two with no downtime.
Burr then assumed the role of the business analyst and was able to participate as a developer without writing code–updating business rules from a browser. We then moved deeper into ops to monitor the infrastructure: Ansible Tower by Red Hat, OpenShift by Red Hat, and Red Hat CloudForms.
All of this was running with interaction happening between the folks on stage. Burr took it one more step further: audience participation. Anyone could join the game. The game could be stopped at-will by ops teams. The game could be updated live. Updates could be rolled out to a percentage of the audience or everyone. Canaries could be rolled out to test certain updates and then rolled back if they were a failure–or rolled out fully if successful.
All of this was happening before our eyes, on or devices. In a few short minutes, the real-time stats showed more than 850 players interacting with the game more than 200,000 times.
One more thing
As a final, fun addition to the game, Burr then asked us to all take a selfie and upload it into the game, which then built a Red Hat logo collage.
Best. Session. Ever.
> See the illustrated version.