Tuesday’s discussion of the Red Hat Cloud Roadmap began with a brief overview of the current portfolio. Host James Labocki, Red Hat senior manager of strategic design practice for integrated solutions, described Red Hat’s vision of a unified cloud solution that meets IT needs “all the way from development to production.”
NASA’s Jet Propulsion Laboratory (JPL) has achieved a lot of firsts: First flyby of Mars. First interplanetary spacecraft. And first selfie on another planet, to name a few.
They got there by staying at the forefront of technology, said Tom Soderstrom, JPL’s chief technology and innovation officer—who also likes to call himself chief toy officer.
To keep innovating, change how you work
With this legacy of firsts, how will JPL get to the next firsts? In his session titled “Innovation is everywhere: Opportunities in a changing world,” Soderstrom said JPL has to change the way they work.
Once every IT decade (that’s 3 years for you and me) JPL looks at what key disruptors are coming and embraces them. What’s coming now? Innovation in the consumer space. There, innovation happens rapidly, unlike in the enterprise where innovation happens at a glacial speed.
The enterprise space could learn a thing or 2 from the consumer space. So JPL researched human behavior as it relates to IT. They discovered that if engineers and scientists can get tools quicker and see what IT disruptors are coming, they’ll be more productive. And that will help all of humanity.
Now JPL practices what Soderstrom calls E4: Engage and enable everyone and everything. It’s about the power of participation (which just happens to be this year’s Red Hat Summit theme).
I was able to wrap up the Summit “graveyard shift” the same way I began the week: Hanging out with the Red Hat Mobile folks. Love those guys.
This session was centered around MAD: microservices, agile, and DevOps. On top of that, Cian Clarke, John Frizelle, and Philip Hayes of Red Hat Mobile showed how all 3 of these pieces relate to Red Hat Mobile Application Platform.
Cian began talking about the new era of applications. Apps can’t cost hundreds of thousands of dollars anymore. They can’t take 6 months to develop; that’s far too long. They don’t live for decades–traditional software lasts for a long time.
“Now, the idea of an application living for 10 years is almost laughable.”
Plenty of people are aware of and use Ansible to manage systems. Whether you need to provision, configure, deploy, or orchestrate systems, at scales small or large, Ansible makes it simple.
As Ansible Director of Community Greg DeKoenigsberg describes it, Ansible is “basically distributed SSH with some other goodness on top. You describe a list of plays, and Ansible uses them to accomplish tasks you’d otherwise have to do yourself.” DeKoenigsberg teamed up with Matt Micene, solution architect from DLT Solutions, to discuss how Ansible is rapidly moving beyond host management into corralling containers.
Ansible is written in Python, with a small, functional core and a hugevariety of modules for almost every imaginable function. DeKoenigsberg showed off some simple examples of Ansible playbooks, which are easy to understand descriptions of tasks. Combine an inventory of systems, variables to distinguish between them, and a set of these Playbooks, and you have a recipe to easily recreate infrastructure on demand.
So Ansible works well to manage the traditional operating system. But what about an OS like Red Hat Enterprise Linux Atomic Host? Some tasks often seen in Playbooks don’t apply. “Mostly,” said Micene, “because we need to reset our fundamental understanding of what the Atomic Host is, versus the general purpose RHEL 7.”
Sometimes things don’t go the way you want. But if you’re Dan Walsh, you don’t give up. You keep working because security is important. Containers are also important, so surely there’s a way to bring these two important things together. Surely.
Dan, a senior principal software engineer for Red Hat, tackled the touchy subject of systemd running with docker. Now, ordinarily, talking about docker or systemd would cause a flurry of responses–champions and detractors. Talking about them together? You must be crazy, Dan. Well maybe so, but Dan is also Dan. That means he’s all for doing the right thing–the right way–to keep businesses and Red Hat customers happy.
Two incredible developers were recognized today for their contributions to open source. Delisa Alexander, Red Hat’s executive vice president and chief people officer, announced that Jessica McKellar and Preeti Murthy won the 2016 Women in Open Source award during this morning’s general session.
“If we don’t continue to evolve and take on challenges, we will get left behind… Innovation is when you take this idea, you cultivate it, and you make the world a better place.” – Genfare
Marco Bill-Peter and Chris Wright took to the main stage early Thursday morning to announce the 2016 Innovation Awards winners. This year, Red Hat celebrates 10 years of the Innovation Awards, which highlights the achievements made by partners and customers around the globe. What makes each winner stand out is their creative thinking, problem solving, and innovative use of Red Hat solutions.
Gordon Haff, a member of Red Hat’s cloud product team, hosts a blog and podcast dedicated to cloud and computing topics. He’s an expert in the field and has written tons of research, offered product and marketing strategy advice, and is frequently quoted by popular publications on a wide range of IT topics. He’s kind of a rock star.
At Summit this year, he’s been writing (and talking) about DevOps. Check out his posts over at Connection, particularly this hot topic pair:
It examines the most important principles for developers starting out with DevOps processes, including automation, metrics, and modularity, and gives excellent advice through metaphor.
What are the right metrics for DevOps?
If you’re ready to dig deeper into one of the principles explored in the previous post, this is where it’s at. Haff discusses the traditional measurements and metrics that app development uses–and why they’re not all appropriate for a DevOps pipeline.
He also looks at the questions you might be asking, and the audiences who might have differing goals for the same processes.