This is the first post in an ongoing series which will explore the changes, improvements, and additions we’re planning for the next big release of Red Hat OpenShift, version 4.0. Check in each week for more information that will prepare you for the shift to 4.0.
From the time the fledgling Kubernetes community met at the Google office in Seattle for our first face-to-face meeting in the fall of 2014, I’ve believed that Kubernetes was a project that would transform how we build and run software. Over the last few years, we’ve seen countless others come around to that point of view (most enthusiastically, some grudgingly). At the same time, the public cloud providers have continued the massive investments in infrastructure and services that make IT and software easier, simpler, and available at a scale that few people anticipated when the decade began.
Of course, every new public cloud service announced is accompanied by a public Twitter debate between talking heads about, variously: the death of open source, the death of on-premises IT, the inevitability of a new software monopoly in the cloud, and how new paradigm X will replace all other paradigms.
These are very silly debates.
The reality of software is that none of it ever goes away; that we are in the middle of an exponential growth of options in how and what we build that is tied to an enormous expansion of software in our lives, and that while everything will change, everything will also still stay the same. Developers will still write buggy code, operations/site-reliability-engineering will still wear pagers / be pinged by Slack bots, managers will still pay both op-ex and cap-ex, and every time something breaks a senior developer will sigh and say “I told you so.”
The right debate to have is “what tools do we build to make our software better, and how can those tools be safer, simple, and more reliable.” With growing complexity comes risk, and people’s lives now depend on software to a degree that should instill in all of us a commitment to do better.
I strongly believe Kubernetes is one of those tools, and Red Hat OpenShift as a project and product is how I work to combine it with other tools and services together into a platform that can make software more reliable, easier to manage, and safer for the people who depend on it.
With that focus in mind, the OpenShift team has been asking itself, our community, and our customers a simple question:
How can we make operating Kubernetes easier?
The answers are surprisingly obvious:
- Automate the hard parts of deployment on or off cloud.
- Focus on reliability by hiding complexity.
- Continuously deliver easy and safe upgrades.
- Make observability and audit inherent.
- Be more secure by default, without compromising usability.
The next version of OpenShift must take lessons from our and others’ experience of deploying software at scale and in production in the largest companies in the world. It must draw from the combined experience of the open source ecosystems that power our modern world, yet be willing to take steps to change from a hobbyist / tinkerer mindset to an opinionated and automated future. It must be a bridge between the old and the new ways of deploying software and fully leverage all infrastructure – whether it is run by the largest cloud provider or the smallest machines at the edge.
How do we get there?
At Red Hat we have a long history of doing the boring, ugly work that helps keep the lights on in the communities and software projects that we contribute to. In open source there are an enormous number of talented people working to build things that entertain, enlighten, enable, and excite, but there is of course no expectation that we steer in the same direction, or take the same path to the same goals. Harnessing that energy with just a bit of curation is sometimes necessary to lead in directions that benefit our users, but we must also follow and learn from our communities.
In early 2018 Red Hat acquired CoreOS because they shared our vision for a safer, more reliable future built on open source. Together we have refined and executed in open source towards our vision for running all the world’s software securely. That vision is built on top of Kubernetes, Linux, public clouds, private clouds, and the thousand of other projects that are the foundations of our modern digital ecosystem.
We are evolving OpenShift 4 to be transparent, automatic, and ambient.
It will pair the best and most reliable Linux operating system, with bare-metal hardware support, easy virtualization, automatic programming of infrastructure, and of course, containers (which, after all, are just Linux).
It should be secure by default while allowing easy iteration for developers – giving flexibility and reliability without compromising audit and control for admins.
It must allow software to run “as a service” without creating an unsustainable sprawl for operators.
It will let you focus on delivering value to users and customers everywhere, without burying you in the details of operating hardware, software, and the accidental complexity of the past.
OpenShift 4 should be NoOps for operations.