Con su cuenta de Red Hat puede acceder a su perfil de miembro y sus preferencias, además de a los siguientes servicios teniendo en cuenta su estado de cliente:
¿Aún no se ha registrado? Le ofrecemos varios motivos por los que debería hacerlo:
- Consulte artículos de la base de conocimiento, gestione casos de soporte y suscripciones, descargue actualizaciones y mucho más desde una misma ubicación.
- Consulte los usuarios de la organización, y edite la información, preferencias y permisos de sus cuentas.
- Gestione sus certificaciones de Red Hat, consulte el historial de exámenes y descargue logotipos y documentos relacionados con las certificaciones.
Con su cuenta de Red Hat puede acceder a su perfil de miembro, sus preferencias y otros servicios dependiendo de su estado de cliente.
Por seguridad, si está en un equipo de acceso público y ya ha terminado de utilizar los servicios de Red Hat, cierre sesión.Cerrar sesión
This post is the second in a three part series. You can find part one here.
Enterprises require commercial open source products, not open source projects.
The rush to enable and adopt Kubernetes is evident with nearly weekly announcements of new Kubernetes distributions or services. The CNCF Kubernetes Conformance Program lists, as of this writing, at least 37 conformant software distributions of Kubernetes alone, plus additional hosted services.
That’s a lot of choice. But many of these vendors and organizations are certifying and delivering just Kubernetes, or Kubernetes plus one or two components that add some extended functionality, not an overall solution or platform in which Kubernetes plays a part. Just like the Linux Foundation is the governing body for the upstream development of Linux, which is also one piece of the much larger operating system platform, so is CNCF the governing body for Kubernetes. Conformance in the upstream development stage does not imply a viable enterprise solution.
Importantly, we need to remember that Kubernetes by itself doesn’t do anything. Just as the Linux Kernel is a core component but not a solution in and of itself, so too is Kubernetes a key piece of larger solutions. Certifying a single piece of a product has a limited use case. All the pieces that make up a commercial product or platform have to integrate with each other, be supported, updated, and coordinated with security fixes. This platform needs a lifecycle to run an enterprise’s business. It also needs to be certified to work in a given environment on specific hardware configurations in its entirety, as all the components are critical to the success of that solution and must work together. Software and hardware vendors that want to build compatible solutions also need a "point of sanity" to test, certify, sell, and support its solution.
This means Kubernetes must integrate with all the other pieces of a product or platform, including the Linux container distribution, for a solution that an end customer can build their mission-critical applications on and rely on over time.
For example, with Red Hat OpenShift Container Platform, we are certifying an entire enterprise application platform based on Kubernetes, not just one technology that is part of the platform. What we stand behind with this certification is that all of these pieces will work together from day one deployment through end of life. Even when changes have to be made through updates or security patches, or changes happen in multiple components of the platform (e.g. in the Linux distribution, in Kubernetes, and in services running on top of Kubernetes), we are going to certify the surrounding ecosystem, including multiple infrastructures, like bare metal, OpenStack, and major public cloud providers. It means that we are going to be the "one throat to choke" as a company to support that integrated solution, of which Kubernetes is, again, one part.
Let me show how this plays out in the real world. Let’s say that a fix needs to be made in one of the Linux kernel APIs with which Kubernetes interfaces. We are certifying that the fix will be backwards compatible with other pieces of the platform so that no critical applications, services, or integrations break. Or, when there is a security vulnerability that may need changes on both sides of any one of those APIs, we certify that we will not only fix that vulnerability in both places, but that it will also be backwards compatible.
This is exactly what we have been doing and what our customers depend on us to do with Red Hat Enterprise Linux for the past 15 years.
It’s companies like Red Hat that bring all of these disparate open source-developed projects together, to move in one motion to solve a real business problem. Customers are going to run platforms that consist of many of these upstream pieces, and associated with many governing bodies, but work together as a supported, integrated product for mission-critical enterprise applications.
As we saw in the multitude of choice in Linux distributions beginning in the early 1990s, choosing a platform isn’t just about answering the needs of developers and infrastructure teams today. It’s about understanding how the needs of these teams will change as they build, integrate, and maintain applications over the long term. In short, choosing a platform is a very long game and a critical decision for CIOs.
If customers are choosing a platform to run their enterprise, they should be choosing an open source-based product not an open source project. While both build off the same principles of community and open source innovation, product and projects differ greatly in their ability to offer a stable, secure, cost-effective, and supportable solution long-term. Especially when considering how to use Kubernetes and containers in a hybrid cloud environment, which is swiftly becoming the reality for every organization.
Based on this, let’s now walk through the differences between an open source project versus a commercial product based on open source development.
Community-driven open source projects, such as the Linux kernel and upstream Kubernetes, by necessity, thrive on robust, engaged communities of developers and users. They are the force behind a project’s innovation, helping to answer community-defined problems through rapid evolution, short code lifecycles, and a willingness to fail and "break everything" just to see what works.
Building from upstream community projects are often open source distributions (often called downstream), such as Fedora, CentOS, Wildfly, and Project OKD, formerly OpenShift Origin. These projects typically bring together multiple open source technologies and provide a targeted foundation for further community-based development and innovation, while ensuring all innovation that might be developed at this stage goes back to the upstream tree. This is the technology that feeds the next stage of development that becomes the base of an enterprise-class product. In the Linux space, Fedora is the last phase of development before it becomes Red Hat Enterprise Linux.
Red Hat Enterprise Linux is an example of a commercial open source-based product, with all of the commercial attributes we discussed above. Products like this follow the same upstream feature alignment as the community and/or distribution projects upon which they are based, but do so prescriptively. These products emphasize the long game that is enterprise IT, focusing on long-term maintenance like hardening, backporting, API/ABI compatibility, security response, technical support, and specific ecosystem relationships through OEM and ISV certification.
With enterprise products, we offer opinionated choices of configurations, deployment options, and features, yet permit users to inject other components which do not disrupt the integrity or supportability of the core product.
If you look through the eyes of ISV and IHV vendors that are seeking a Linux-based container platform to support and drive compatibility, they are not able to test a matrix that includes 30+ versions of the various components of the platform, like Kubernetes, Linux containers, etc. This does not even account for the fact that the versions will often change every six to 12 months with base code compatibility typically ranging between 75-99%, depending on what components/versions are used and what bug fixes are applied to any part of the platform. Every time one of those minor changes happens in any one of those components, at a minimum, the test matrix needs to be executed again.
ISVs and IHVs want a stable offering, supported by a trusted software supplier, with a program to enable support, the development of a sizable market opportunity for selling its solution, and an ongoing business collaboration.
Just as in selecting a Linux distribution, choosing a commercial, open source, enterprise Linux container and Kubernetes solution is a key to factor in building a modern, digitally-transformed enterprise, one that emphasizes the hybrid cloud. This choice offers developers, operators, and customers added confidence that a specialized vendor will maintain and evolve its platform choice to match its changing needs for years to come, even in the face of a restless technology and business landscape.
As your teams sit down to decide on the future direction of your enterprise IT infrastructure, focus on the long-game solutions that align with the community, provide complete environments, and, most importantly, are designed to service business needs as the priority.
Check in soon for part 3, where I will examine the realities of today’s Kubernetes landscape and why a commercially-supported Linux operating system remains such a critical piece to enterprise adoption.
Paul Cormier is president, Products and Technologies, at Red Hat.
About the author
Paul Cormier is Chairman of Red Hat. He has been with the company since 2001 and previously served as President and Chief Executive Officer. During his tenure, he has driven much of the company’s open hybrid cloud strategy, playing an instrumental role in expanding Red Hat’s portfolio to a full, modern IT stack based on open source innovation.