In base allo stato cliente, dal tuo account Red Hat puoi accedere al profilo personale, alle preferenze e ai seguenti servizi:
Non ti sei ancora registrato? Ecco alcuni motivi per cui ti consigliamo di registrarti:
- Per poter consultare gli articoli della Knowledgebase, gestire i casi con il supporto tecnico e le sottoscrizioni, scaricare gli aggiornamenti e altro ancora da un'unica posizione.
- Per poter visualizzare gli utenti all'interno dell'azienda e modificarne le informazioni di account, le preferenze e le autorizzazioni.
- Per poter gestire le tue certificazioni Red Hat, visualizzare la cronologia degli esami e scaricare logo e documenti relativi alle certificazioni.
In base allo stato cliente, dal tuo account Red Hat puoi accedere al profilo personale, alle preferenze e ad altri servizi.
Per tutelare la tua sicurezza, se stai usando i servizi Red Hat da un computer pubblico, assicurati di disconnetterti.Esegui il log out
As 2018 draws to a close, I’ve spent some time thinking about the progress we’ve made with Red Hat OpenShift and where we’re going. Spoiler alert - it’s been an exciting year and I’m optimistic about 2019.
Focusing on operations
We’ve, as a community, spent the last three years focusing on building Kubernetes the platform. And that’s been successful, we’ve seen greater adoption of Kubernetes. As for Red Hat, we have hundreds of customers on OpenShift across a number of industries.
People seem to have accepted Kubernetes as the de facto standard in linux container orchestration. But there’s a lot of work to do around Kubernetes. As a result, the focus has shifted this year from building the platform, to focusing more on how to operate that platform. For example, automation and upgrades. Our acquisition of CoreOS has been part of increasing our efforts to focus on day two and automation, how you operate at scale, how to take advantage of hybrid cloud. The upgrade experience has not been as smooth as users would like so we’ve doubled down on that this year to improve that experience. Our work on the Operator Framework is a good example of this. An early preview of our progress on these fronts to be delivered on OpenShift 4 is available for feedback.
We have also continued to focus on the important work of maintaining the software running mission critical workloads today. The recent Kubernetes privilege escalation flaw, for example, required coordination with upstream and creating eratta for several versions of Red Hat OpenShift Container Platform back to OpenShift 3.2 (shipped in 2016), deploying fixes to OpenShift Online Starter and Pro, and working with customers on OpenShift Dedicated to deploy fixes to their environments.
For customers who want to use OpenShift without maintaining the platform themselves, we offer OpenShift Dedicated and OpenShift Online. Most recently, we expanded the types of EC2 instance types we offer on AWS, and now offer multi-availability zone (AZ) stretched clusters, lower prices, and more.
Consistency across layers
A few years ago, we had debates about Platform-as-a-Service versus Containers-as-a-Service, but that’s pretty much over. We’re seeing users who want to deploy in the hybrid cloud and the expectation from these users is that they have a consistent abstraction layer across platforms. They want a consistent application platform that spans multiple infrastructures.
Users also want a consistent way to package and deploy their applications. The lines have started to blur between what is the infrastructure platform and what is the application platform. Our answer is to support running across the hybrid cloud. Our unified hybrid cloud vision is to allow for multi cluster federation and across deployment footprints. Operators help make this a reality. The Operator Framework gives users a method of packaging, deploying and managing a Kubernetes application. Operators make it easier to package an application and include the operational knowledge to make it easier to run on your environment.
Serverless goes hybrid
We know that many of our customers want to take advantage of the so-called "serverless" movement, and we see a lot of value in the concept to enable flexibility across providers and platforms by providing a standard set of primitives or building blocks.
The good news is that we see technologies like Knative, which we’re contributing to along with many other industry leaders, helping to make serverless across the hybrid cloud a reality in 2019. We are looking to integrate Knative with OpenShift in 2019 to enable our users to take advantage of the power of serverless while still remaining free to choose their cloud providers. We don’t want anyone to be tied to a single cloud provider, or have to re-write applications when they change providers.
Containers on bare metal
Customers do want to run their containers on bare metal. We have seen interest from customers in running container workloads directly on servers, to help wring maximum performance from their applications.
In particular, customers are looking to bare metal for performance-sensitive workloads like artificial intelligence / machine learning (AI/ML). The work we’re doing upstream and with partners like NVIDIA is helping to drive this forward.
We are also envisioning a data center managed with Kubernetes as its underlying infrastructure, which allows us to use virtual machines when they are better suited to a workload than containers. That's the mission of the KubeVirt project, to make Kubernetes a converged platform for running and managing virtual machines as containers. In a Kubernetes native infrastructure world, virtual machines would be able to run as before, but take advantage of Kubernetes' infrastructure, tools, and management. ICYMI here’s a pointer to what we demonstrated in this area in the summer of 2018.
Kubernetes’ role in the enterprise
Kubernetes is still in the early stages of adoption with enterprises, globally. There’s a lot of receptivity to it, it’s the de facto standard in Linux container orchestration, but many companies are still finding their feet in terms of embracing it across the board.
But, we’re seeing interest in doing more than we have in the past. When talking to our own OpenShift customers, we’re seeing customers focused on increasing agility by adopting microservices, achieving greater scale with containers, seeking greater innovation taking advantage of hybrid cloud, and better organizational efficiency by adopting DevOps practices.
When we talk to customers, time and time again I hear that something like 80% of their budget is around maintenance and only 20% goes to innovation. If we can do anything to change that, reduce maintenance and increase innovation, we have the opportunity to help them grow the business instead of merely keeping the lights on. While there’s still plenty of work left to do, Kubernetes (and, of course, OpenShift) has reached the mainstream - and can deliver a platform that can enable a business to focus on innovation.
And, it’s worth noting, it’s already made a difference to many of our customers. People often don’t realize how many services are already powered by OpenShift today. Mission critical services, like airline booking, providing flight pricing data, booking hotel rooms -- if you’ve used the Hilton mobile app to book a hotel room or booked on Cathay Pacific, you’re using services powered by OpenShift.
Enterprises globally are engaging with us on a day-to-day basis, running the OpenShift platform as the basis of a Kubernetes native hybrid cloud infrastructure. It’s a remarkable thing. We’ve made exceptional strides in 2018 with Kubernetes and OpenShift, and have laid the groundwork for even more exciting work in 2019.
About the author
Ashesh Badani is senior vice president of Cloud Platforms, responsible for leading Red Hat’s broad hybrid cloud portfolio, including product development and go-to-market strategy for Red Hat OpenShift, Red Hat OpenStack Platform, Red Hat Virtualization, Red Hat Cloud Suite, and Red Hat Cloud Infrastructure. In this role, Badani has helped to solidify Red Hat as a hybrid cloud and enterprise Kubernetes leader.