In the previous post I described the goals that helped shape the OpenShift 4 vision.  We want to make the day to day of software operations effortless - for operations teams and for developers.  How do we make that goal - a NoOps platform for operations - a reality? What does “NoOps” mean in this context?

At a ten thousand foot level, “Serverless” or “NoOps” for developers is characterized by tools and services that hide or minimize the operational burden from the developer.

  • Don’t consume systems - consume APIs.
  • Don’t deploy software - have the provider deploy it for you.
  • Don’t start with a large framework - write small pieces of software as building blocks and connect them with data and events rather than disks and databases.

The goal, as always, is to iterate faster and deliver better experiences while worrying less  about the systems that run your software. The developer knows that things will change rapidly as you focus on your users - don’t over-invest in the ceremony of writing software until you’ve proved the problem is worth solving.

For an operations team, the phrase NoOps might sound scary. But when we talk to and collaborate with operations teams, the patterns and practices espoused as Site Reliability Engineering (SRE) has some deep similarities to the patterns we described above:

  • Don’t manage systems - automate their management.
  • Don’t deploy software - define a deployment pipeline.
  • Don’t couple all of your services together in a single failure domain - spread them out with infrastructure automation and connect them with observability.

The SRE knows that eventually something will fail and that a human will have to debug the problem - they automate the toil away and set error budgets so they are ready to prioritize and react when it does.

Kubernetes through OpenShift is a platform designed for realizing these two goals - instead of forcing you to deal with VMs or load balancers APIs, we focus on higher level abstractions like deployments and services. Instead of installing software agents you run containers, and instead of writing your own monitoring stack you leverage ambient monitoring from the platform. The secret sauce of OpenShift 4 is no secret - take the serverless and SRE principles and carry them to their logical conclusions to help developers and operations:

  • Automate and standardize infrastructure in service of the application.
  • Blend deployment and development without limiting the developer.
  • Make running, auditing, and securing the hundredth service, function, application, or stack as easy as the first.

What distinguishes OpenShift 4 from its predecessors and the “standard” approach to solving these problems?  How do we enable operations teams to scale?

  • Make clusters self-describing - don’t just run on a cloud, tell it what to do.
  • Machines and the operating system that run them exist to serve the cluster.
  • Control the host state from the cluster, and minimize the drift hosts may have.
  • Every important part of the system needs a babysitter reconciling and fixing problems.
  • Make failure and recovery an expected part of *every* aspect of the system.
  • Everything must be configured via an API.
  • Use Kubernetes to run Kubernetes.
  • Updates have to be no big deal - if an update isn’t pushing a button, it’s wrong
  • Every component has to be easy to monitor and debug, and conversely summarizing and monitoring everything has to also be easy.

Over the next few weeks we’ll discuss each of these topics in more depth, but the best way to see how they work is to try it for yourself.

Want to see it now?

That is why I am happy to announce the Developer Preview of OpenShift 4 is now available for public trial. This is a sneak peek of the next version of OpenShift, with an easy to use installer for starting a cluster on AWS on top of Red Hat CoreOS. The preview requires only credentials to an AWS account to provision infrastructure and a set of credentials to access the images for the preview.

  1. To get started, visit try.openshift.com and click on “Get Started”.
  2. Log in or create a Red Hat account and follow the instructions for setting up your first cluster.

Once you’ve successfully installed, check out the OpenShift Training walkthrough for a deep dive on the systems and concepts that make OpenShift 4 the easiest way to run Kubernetes.

We hope you are as excited about the future of OpenShift as we are. Give the preview a try, and give us your feedback. We want to make Kubernetes effortless - the NoOps future starts today.