What is Red Hat OpenShift? A cooking story.

(AKA The most non-technical explanation possible.)

Let’s say you’re a world-class chef. Your customers expect amazing food.

You find and source the best ingredients possible. You combine them using your experience, trying different cooking methods and recipes and you serve them up to your customers who are delighted by the meal.

You obviously need great tools to make that happen, so you certainly care about the equipment you use in the kitchen.

In fact, you care SO much about your equipment that you leave the creation of your tools to the experts.

Put another way, world class chefs don’t make their own pans.

And just like the world class customers that use Red Hat OpenShift—they don’t build their own application platform. They know that’s not one of their core competencies.

If you’re a world-class chef, you want to know the pan you use is the highest quality pan possible.

You want to know:

• The core is copper
• The handle has rivets to hold it together
• It has a lid that fits
• It’s durable even in your demanding kitchen

There is one more critical point here: the pan needs to work in different environments. Gas stovetop, electric range, in the oven, or even over an open fire. Why is that so critical? Well, if a pan that only works in one situation, that’s not terribly useful to a chef.

So you do your research and buy the best pan to fit your needs. You don’t go learn how to weld and shape metal into a pan that will be useful.

How does that relate to OpenShift?

With OpenShift, you know that Kubernetes is at the core, and it also has the other components you are going to need, like CI/CD, logging, service mesh and more so it can handle everything you need to throw at it.

Now with OpenShift as your pan, chef, you can run in any public cloud, in your datacenter and all the way at the edge. You can then run your applications in AWS, then move them to Azure, all while running the same applications in your datacenter.

Why do you need a platform that works in different environments?

The restaurant chef has to cook different dishes in different environments, at different temperatures - just like you need to run applications in the environment that is the best fit.

AI workloads are a great example of why organizations need to move between clouds, datacenters and other environments. Your data scientists might be tuning the model in your on-prem datacenter. From there, the developer lifecycles the AI application in the public cloud so you have the necessary compute power. Finally, platform engineering will run it across different clouds, perhaps for compliance reasons, or maybe because the AI application works at the edge, capturing data and making recommendations on-the-spot where the action is happening.

Just like a pan that only works on a specific type of stove, cloud-based Kubernetes services don’t work everywhere. You’ll need to change the ingredients inside the application and adjust the recipe before you can move it to a different environment - a different cloud for example.

When you’re a world-class chef, you don’t make your own pans, knives, stove, oven or any other equipment. Your highest value contribution is what you create using the pan and ultimately serve to your customers. And during the course of cooking, you’ll need to move your pan around to different environments. Same goes for your organization’s applications and workloads. Build once, run anywhere.

Celebrity chefs are known for their food, not for the pan they use and certainly not for making any kitchen equipment.

Shouldn’t you be known for delighting your customers with your applications, not for trying to piece together a DIY app platform or Kubernetes service?

Try Red Hat OpenShift. It’s trusted, comprehensive and consistent. And with it, you can make and launch great apps.

Learn more about Red Hat OpenShift