Red Hat this week reveals it has extended its alliance with Amazon Web Services (AWS) to include a managed Red Hat OpenShift service that the two companies will jointly provide.

Based on Kubernetes, the Red Hat OpenShift application development and deployment platform is at the core of the hybrid cloud computing strategy that Red Hat and its parent company, IBM, are betting will drive the next wave of enterprise computing.

Under the terms of the expanded alliance with AWS, the two companies are making available a managed Red Hat OpenShift Service on AWS (ROSA) that is more tightly integrated with the AWS Console.

That offering enables customers to subscribe to Red Hat OpenShift services, which will appear on the same bill IT organizations receive for the other AWS services they consume. There are no up-front investments required to use ROSA, and IT teams only pay for the container clusters and nodes they actually consume.

Sathish Balakrishnan, vice president of hosted platforms for Red Hat, says this managed service offering is similar to a managed service offering that Red Hat offers jointly with Microsoft. Demand for managed services has increased significantly because developers have accelerated the rate at which cloud-native applications are being built, even though Kubernetes management expertise among internal IT operations teams remains in short supply.

At the same time, many IT organizations are now looking to standardize on a single Kubernetes-based platform that provides a higher level of abstraction and spans multiple clouds and on-premises IT environments, including edge computing platforms. As IT environments become more distributed, the need to rely on an external IT services provider to manage it only increases, Balakrishnan says. A common layer of abstraction will also make it easier for IT organizations to shift workloads from one cloud provider to another as business and technology considerations warrant.

Ultimately, organizations of all sizes will soon have to decide the degree to which they want to manage IT infrastructure themselves. In theory, the more they rely on an external service provider, the more internal resources they should be able to devote to new application development and deployment. Of course, there’s never been a shortage of managed service providers (MSPs). The thing that is changing most is that IT vendors are now providing these managed services themselves. Each IT organization that decides to rely more on an external service provider will need to decide if it makes sense to rely on a service provided by a vendor – that is optimized for that single vendor – versus relying on a third-party MSP capable of aggregating multiple services.

In the meantime, the rate at which cloud-native applications are being deployed across an extended enterprise is only going to increase as the overall global economy continues to steadily improve. The major IT issue of the day, now, is determining how best to achieve that goal in an era when the global economy has never been more dependent on software.

Prolifics, a global digital transformation leader is proud to announce that we now can help enterprises manage their applications across multiple cloud environments with IBM Cloud Satellite. IBM Cloud Satellite, now generally available, enables clients to run IBM Cloud services on any cloud, on premises, in multicloud environments or at the edge – all delivered as a service. This flexibility will help bring cloud capabilities to where client data resides, in the environment of their choice, while focusing on consistency, user experience, and security.

With its open architecture, IBM Cloud Satellite builds on IBM’s deep industry expertise and can help enterprises across a variety of industries including telecommunications, healthcare, banking, insurance, travel and transportation, transform into digital-first organizations. The need to modernize mission-critical workloads is intensifying. According to a recent IBM Institute for Business Value report, 74% of CEOs interviewed during the COVID-19 pandemic believe cloud computing will most help their organization deliver these results over the next 2-3 years. We see a cornerstone of this transformation is in edge computing. The continued proliferation of edge devices is expected to shift the amount of data that resides at the edge compared to within central data centers. As this transition takes place, IBM Cloud Satellite is designed to bring cloud services to where clients’ data already resides — and help them bridge to where they want to go.

Prolifics is part of IBM’s ecosystem of partners fueling hybrid cloud deployments by helping clients modernize applications and manage workloads on infrastructure ranging from bare-metal to multicloud and everything in between using Red Hat OpenShift, the industry’s leading enterprise Kubernetes platform. IBM Cloud Satellite is engineered to give clients the flexibility to bring their applications to environments where their data resides while leveraging the security of IBM Cloud.

Satya Bolli, Prolifics Chairman & Managing Director, said, “Modernizing applications to enable our clients to become faster, more agile, and more creative is what we do. Deciding the right platform for the right application workloads is a critical part of the equation. We see IBM Cloud Satellite as a game changer for our clients who want an enterprise grade option to bring the convenience of a cloud experience into the control of their own data center.”

Greg Hodgkinson, Prolifics Chief Technology Officer, said, “In the Prolifics Innovation Center, we’ve crafted more than 20 of our solutions using OpenShift and the Cloud Paks as our solution platform, ensuring flexible deployment models and simplified operations across cloud infrastructure. These solutions span verticals such as healthcare and banking, and horizontals such as data science, Hyperautomation, data privacy, DevOps and testing. IBM Cloud Satellite can help us deliver this solution platform as a service across an infrastructure of our client’s choosing, enabling us to roll out our solutions with Cloud Paks quicker and more efficiently. We believe this will improve availability to users, free-up capacity in our client’s operations team, and lower long-term cost of ownership.”

Since the COVID-19 virus outbreak in December 2019, the disease has spread to almost 100 countries around the globe with the World Health Organization declaring it a public health emergency. The global impacts of the coronavirus disease 2019 (COVID-19) are already starting to be felt, and will significantly affect the Cloud Computing Platform as a Service (PaaS) market in 2020.
COVID-19 can affect the global economy in three main ways: by directly affecting production and demand, by creating supply chain and market disruption, and by its financial impact on firms and financial markets.

The outbreak of COVID-19 has brought effects on many aspects, like flight cancellations; travel bans and quarantines; restaurants closed; all indoor events restricted; over forty countries state of emergency declared; massive slowing of the supply chain; stock market volatility; falling business confidence, growing panic among the population, and uncertainty about future.
This report also analyses the impact of Coronavirus COVID-19 on the Cloud Computing Platform as a Service (PaaS) industry.
Based on our recent survey, we have several different scenarios about the Cloud Computing Platform as a Service (PaaS) YoY growth rate for 2020. The probable scenario is expected to grow by a xx% in 2020 and the revenue will be xx in 2020 from US$ xx million in 2019. The market size of Cloud Computing Platform as a Service (PaaS) will reach xx in 2026, with a CAGR of xx% from 2020 to 2026.
With industry-standard accuracy in analysis and high data integrity, the report makes a brilliant attempt to unveil key opportunities available in the global Cloud Computing Platform as a Service (PaaS) market to help players in achieving a strong market position. Buyers of the report can access verified and reliable market forecasts, including those for the overall size of the global Cloud Computing Platform as a Service (PaaS) market in terms of revenue.
Players, stakeholders, and other participants in the global Cloud Computing Platform as a Service (PaaS) market will be able to gain the upper hand as they use the report as a powerful resource. For this version of the report, the segmental analysis focuses on revenue and forecast by each application segment in terms of revenue and forecast by each type segment in terms of revenue for the period 2015-2026.
Regional and Country-level Analysis
The report offers an exhaustive geographical analysis of the global Cloud Computing Platform as a Service (PaaS) market, covering important regions, viz, North America, Europe, China, Japan, Southeast Asia, India and Central & South America. It also covers key countries (regions), viz, U.S., Canada, Germany, France, U.K., Italy, Russia, China, Japan, South Korea, India, Australia, Taiwan, Indonesia, Thailand, Malaysia, Philippines, Vietnam, Mexico, Brazil, Turkey, Saudi Arabia, U.A.E, etc.
The report includes country-wise and region-wise market size for the period 2015-2026. It also includes market size and forecast by each application segment in terms of revenue for the period 2015-2026.
Competition Analysis
In the competitive analysis section of the report, leading as well as prominent players of the global Cloud Computing Platform as a Service (PaaS) market are broadly studied on the basis of key factors. The report offers comprehensive analysis and accurate statistics on revenue by the player for the period 2015-2020. It also offers detailed analysis supported by reliable statistics on price and revenue (global level) by player for the period 2015-2020.
On the whole, the report proves to be an effective tool that players can use to gain a competitive edge over their competitors and ensure lasting success in the global Cloud Computing Platform as a Service (PaaS) market. All of the findings, data, and information provided in the report are validated and revalidated with the help of trustworthy sources. The analysts who have authored the report took a unique and industry-best research and analysis approach for an in-depth study of the global Cloud Computing Platform as a Service (PaaS) market.

The following players are covered in this report:
Cloudflare
IBM Cloud
Oracle
Salesforce
Google
ServiceNow
Apache Stratos
Windows Azure
AWS
OpenShift
Plesk
Zoho Creator
Red Hat
VMware
SAP
Cloud Computing Platform as a Service (PaaS) Breakdown Data by Type
Video Communication Paas
Cloud Telephony Paas
Web and Mobile Optimization
Others
Cloud Computing Platform as a Service (PaaS) Breakdown Data by Application
Large Enterprises
SMEs

Red Hat, Inc., the world’s leading provider of open source solutions, and GitHub, the software collaboration platform home to more than 50 million developers, today announced extended collaboration between the two companies, emphasizing Red Hat OpenShift through GitHub Actions and more. Red Hat is adding Red Hat GitHub Actions to the GitHub Marketplace, bringing GitHub’s DevOps, continuous integration/continuous development (CI/CD) and developer workflow automation tools to Red Hat OpenShift. This further refines the application development capabilities of the world’s leading enterprise Kubernetes platform with GitHub Actions, adding greater freedom to how developers can build and deploy applications on Red Hat OpenShift across the open hybrid cloud.

GitHub has become nearly synonymous with developer tools and serves as the home for many popular software projects, including open source communities like the Linux kernel and Kubernetes. Using GitHub’s built-in powerful, flexible CI/CD solution, GitHub Actions puts automation directly in the developer path, making it possible for nearly any event in a GitHub repository, like a pull-request or issue comment, to trigger workflows that can build and deploy applications across an IT environment and automate nearly any process in the software lifecycle. Organizations often want to bring the familiar, collaborative experience of GitHub to their developers, as well as provide a more secure, common platform for working with open source communities. This makes the availability of tooling like Actions on enterprise Kubernetes platforms a crucial component for the future of IT.

Red Hat OpenShift now supports GitHub Actions, enabling organizations to standardize and scale their use of open, standardized developer toolchain components like Quay, Buildah, or Source-to-Image (s2i). This helps to meet developers where they are and provides greater choice and flexibility to OpenShift customers in how they build and deploy applications. The new GitHub Actions for Red Hat OpenShift, along with existing actions on GitHub Marketplace and action workflows, make it possible to achieve simple as well as complex application workflows on Red Hat’s enterprise Kubernetes platform using an extensive array of standards-based tools.

As part of the collaboration, GitHub has also joined OpenShift Commons, a community that helps drive connections and collaboration across the OpenShift ecosystem. Beyond Actions and GitHub Marketplace, Red Hat and GitHub are also exploring self-hosted GitHub runners for OpenShift. A runner is the combined application and server that hosts a job and carries out the steps for an Action workflow. Self-hosting runners gives IT teams more control and flexibility over the hardware and software included as part of their environment. This means that end users can increase memory size, enable GPUs, or install software that may only be available locally as part of a tailored application development experience.

The addition of GitHub Actions builds on Red Hat OpenShift’s robust developer experience, which includes OpenShift GitOps (based on ArgoCD) and OpenShift Pipelines (based on Tekton). OpenShift is now able to provide a complete solution for DevOps and GitOps practitioners as they seek to build, deploy, and maintain cloud-native applications.

Availability

GitHub Actions on Red Hat OpenShift are available now via GitHub Marketplace.

Supporting Quotes

Joe Fernandes, vice president, Products, Cloud Platforms, Red Hat

“Red Hat OpenShift is more than a Kubernetes platform for deploying cloud-native applications; it’s a powerful, flexible foundation for developers to build the latest and greatest applications. By adding GitHub Actions to our existing set of DevOps and GitOps capabilities and by working with GitHub to further refine and expand the developer experience, we aim to make Red Hat OpenShift the most complete cloud-native development platform available, one built on the open standards of Kubernetes and Linux containers and backed by the vast expertise of Red Hat.”

Jeremy Epling, vice president of Product Management, GitHub

“GitHub is the home for all developers, and we’re excited to expand our collaboration with Red Hat to accelerate software development within the enterprise. Combining Red Hat OpenShift with GitHub Actions will help our customers more securely automate nearly all their cloud-native development and DevOps workflows, providing a unified experience across the hybrid cloud that is exceptionally friendly to developers, security and operations teams. We’re looking forward to working more closely with Red Hat, and helping our customers deliver better and faster with open source software and standards.”

IBM has made available Quick Start for IBM Cloud Pak for Integration based on the Red Hat OpenShift platform on the Amazon Web Services (AWS) cloud.

Savio Rodrigues, vice president for integration and application platform offering management for IBM, says the Quick Start capability that IBM added to its Cloud Pak for Integration offering makes it easier possible to deploy IBM middleware encapsulated in containers on the AWS cloud.

Announced at the ongoing online AWS re:Invent conference, the Quick Start capability that IBM created is already available for IBM Cloud, with support for other clouds such as Microsoft Azure planned. Quick Start gives IT teams a set of best practices for deploying a set of IBM middleware that spans everything from application programming interface (API) integration and application data integration to messaging, event-driven publish/subscribe tools and file-transfer capabilities.

Rodrigues says it’s now apparent cloud computing is by definition hybrid. As such, IT teams will need a federated approach to integration that leverages the same middleware running on multiple clouds.

At the foundation of the IBM middleware strategy is an instanced of Red Hat OpenShift based on Kubernetes that can be deployed anywhere. IT organizations need platforms such as IBM Cloud Pak for Integration to better manage all the microservices that make up a cloud-native computing environment, he notes.

IT teams will also be able to more flexibly deploy a mix of applications constructed using microservices alongside legacy monolithic applications that can access the same middleware capabilities enabled by IBM, Rodrigues says.

In addition, IT teams will be able to flexibly manage varying service levels by controlling application traffic flows across between API endpoints, he says. As cloud-native applications become more distributed, Rodrigues notes that level of control will enable IT teams to meet service level agreements (SLAs) spanning different classes of cloud-native applications.

In addition, IT teams will be able to map dependencies between microservices more easily, he says.

IBM is positioning IBM Cloud Pak for Integration as a complement to the open source Istio service mesh it created in collaboration with Google and Lyft. IBM Cloud Pak for Integration will be able to, for example, invoke Istio as a security gateway that validates whether a specific microservice should be trusted, says Rodrigues.

Over time, he notes, IBM also plans to apply machine learning algorithms and other forms of artificial intelligence to make it easier to manage increasingly complex IT environments consisting of hundreds, possibly even thousands, of microservices.

IBM is not the only provider of integration software that views the rise of microservices based on containers as a major new opportunity. However, the company is fairly far down the path toward making integration software available that runs natively on Kubernetes clusters.

It may take some time for the bulk of organizations to deploy the number of microservices that would justify an investment in IBM Cloud Pak for Integration. However, it’s now more a question of when that middleware will be needed rather than if.

In addition, LogDNA has expanded an existing alliance to IBM to add support for instance of Red Hat OpenShift running on VMware platforms hosted on the IBM Cloud, which enables IT teams to centralize log management using LogDNA and IBM Log Analysis.

Chris Nguyen, chief strategy officer for LogDNA, said the goal is to continue to establish partnerships that will enable DevOps teams to manage larger swaths of the IT environment via a single pane of glass.

Vercel has been gaining traction as a provider of an open source reactive programming framework that is being employed to build more interactive front ends for web and mobile applications.

LaunchDarkly is a feature management platform that serves more than 6 trillion feature flags a day spanning 14 million mobile devices and 3 million servers. The integration between LogDNA and LaunchDarkly enables developers to rapidly iterate on feature flags using logging data surfaced by LogDNA.

Nguyen said that as IT environments continue to become more complex, more organizations are relying on log analytics to reduce the noise level being created by all the tools and platforms that make up a modern IT environment. The challenge IT organizations face is most of them can’t find or retain a site reliability engineer (SRE), so they need tools that enable developers to make better-informed decisions.

LogDNA is making the case for a log management platform deployable in the cloud or on-premises, designed for DevOps teams as an alternative to existing log management platforms that were designed for IT administrators who rely on graphical tools. LogDNA instead provides developers access to log analytics that are accessed via command-line interfaces (CLIs) and REST application programming interfaces (APIs).

It’s not clear whether or how much IT organizations may be willing to replace legacy log management platforms. However, as more organizations embrace best DevOps practices that include observability as a core tenet, LogDNA is betting those organizations will prefer an approach to log management aimed at developers rather than IT operations staff.

As DevOps teams assume more responsibility for the management of IT on an end-to-end basis, a seismic shift in IT tooling is underway. Providers of legacy IT tools are quickly shifting toward making APIs and CLIs available in response to a range of startups that are making available tools designed from the ground up to appeal more to DevOps teams. It’s too early to say how this battle for control over observability will play out, but the number of providers of tools for DevOps teams has never been greater.

In the meantime, many DevOps teams are still sorting out when best to employ log analytics, metrics and distributed tracing to optimize IT environments. The challenge these days isn’t so much being able to discover what’s occurring in an IT environment as much as it is making sense of it all.

Operations support systems (OSS) and business support systems (BSS) are being rewritten or refactored to cloud-native, microservices-based applications capable of running on hybrid cloud and multicloud computing and storage infrastructure. As a part of its transition, Amdocs created Microservices360 (MS360), an end-to-end carrier-grade accelerated microservices development platform for its own new generation of products, called CES 20. CSPs can use it for co-development with Amdocs or their own development purposes, as it provides a full SDK for cloud-native code development and deployment. MS360 leverages the Red Hat OpenShift container platform deployable solution architecture to optimally run on carrier-grade Intel computing and storage technology.

Introduction

This article provides a summary of the webinar, jointly sponsored by Red Hat and Intel, titled “Realize your OSS/BSS modernization vision today: Accelerating microservices development.” We describe the current movement of OSS/BSS to a hybrid cloud infrastructure and describe how one leading vendor, Amdocs, maximized use of the Red Hat solution for OSS and BSS modernization. This solution for OSS and BSS, as well as containerized network functions (CNFs), runs optimally on CSP-tuned computing and storage technology by Intel.

OSS/BSS in the Clouds

Cloud-native software technology was created by the web-scale players using modern Service Oriented Architecture (SOA), DevOps development methodology, and Continuous Integration/Continuous Deployment (CI/CD) implementation techniques. These techniques were embodied in tool sets released to the open source community and represent the current state of the art in software. Vendors and CSPs have been executing pilot programs with these technologies and have proved them out for telecommunications use cases. They are now moving OSS and BSS systems to cloud native architecture through a combination of re-coding and refactoring.

Amdocs MS360: A Comprehensive Development Platform

As Amdocs prepared to move its products to cloud technology, creating the CES 20 cloud-native OSS/BSS suite, it decided to create an accelerated development platform for containerized microservices for its own use leveraging best practices and incorporating open source tools. Amdocs MS360 was the result. It provides an environment with intrinsic security for developers to use from design to deployment of their containerized or virtualized microservices on hybrid cloud infrastructures.

Red Hat OSS/BSS Modernization Solutions

For service providers, OSS and BSS are fundamental and crucial to innovate and compete in quickly changing markets. It’s no longer only about billing and operating three or four core services. Now operators are competing in a platform-based economy where innovation is created through partner ecosystems. As digital service providers seek competitive advantage, they need an open and consistent OSS/BSS foundation to build differentiated services with speed, open to an ecosystem that maximizes choice. Red Hat helps service providers and independent software vendors (ISVs) build and run cloud native OSS/BSS solutions on premise and on any cloud with higher efficiency and flexibility.

Intel

While creating cloud native solutions can be a challenging task, Intel has a history of rising to support similar industry transitions and has already invested in 5G cloudification and network transformation efforts in partnership with Red Hat. Intel was the founder and lead contributor to the Data Plane Development Kit, which just experienced it’s 10-year publishing anniversary, making NFV adoption by Communication Service Providers (CoSPs) possible. Most recently, Red Hat and Intel released a new Reference Implementation, optimized for Cloud-Native Hybrid/Multi-cloud and built using Red Hat OpenShift Container Platform. It is designed to let CSPs and the industry eco-system quickly turn innovations into deployed VNFs/CNFs and transform OSS/BSS systems. This investment in thoroughly verified reference configurations provides a scalable, cost-efficient foundation to achieve deterministic performance for most demanding use cases as well as to lower design and integration risks.

Conclusion

The movement of CSPs’ OSS and BSS systems to the cloud and cloud-native technology is underway, helped strongly by companies such as Red Hat and Intel. Amdocs, a leading vendor, created its Microservices360 solution for its CES 20 BSS offerings, making maximum use of the Red Hat and Intel solutions for BSS and OSS modernization. CSPs can use this end-to-end carrier-grade accelerated microservices development environment for co-development and their own development purposes. The time is now for digital service providers to transition to cloud native OSS and BSS solutions to stay competitive, innovate and meet increasing customer expectations.

While it probably feels like you only started hearing the term DevOps in the past decade, it may already be time to start considering the next iteration of this trendy job title. With the complexity of IT automation increasing almost daily, some experts think DevOps could start shifting focus in the not too distant future, instead of centering their work on prioritizing which IT policies and procedures need to be automated.

Any way you slice it, DevOps and those responsible for shepherding products from concept to finished work are and will remain a vital cog in the development pipeline for the foreseeable future. And with the training in The Complete DevOps Certifications Courses and Practice Tests Bundle ($39.99, 87 percent off from TNW Deals), you can get the training and test-taking experience to be a fully-certified DevOps pro.

This package includes 12 courses stuffed with almost 60 hours of video instruction and a whopping 300 practice tests, each aimed at getting you ready to sit for and pass key DevOps certification exams to prove your mastery in this competitive field.

The training starts with an exploration of the most critical DevOps tools, such as using Git and GitHub to track changes in code and head off problems that are bound to happen when several programmers have their fingers in the mix.

As previously alluded, automation is also a huge piece of the DevOps trade, which is why coursework exploring automation tools like Jenkins, Ansible and Puppet is also so critical to shaving hours, days, and weeks of the development process.

Along with automation, the process of containerization, which allows developers to try out apps in a safe space in a program without impacting everything around it, is also vital. That’s why nearly half of the 12-course collection drills deep into how containerization works. With courses covering Docker, Kubernetes and OpenShift, you’ll see how these three independent, yet intrinsically linked platforms can make the final product a stronger, faster and smarter piece of software.

The training closes with an exploration of Dialogflow and its role in the development of chatbots, natural language, machine learning and other DevOps-related work.

And all of these courses are accompanied by dozens and dozens and dozens of practice questions and full tests, helping users get ready to pass all the necessary DevOps certification tests.

RALEIGH, N.C.–(BUSINESS WIRE)–Red Hat, Inc., the world’s leading provider of open source solutions, today announced several upgrades to its enterprise automation platform, including the latest version of Red Hat Ansible Automation Platform with new Red Hat Certified Ansible Content Collections, automation services catalog and private Automation Hub.

With dynamic global challenges requiring rapid adjustments in operational domains and environments, automation projects have helped mitigate the complexity that these conditions produced and provides faster responses to changing business requirements. Bringing together teams for improved collaboration, these new services and offerings ultimately connect business managers with automation leaders to better align automation strategies with the needs of the business and expand how automation can be invoked.

In a related announcement, Red Hat previewed an integration between Red Hat Advanced Cluster Management and Ansible Automation Platform, bridging the divide between traditional IT environments and cloud native, container-based solutions. This integration unites two of Red Hat’s industry-leading platforms, Red Hat OpenShift and Ansible Automation Platform, to drive automation across the open hybrid cloud.

Additional Certified Content Collections: in-demand automation code made more readily available

Introduced in 2019, Ansible Content Collections provide a standardized method for automation developers to build and package automation content, and for implementers to consume them in a portable and scalable way. Ansible Content Collections bring guardrails and structure to automation content, packaging Collections into categories based on automation domain or platform. Collections delivered in Ansible Automation Hub are certified by the Ansible partner network and are tested, validated and fully supported for enterprise-class production environments.

The newest version of Ansible Automation Platform is slated to include newly certified Ansible Content Collections for Red Hat OpenShift, Kubernetes Core and VMware vSphere REST API. These Collections showcase Red Hat’s continued commitment to automating cloud and Kubernetes platforms for modern IT. Hybrid cloud use cases have pressed forward, whether it’s utilizing native Kubernetes or Red Hat OpenShift, these Certified Content Collections enable automation for various container management systems.

With the addition of these new Collections, there are now more than 60 Ansible Content Collections available from Red Hat and its partners in Automation Hub; you can view a full list of supported and certified Ansible Content Collections.

Building internal automation content communities with private Automation Hub

Ansible Automation Hub is a managed cloud service to provide easy access to certified Ansible content for customers, maintained by Red Hat and our partners. As automation efforts expand across organizations, individual teams often look to integrate automation as part of their overall IT strategy, while IT leaders want the ability to ensure security and manageability of unsupported content. Private Automation Hub delivers a central location for internal automation communities to manage and curate their Ansible content privately, using trusted content from Red Hat, its partners and internal developers.

Private Automation Hub enables content creators as part of enterprises to collaborate and publish trusted, verified resources from a single source, helping to streamline Ansible code within an organization and create a knowledge guide for automation newcomers. More advanced teams can still use this content as a basis for automation, while the organization as a whole gains the ability to manage and control the lifecycle of Ansible automation content as needs scale across the hybrid cloud.

Driving customized automation for the open hybrid cloud

Announced at Red Hat Summit 2020, the automation services catalog makes enterprise-specific, pre-approved, curated automation available to infrastructure and application teams, as well as to business users. This capability helps provide IT administrators and security operations teams with greater visibility over what is being automated while not slowing down organization-wide automation practices. With the addition of the connector technology in the automation services catalog, customers can now bring the automation services catalog directly and more securely to their own private infrastructure, enhancing control over what automation practices are being used.

The connector technology also enables organizations to maintain business-specific controls and compliance mechanisms, while developers can still access the information they need, faster. New integrations for Information Technology Service Management (ITSM) also extends the automation services catalog to platforms like BMC Remedy and ServiceNow, reducing friction in proactively completing ITSM rulesets and standards tasks. This can help drive greater efficiency for teams that are seeking to make Ansible automation a key part of their overall business strategy and not simply a siloed IT component.

Automation as an enterprise imperative

Red Hat acquired Ansible in 2015, and since then, the world of IT has changed.

Organizations now understand that automation can provide faster responses to changing business requirements, and provides the capability to automate more aspects of a business as a driver for future plans. According to a 2020 Forrester report commissioned by Red Hat, automation is a necessity; three out of five respondents reported automation as one of their firms’ top initiatives, even amid competing priorities like adoption of cloud, containers and security management. This imperative for automation has fueled momentum around Ansible, making it a leader in infrastructure automation platforms today:

More than 87% of U.S. executive departments and 83% of airlines in the Fortune 500 use Ansible Automation Platform
Organizations across industries are running Ansible Automation Platform to manage global operations, freeing up IT teams to focus on digital transformation and business-level innovations.
IT automation knowledge is now frequently cited amongst the most in-demand job skills.
Ansible Automation Platform enables customers to move away from do-it-yourself, siloed approaches and to improve ROI. These customers are automating millions of nodes with Ansible as part of a modernization of management approach.

Availability

The latest version of Red Hat Ansible Automation Platform is slated for November release, including private Automation Hub on-premise or in the cloud of your choice. The connector technology in the automation services catalog will also be available next month for technology preview. The new Ansible Content Collections are available now on cloud.redhat.com, with additional Collections released on a rolling basis.

Supporting Quotes

Joe Fitzgerald, vice president, Management, Red Hat
“Ansible has evolved into a defacto standard for automation and became one of the top 10 open source projects in the world, according to a most recent study. Red Hat has built an automation platform for enterprises to more easily access, consume and share Ansible content to significantly reduce the time-to-automation. As customers continue down the path of digital transformation, these pre-integrated resources can address common use cases while advancing the management and innovation of traditional and cloud-native infrastructure.”

On its surface, DevOps seems like a simple idea. It’s the place where product development syncs up with operations to hopefully coalesce into a finished piece of software that’s been fully tested, vetted and optimized to perfection.

Of course, there’s a lot more than a simple straight line carrying a major project like that from ideation all the way through to completion. There are a lot of procedures and tools that help make that journey possible — and the well-trained, impactful DevOps pro has to know ’em all.

You can take the first steps toward understanding how to plan, then execute these projects as well as manage software developers and IT pros working together with the comprehensive training in The Complete DevOps Certifications Courses and Practice Tests Bundle.

This collection brings together 12 different courses packed with nearly 60 hours of video content and an avalanche of more than 300 different practice tests to help students earn DevOps certifications and become knowledgeable IT systems and network professionals.

These courses can help walk you through some of the most important tools a DevOps pro uses, including how source code changes are tracked with Git and GitHub. Inside builds, engineers need to automate processes so they aren’t writing all that code themselves, which is where a knowledge of automation tools like Jenkins, Ansible and Puppet can save countless hours of work.

Meanwhile, much of the DevOps process keys on containerization, which allows developers to each create their own isolated apps in a self-contained space in the program, yet all accessing and running off the same operating system.

A solid half of this collection focuses on the containerization process, including three different, yet intertwined methods of executing those projects. From a pair of courses on using Docker, to three mastering the more specific Kubernetes to two more on OpenShift, a platform for troubleshooting and optimizing Docker and Kubernetes projects.

Finally, there’s also a course in understanding Dialogflow and how it can be used to in the development of chatbots, natural language, machine learning and more automation tools and tricks.

Meanwhile, all this training is backed with dozens upon dozens of practice tests aimed at getting students ready to take and pass key DevOps certification exams.

It’s getting harder to keep track of “Git”-branded DevOps startups with ties to the Microsoft-owned GitHub open source software mothership.

Among the latest is Gitpod, which announced native integration with GitLab, the open-source DevOps platform. Gitpod also last week disclosed a seed funding round as it seeks to flesh out the expanding DevOps pipeline.

Along with GitHub Enterprise and GitLab, the cloud-focused developer also links via a browser extension to the Bitbucket, the web-based version control repository hosting service owned by Atlassian (NASDAQ: TEAM).

Gitpod said its native integration with GitLab’s user interface represents “the last missing piece” in the latter’s DevOps pipeline used by more than 100,000 organizations.

“Until now GitLab users would set up and maintain a single [development] environment on their local machines,” the Germany-based company said in a blog post. “It’s time to free engineers from wasting their time with such tedious tasks and apply the lessons learned from [continuous integration/continuous delivery] and infrastructure as code to dev environments.”

The next step is building an automated Gitpod configuration for GitLab’s source code, the company said, adding that the DevOps integration is now live on GitLab and will be part of a version update released scheduled for Oct. 22.

San Francisco-based GitLab, which offers a DevOps platform as a single application, currently has more than 175 partners integrating with cloud platforms, the Kubernetes cluster orchestrator and legacy DevOps workflows. The partner ecosystem includes Red Hat’s OpenShift container platform and VMware’s Tanzu application service.

Meanwhile, Gitpod announced a $3 million seed founding round spearheaded by Speedinvest along with Crane Venture Partners and Vertex Ventures.

“Gitpod’s first mover advantage and vibrant open source community enables developers today to treat development environments as automated, yet customizable, resources they can spin up whenever they need them and close down and forget about them when they are done with their task,” said Sven Efftinge, Gitpod’s co-founder and CEO.

It’s getting harder to keep track of “Git”-branded DevOps startups with ties to the Microsoft-owned GitHub open source software mothership.

Among the latest is Gitpod, which announced native integration with GitLab, the open-source DevOps platform. Gitpod also last week disclosed a seed funding round as it seeks to flesh out the expanding DevOps pipeline.

Along with GitHub Enterprise and GitLab, the cloud-focused developer also links via a browser extension to the Bitbucket, the web-based version control repository hosting service owned by Atlassian (NASDAQ: TEAM).

Gitpod said its native integration with GitLab’s user interface represents “the last missing piece” in the latter’s DevOps pipeline used by more than 100,000 organizations.

“Until now GitLab users would set up and maintain a single [development] environment on their local machines,” the Germany-based company said in a blog post. “It’s time to free engineers from wasting their time with such tedious tasks and apply the lessons learned from [continuous integration/continuous delivery] and infrastructure as code to dev environments.”

The next step is building an automated Gitpod configuration for GitLab’s source code, the company said, adding that the DevOps integration is now live on GitLab and will be part of a version update released scheduled for Oct. 22.

San Francisco-based GitLab, which offers a DevOps platform as a single application, currently has more than 175 partners integrating with cloud platforms, the Kubernetes cluster orchestrator and legacy DevOps workflows. The partner ecosystem includes Red Hat’s OpenShift container platform and VMware’s Tanzu application service.

Meanwhile, Gitpod announced a $3 million seed founding round spearheaded by Speedinvest along with Crane Venture Partners and Vertex Ventures.

“Gitpod’s first mover advantage and vibrant open source community enables developers today to treat development environments as automated, yet customizable, resources they can spin up whenever they need them and close down and forget about them when they are done with their task,” said Sven Efftinge, Gitpod’s co-founder and CEO.

Overview

Kubernetes launched as an open source project in 2014, and while the core architecture is well understood, the ecosystem surrounding it has shifted dramatically. Over a relatively short period, the market has consolidated around large software vendors, new tools have extended Kubernetes to virtual machines and multi-cloud environments, and management of multiple clusters has become the norm rather than the exception. This article examines each of those shifts in detail.

1. The Kubernetes Market Is Consolidating

The most visible trend in the Kubernetes space is consolidation around large, established software vendors. A few significant acquisitions illustrate the pattern clearly.

SUSE Acquires Rancher

In July 2020, SUSE acquired Rancher Labs, a company focused on Kubernetes management software. The deal gave SUSE — a well-established open source vendor with historically limited exposure to the container ecosystem — a competitive position alongside companies like Canonical and Red Hat, both of which had already invested heavily in Kubernetes tooling and platforms.

IBM, Red Hat, and OpenShift

IBM’s acquisition of Red Hat placed OpenShift — one of the most widely deployed Kubernetes-based application platforms — under the ownership of one of the world’s largest enterprise technology companies. Prior to the IBM deal, Red Hat had also acquired CoreOS in 2018, absorbing another early and influential player in the Kubernetes space.

Managed Kubernetes on Public Cloud

Managed Kubernetes services from major cloud providers — including Azure Kubernetes Service (AKS) from Microsoft and Elastic Kubernetes Service (EKS) from Amazon — have matured considerably. These services abstract away much of the operational overhead of running a Kubernetes control plane, making Kubernetes more accessible to teams without deep infrastructure expertise.

The net result is that deploying Kubernetes today most commonly means using a platform owned and operated by a large technology company. Independent vendors such as Platform9 still serve organizations that need more flexibility across heterogeneous infrastructure, but the general trend points toward corporatization of the Kubernetes stack.

2. VMware Enters the Kubernetes Architecture Space

For most of Kubernetes’ history, VMware and Kubernetes occupied separate corners of the IT landscape — virtualization on one side, container orchestration on the other. That separation has narrowed significantly.

Project Pacific and VMware Tanzu

VMware launched Project Pacific and the Tanzu portfolio to address both container and virtual machine workloads through a unified management framework. The strategic logic is sound: not every workload can be containerized, and organizations running mixed environments benefit from a single operational model for both VMs and containers.

The open source project KubeVirt pursues a similar goal in a vendor-agnostic way, allowing virtual machine workloads to run inside Kubernetes clusters alongside container workloads.

VMware’s Kubernetes strategy is most likely to succeed within its existing customer base — organizations already deeply invested in VMware’s virtualization stack. Whether VMware can attract net-new Kubernetes adopters who have no prior VMware investment is a more open question.

3. Kubernetes Goes Multi-Cluster and Multi-Cloud

Early Kubernetes deployments assumed a single cluster per environment. Kubernetes namespaces provided a way to segment workloads within that cluster — useful for resource isolation, access control, and organizational separation, but not providing the full isolation that distinct clusters offer.

Multi-Cluster Management

Tools like Rancher and VMware Tanzu Mission Control have made managing fleets of Kubernetes clusters a central capability. Teams can now run each application or tenant in its own dedicated cluster, providing strong isolation guarantees without relying solely on namespace-level separation. This is particularly valuable for security-sensitive workloads or environments with strict compliance requirements.

Multi-Cloud and Hybrid Cloud with Anthos

Google introduced Anthos in 2019 as a platform that uses Kubernetes as an abstraction layer across multiple underlying environments — public clouds, on-premises data centers, or both. Anthos allows teams to define, deploy, and manage applications consistently regardless of where the underlying infrastructure lives. This positions Kubernetes not just as a container orchestrator, but as a control plane for hybrid and multi-cloud strategy.

The practical implication: modern Kubernetes architecture is designed around the assumption that you will run many clusters, across many environments, and need unified tooling to manage them all.

4. Google Continues to Dominate Kubernetes Development

Kubernetes originated from an internal Google project called Borg. Even six-plus years after Google open-sourced Kubernetes and donated it to the Cloud Native Computing Foundation (CNCF), Google remains by far the largest contributor to the core project.

This is notable given the breadth of the Kubernetes ecosystem. Red Hat and IBM together represent a distant second in terms of core contribution volume. Major cloud providers such as Amazon, despite running large commercial Kubernetes services, have historically ranked outside the top contributors to the upstream project. This asymmetry reflects a broader pattern: companies that have built managed services on top of Kubernetes often invest more in their own control-plane abstractions than in the upstream codebase itself.

What This Means for DevOps Teams

For engineers evaluating or operating Kubernetes environments, several practical points emerge from these trends:

• Vendor lock-in risk is real but manageable. Managed Kubernetes services reduce operational overhead but may introduce dependency on provider-specific APIs and tooling. Evaluate the exit cost before committing.
• Multi-cluster is now the default assumption. Design your CI/CD pipelines, RBAC policies, and networking with multi-cluster topologies in mind, even if you start with a single cluster.
• Hybrid cloud use cases are expanding. If your organization operates on-premises infrastructure alongside public cloud, tools like Anthos, Rancher, and similar platforms offer a route to a consistent operational model.
• VM-to-container migration has vendor-supported paths. If you have a significant VMware estate, Tanzu and KubeVirt provide gradual migration options rather than requiring a full rewrite to containerize every workload.
• Upstream contributions signal long-term influence. Google’s continued dominance in Kubernetes development means the project’s direction is heavily influenced by Google’s own product roadmap priorities.

Looking Ahead

Further consolidation in the Kubernetes vendor landscape seems likely. The remaining independent Kubernetes management vendors face pressure from well-resourced platform companies offering bundled solutions. Meanwhile, Kubernetes itself is expected to play an increasingly central role in hybrid cloud strategies, with more vendors likely to invest in Anthos-style abstraction platforms over time.

As Kubernetes matures, it is becoming less a disruptive technology and more a foundational layer of modern infrastructure — present in solutions stacks almost by default. For DevOps engineers, that means deeper familiarity with Kubernetes is increasingly a baseline skill rather than a specialization.

Why Kubernetes Sprawl Happens

Kubernetes is the dominant open source container orchestration platform. It lets teams package workloads into containers, schedule them across nodes, and manage their lifecycle at scale. Because the software carries no licensing cost, individual teams and business units install it independently—on AWS, on Azure, on on-premises hardware, or on bare metal—often without informing central IT. The result is an uncoordinated proliferation of clusters, configurations, and tooling choices across the enterprise.

Three Core Problems Created by Uncontrolled Kubernetes

1. Security Vulnerabilities from Configuration Errors

Misconfiguration is consistently cited as a leading security risk in Kubernetes environments. When clusters proliferate without central oversight, each team applies its own (often incomplete) security settings. Role-based access control (RBAC) policies, network policies, pod security standards, and secrets management are all configured differently—or skipped entirely. The more uncontrolled instances you have, the higher the probability that at least one will be seriously misconfigured.

2. Hidden and Escalating Costs

The Kubernetes software itself is free, but the infrastructure it runs on is not. Cloud-hosted clusters incur compute, storage, and networking charges from the cloud provider. On-premises clusters require hardware, power, and operations staff. Without central visibility, these costs accumulate in silos, making it nearly impossible to optimize or even accurately report total Kubernetes spending across the organization.

3. Inconsistency Across Teams and Platforms

Kubernetes is intentionally flexible about the tooling stacked on top of it—networking plugins (CNI), storage drivers (CSI), operators, service meshes, and monitoring agents are all choices left to the operator. In practice, different teams pick different vendors. One group uses one CNI plugin; another uses a competing storage driver. Applications can develop implicit dependencies on these vendor-specific behaviors, making it risky to change or standardize later. The operational outcome is an enterprise-wide patchwork of incompatible stacks that no single team fully understands.

Accept Four Realities Before Trying to Regain Control

Regaining control does not mean preventing teams from using Kubernetes. It means creating visibility and governance while still giving teams the flexibility they need. Before any governance initiative can succeed, leadership must honestly accept the following realities:

• Reality 1 – You will manage multiple Kubernetes versions. Different teams will legitimately need different versions of Kubernetes running concurrently. Forcing a single version on everyone is impractical and likely to slow delivery.
• Reality 2 – You will manage Kubernetes across multiple platforms. Some groups will run workloads in public cloud environments (AWS, Azure, GCP); others will run them in private datacenters. A governance model that only covers one platform will fail.
• Reality 3 – Versions must be upgradeable independently. Upgrading all clusters in lockstep is rarely feasible. Each cluster or group of clusters must be upgradeable on its own schedule without disrupting others.
• Reality 4 – Data access must be consistent despite platform differences. Even across different versions, platforms, and vendor stacks, applications and users need a consistent, predictable way to access data. Inconsistent data access patterns multiply integration costs and reliability risks.

Attempting to govern Kubernetes while denying any of these realities wastes time and generates internal conflict. Acknowledge them first, then design governance around them.

Building a Kubernetes Control Plane for the Enterprise

In networking, a control plane is responsible for routing decisions and managing the state of the network, separate from the data plane that actually forwards packets. The same concept applies to enterprise Kubernetes governance: you need a management layer that provides visibility and policy enforcement across all clusters, regardless of where or how they run.

Building this control plane starts with discovery and structured questioning. You cannot govern what you cannot see. A practical starting checklist includes:

• Cluster inventory: How many Kubernetes clusters exist across the enterprise, and where are they running?
• Identity and access management: How is IAM enforced consistently across clusters from different vendors and on different platforms?
• Namespace and data fabric management: How is a consistent global namespace maintained for shared data across clusters in different geographies?
• Application security: How are applications secured when they span different Kubernetes versions and infrastructure types?
• Observability: How is logging and monitoring unified across dissimilar platforms and Kubernetes distributions so that operations teams have a single coherent view?
• Policy enforcement: How are network policies, pod security standards, and resource quotas applied uniformly, and who is responsible for auditing them?
• Upgrade planning: What is the process for tracking end-of-life Kubernetes versions and coordinating upgrades without breaking dependent applications?

This list is a starting point. A structured workshop between central IT and the business units that own clusters will surface additional gaps specific to your organization.

Practical Governance Approaches

Standardize on a Kubernetes Distribution Catalog

Rather than banning non-standard distributions, publish an approved catalog of distributions and versions. Teams pick from the catalog; central IT supports what is on it. This limits sprawl without blocking autonomy.

Enforce Policy Through GitOps

Tools such as Flux or Argo CD enable policy-as-code, storing cluster configuration in version-controlled repositories. Security policies, RBAC rules, and approved operators can be applied consistently to every cluster through a shared Git repository, making deviations visible and auditable.

Use a Multi-Cluster Management Layer

Several platforms—both commercial and open source—provide centralized dashboards and policy engines for fleets of Kubernetes clusters. These tools address the observability gap by aggregating cluster health, workload status, and policy compliance into a single view without requiring all clusters to run identical configurations.

Introduce Showback and Chargeback

Visibility into cost by team and cluster creates natural incentives for responsible resource use. Even before a formal chargeback model is in place, a showback report—showing each team what its clusters cost—tends to prompt self-governance.

The Goal: Enabling Speed Without Chaos

Shadow IT emerged because central IT was too slow. Kubernetes sprawl is emerging for the same reason. Governance frameworks that are too restrictive will simply push teams further underground. The objective is to make the governed path faster and easier than the ungoverned one: provide approved distributions, pre-configured security baselines, and self-service cluster provisioning through an internal platform. When teams can get a compliant cluster in minutes through official channels, there is little incentive to go rogue.

Stopping the Kubernetes food fight is not about authority—it is about providing a better alternative to chaos.

This article is an independent editorial expansion of a post originally sourced from cio.com (published 2020). The original post referenced HPE Ezmeral as a commercial solution; readers should evaluate current multi-cluster management offerings against their specific requirements.

Red Hat Brings Quarkus into the Red Hat Runtimes Subscription

Red Hat has added Quarkus — a Java framework purpose-built for Kubernetes — to its Red Hat Runtimes subscription portfolio. The move gives subscribers access to a cloud-native Java runtime alongside other supported runtimes, making it easier for enterprise development teams to adopt Quarkus when deploying Java applications on Kubernetes platforms such as Red Hat OpenShift.

According to Rich Sharples, Senior Director of Cloud Services at Red Hat, Quarkus deliberately removes layers of JVM code that were originally designed to provide cross-platform portability — a concern that Kubernetes itself now largely addresses through containerization and orchestration.

Why Traditional JVMs Are a Poor Fit for Kubernetes

The Java Virtual Machine was engineered decades before Kubernetes existed. Its design goals — write once, run anywhere — were met by abstracting away the underlying operating system. In a Kubernetes environment, that abstraction is already handled by the container runtime and the orchestration layer itself. As a result, a conventional JVM carries unnecessary overhead when deployed inside a container pod.

This overhead manifests in two important ways for Kubernetes workloads:

• Slow startup times: Traditional JVMs perform significant class-loading and JIT compilation at startup, making rapid pod scaling sluggish.
• High memory consumption: The JVM’s memory footprint is relatively large, reducing the density of workloads that can run on a given cluster node.

Quarkus addresses both issues directly, offering faster boot times and improved memory density compared to a legacy JVM deployment.

Key Technical Features of Quarkus

Kubernetes-Native Scaling

Because Quarkus is optimized for container environments, Java applications built with it can scale up and down more efficiently as Kubernetes reallocates cluster resources. This elasticity is critical for microservices workloads that must respond quickly to traffic spikes or resource constraints.

Extensive Extension Library

Quarkus ships with a library of more than 200 extensions, covering a broad range of enterprise Java standards and integrations. Notable examples include:

• RESTEasy — JAX-RS implementation for building REST APIs
• Hibernate ORM — object-relational mapping for database access
• Eclipse MicroProfile — enterprise Java APIs for microservices
• Red Hat AMQ Streams — Kafka-based event streaming
• Red Hat AMQ Broker — messaging middleware
• Red Hat Fuse — integration platform based on Apache Camel

Developer Productivity Features

Quarkus includes a live coding mode that reflects code changes immediately in a running application without requiring a full restart. Combined with unified configuration — a single configuration file covering all extensions — this significantly reduces the feedback loop during local development.

Reactive Programming Support

Quarkus exposes a Reactive programming model that simplifies the construction of complex distributed applications. This is particularly relevant for event-driven microservices that rely on asynchronous data streams, where a blocking I/O model would limit throughput and scalability.

Why This Matters for Enterprise Java Adoption on Kubernetes

Java remains one of the most widely deployed languages in enterprise environments, and organizations are not about to abandon years of Java expertise and existing application investments. However, for Kubernetes to achieve broad enterprise adoption, it must be able to run both new cloud-native Java applications and existing Java workloads efficiently.

By bundling Quarkus within the Red Hat Runtimes subscription, Red Hat lowers the barrier for development teams to evaluate and adopt a Kubernetes-optimized Java stack. Developers already using other runtimes in the subscription will encounter Quarkus as a first-class option rather than a separate evaluation project.

The Broader Context: Cloud Migration and Microservices

Enterprise organizations are under increasing pressure to move applications to the cloud in pursuit of greater flexibility and operational resilience. This trend is accelerating adoption of microservices architectures on Kubernetes clusters — and Java-based microservices remain a dominant choice in enterprise shops.

Many organizations will initially lift existing monolithic Java applications into the cloud with minimal changes. Once in a containerized environment, those applications often become candidates for incremental decomposition into microservices — a process that Quarkus is designed to support from the outset.

Red Hat’s inclusion of Quarkus in a subscription model reflects a broader bet that enterprises want to modernize Java workloads without abandoning the language — and that Kubernetes is the deployment platform where that modernization will happen.

Summary

For Java development teams evaluating Kubernetes-native runtimes, Quarkus — now available as part of Red Hat Runtimes — is worth considering as a path to modernizing both greenfield microservices and migrated enterprise Java applications.

Red Hat and AWS Expand Their Partnership with a Jointly Managed OpenShift Service

Red Hat has extended its strategic alliance with Amazon Web Services (AWS) to include a jointly managed Kubernetes service built on Red Hat OpenShift. Under the arrangement, AWS is responsible for managing the underlying public cloud infrastructure, while Red Hat takes ownership of a fully managed OpenShift control plane running on top of it. Billing flows through a customer’s existing AWS contract, removing the need to manage a separate Red Hat invoice.

Sathish Balakrishnan, then Vice President for Hosted Platforms at Red Hat, described the offering at the time of launch. He noted that Red Hat already had comparable jointly managed arrangements with Microsoft Azure and IBM, as well as a separately available product called Red Hat OpenShift Dedicated, which Red Hat deploys and manages on Google Cloud Platform (GCP) on behalf of customers.

Why Organizations Are Turning to Managed Kubernetes

The appeal of a managed OpenShift service reflects a broader industry shift in how enterprises consume Kubernetes. Several factors are driving this trend:

• Operational complexity. Kubernetes involves a significant operational surface area—cluster provisioning, networking, storage, upgrades, and security patching. Many organizations prefer to delegate that responsibility rather than absorb it internally.
• Talent scarcity. Skilled Kubernetes engineers remain difficult to hire and retain. A managed service lets teams consume the platform without needing deep in-house expertise from day one.
• Skills transfer. Some organizations use a managed service as a stepping stone: they consume OpenShift as a service while their internal teams learn the platform, with the option to take over management later.
• Resource constraints. At the time of the launch (mid-2020), the economic disruption caused by the COVID-19 pandemic had left many IT departments understaffed, accelerating interest in offloading platform management.

Red Hat’s Broader Managed Service Ecosystem

The AWS partnership sits within a much larger managed service ecosystem that Red Hat has built around OpenShift. At the time of the announcement, Red Hat already had relationships with more than 300 IT services providers that make OpenShift available as a managed offering. The strategy reflects Red Hat’s goal of making OpenShift available across every major public cloud and hybrid environment as the runtime fabric of a broad hybrid cloud computing strategy.

Customers can choose how they engage with the platform:

• Directly through Red Hat (OpenShift Dedicated or the relevant cloud-provider managed service)
• Through a hyperscaler such as AWS, Microsoft, or IBM under a jointly managed model
• Through a third-party IT services provider that wraps OpenShift in its own managed offering

DevOps Considerations for Managed OpenShift

One practical challenge that teams face when adopting any managed Kubernetes service is aligning their existing DevOps workflows to the constraints and opinions of the managed platform. OpenShift takes an opinionated stance on how applications are built and deployed—for example, it enforces stricter security contexts than vanilla Kubernetes by default. However, the platform does expose extension points that allow teams to integrate their preferred CI/CD tooling, policy engines, and observability stacks through plug-ins and Operators.

Engineering teams evaluating a managed OpenShift service should assess:

• Which cluster configuration options are exposed to tenants versus locked down by the managed provider
• How upgrade schedules are communicated and whether teams can defer patch windows
• How existing Helm charts, Operators, or custom controllers will behave under OpenShift’s security policies
• What observability and logging data is surfaced to tenants versus retained only by the provider

The Broader Kubernetes Adoption Curve

The launch of this service reflects a maturing Kubernetes market. Enterprises are increasingly treating Kubernetes not as a technology to evaluate, but as infrastructure to consume. The remaining open question—relevant to both managed service providers and platform teams—is what percentage of new workloads will be refactored into microservices architectures versus lifted and shifted as monoliths onto containerized infrastructure.

Microservices architectures are better suited to Kubernetes’s scheduling and scaling model, but they carry higher initial development and operational complexity. Organizations that move monolithic applications to containers gain portability and some operational consistency, but they may not realize the full flexibility benefits that a cloud-native architecture enables. Both paths are increasing the overall footprint of Kubernetes clusters in production—and, by extension, demand for managed services that absorb the operational overhead of running them.

Summary

Red Hat’s jointly managed OpenShift service with AWS gives enterprise teams a straightforward path to production-grade Kubernetes without staffing a dedicated platform engineering team. By consolidating billing through an existing AWS contract and distributing operational responsibility between the two vendors, the offering lowers the barrier to adopting OpenShift at scale. As managed Kubernetes services from multiple providers mature, the key differentiators will increasingly be operational transparency, upgrade control, and how well the platform integrates with a team’s existing DevOps toolchain.

Red Hat and AWS Deepen Their Partnership with a Managed Kubernetes Offering

Red Hat and Amazon Web Services (AWS) have extended their long-standing collaborative partnership to release Amazon Red Hat OpenShift, a jointly engineered, managed, and supported Kubernetes service delivered through AWS. The announcement, made in May 2020, targets enterprise organizations seeking to accelerate cloud-native application development without sacrificing security, compliance, or operational consistency.

What Is Amazon Red Hat OpenShift?

Amazon Red Hat OpenShift is a fully managed service built on Red Hat’s enterprise Kubernetes platform, OpenShift Container Platform. It brings together Red Hat’s container and Kubernetes expertise with AWS’s cloud infrastructure and services. The goal is to give IT teams a single, integrated experience for deploying and operating containerized workloads at scale on AWS.

Key operational features announced for the service include:

• Managed Red Hat OpenShift cluster creation and lifecycle management
• Native integration with the AWS Console for cluster visibility and control
• On-demand, hourly billing consolidated into a single AWS invoice
• Unified support through AWS, covering both the infrastructure and the OpenShift platform
• Native access to more than 170 AWS cloud-native services from within containerized applications

Why This Matters for Enterprise Kubernetes Adoption

One of the persistent friction points for enterprises adopting Kubernetes is the operational complexity of managing the platform alongside the underlying infrastructure. A jointly managed service removes much of that burden, allowing development and platform engineering teams to focus on application delivery rather than cluster administration.

Sathish Balakrishnan, Red Hat Vice President of Hosted Platforms, explained the rationale at launch:

“We often see IT decision-makers seeking prescriptive guidance around the changing requirements of IT operations and application development in a containerised world. By blending Red Hat’s and AWS’ decades of enterprise IT knowledge and experience into Amazon Red Hat OpenShift, IT organisations will be able to launch cloud-native systems that can retain enterprise-grade security, be more agile and see improved performance while driving cost efficiencies.”

Sathish Balakrishnan, VP of Hosted Platforms, Red Hat

Key Benefits for Enterprise Teams

According to Red Hat, the primary benefits of Amazon Red Hat OpenShift include:

• Enterprise-grade Kubernetes: Access to the same OpenShift platform used by more than 2,000 enterprise customers globally at the time of announcement.
• Deep AWS integration: Native connectivity to AWS managed services, enabling teams to build applications that leverage the full AWS portfolio without leaving the OpenShift environment.
• Hybrid cloud readiness: Consistent APIs and tooling across on-premises OpenShift deployments and the AWS-managed version, supporting hybrid cloud architectures.
• Open-source foundation: Built on upstream Kubernetes and Open Container Initiative (OCI) standards, avoiding proprietary lock-in at the platform layer.

Red Hat’s Stance on Enterprise Kubernetes Architecture

Balakrishnan was explicit about Red Hat’s architectural philosophy, pushing back against approaches that layer Kubernetes on top of legacy virtualization stacks or proprietary middleware:

“Contrary to some industry vendors, we do not see enterprise Kubernetes as being truly successful if it’s based on legacy virtualisation infrastructure or layered across proprietary technologies. Red Hat views the cloud-native platform for the enterprise as fully open and highly-scalable in a model that embraces upstream innovation safely for use in production.”

Sathish Balakrishnan, VP of Hosted Platforms, Red Hat

This positions Amazon Red Hat OpenShift as a direct counter to managed Kubernetes offerings that rely on hypervisor-based node isolation or vendor-specific control plane components.

Availability

At the time of the original announcement in May 2020, Amazon Red Hat OpenShift was entering an early access program. Interested organizations were directed to the Red Hat OpenShift website to register for preview access. For the current availability status and regional support, consult the official Red Hat OpenShift and AWS product pages, as the service has continued to evolve since this initial launch.

Watch: OpenShift on AWS Overview

Summary

Amazon Red Hat OpenShift represents a significant step in making enterprise Kubernetes accessible to organizations that want the power of OpenShift without the operational overhead of self-managing the platform. By combining Red Hat’s Kubernetes expertise with AWS’s infrastructure scale and managed service tooling, the offering addresses two of the most common enterprise objections to Kubernetes adoption: operational complexity and integration with existing cloud services. For DevOps and platform engineering teams evaluating managed Kubernetes options on AWS, it is a solution worth evaluating alongside Amazon EKS and other alternatives.

Amazon Red Hat OpenShift, merging the industry’s largest public cloud with its leading Kubernetes platform for hybrid deployments, comes integrated with native AWS services, and can be provisioned and billed through the AWS console.

Red Hat and Amazon Web Services have partnered to offer a jointly managed and supported version of Red Hat OpenShift on the industry’s largest public cloud.

Amazon Red Hat OpenShift, introduced Thursday, combines AWS-native capabilities with Red Hat’s leading Kubernetes platform—the central pillar of Red Hat’s, and parent IBM’s, strategy to achieve hybrid cloud supremacy with more than 2,000 customers.

The joint offering natively integrates with more than 170 AWS services, and is the first that allows enterprises to provision, license and bill for OpenShift through AWS, Sathish Balakrishnan, Red Hat’s vice president for Hosted Platforms, told CRN.
[Related: Sanjay Poonen On VMware Vs. Red Hat OpenShift: ‘May The Best Product Win’]

“Because it’s such a broad market, we want to give OpenShift in multiple forms,” Balakrishnan said. Offering a diversity of consumption models is important in realizing the promise of Kubernetes to extend across all types of infrastructure and environments.

Many customers tell Red Hat they’ve standardized on OpenShift as their hybrid platform, and now want to run it in multiple clouds. But they want Red Hat to make it easier to support deployments across those providers, he said.

The integrated AWS offering follows a similar partnership with Microsoft which yielded the introduction one year ago of Azure Red Hat OpenShift. Red Hat also offers Red Hat OpenShift on IBM Cloud, a fully managed offering n on its parent company’s infrastructure.

Previously, enterprises that wanted to run OpenShift on AWS could opt for Red Hat OpenShift Dedicated, a fully managed service from Red Hat available on AWS, as well as Google Cloud Platform. Or they could opt for OpenShift Container Platform, a version they could either self-install and self-manage, or implement through a systems integrator.

Amazon Red Hat OpenShift adds another option to that mix—one that doesn’t involve partners in the deployment phase of an engagement, but creates a different opportunity for the channel, Balakrishnan said.

“Partners have multiple roles to play in adoption of OpenShift,” Balakrishnan said.
While the two technology giants will handle standing up and managing the platform, he said, enterprises will turn to the channel to migrate workloads and refactor applications using containers and cloud-native architectures.

Balakrishnan, who has a consulting background with Accenture and Deloitte, said it’s those layers above infrastructure where partners see their healthiest profits.
And the joint offering will give partners without Kubernetes specialists and the resources to create container clusters a chance to play in that market by allowing them to focus exclusively on higher-order business priorities and applications, he said.
Amazon Red Hat OpenShift is a “complementary offering to the services GSIs provide in the world of Kubernetes and containers, where skills are scarce,” Balakrishnan told CRN.
With the new offering, enterprises for the first time will be able to provision OpenShift through the AWS console, apply existing AWS Enterprise Agreements, and be billed through a single AWS invoice. AWS and Red Hat will both provide technical support.

The offering can directly access AWS compute, storage, networking, database, analytics and machine- learning services

But the key value proposition for OpenShift—application portability and compatibility—remains the same, making it an easy switch from other OpenShift deployments on AWS or its rival clouds.
The partnership with Amazon demonstrates IBM is staying true to the pledge it made when it purchased Red Hat for $34 billion of maintaining the open-source software leader’s neutrality.

“It’s a great validation of IBM keeping its word on independence,” Balakrishnan said.

Windows Containers: More Than Just Docker

Microsoft’s container story on Windows is broader than most engineers realize. If you’re running Windows 10, you’re already using containers without necessarily knowing it: UWP (Universal Windows Platform) apps run inside lightweight app containers that sandbox them from the rest of the OS. Beyond that, developers can run both Windows and Linux Docker instances on the same machine, thanks to WSL2 and Docker Desktop.

Understanding the different container models — and when each applies — is essential for DevOps teams building hybrid-cloud or Windows-native workloads. Despite the surface complexity, Microsoft’s strategy follows a clear logic once you separate desktop isolation concerns from server-side orchestration concerns.

The Two Broad Use Cases for Windows Containers

• Desktop application isolation: Windows 10 uses container-like process isolation to sandbox apps installed via .appx or .msix packages. This happens automatically and is managed by the OS installer — developers and operators don’t need to configure it manually.
• Server and cloud workloads: Windows Server containers allow .NET applications, SQL Server, and other Windows-based services to be packaged, versioned, and deployed through standard DevOps CI/CD pipelines using Docker and Kubernetes tooling.

The desktop side is largely transparent to operators. The server side is where DevOps teams need to make deliberate architectural decisions.

Windows Containers vs. Linux Containers on Windows

Windows 10 Pro and Enterprise can run Docker containers in two flavors:

• Windows containers: Use the Windows kernel. Images are Windows-based and cannot run on a Linux host without emulation.
• Linux containers via WSL2: Docker Desktop for Windows uses the WSL2 backend to run a real Linux kernel on Windows, enabling Linux container images to run natively without a full Linux VM overhead.

Docker Desktop abstracts the complexity of switching between these modes, making Windows 10 a viable development platform for both Windows and Linux containerized workloads. For teams building microservices that will ultimately run on Linux nodes in production, the WSL2-backed Linux container workflow on Windows provides a high-fidelity local development environment.

Windows Containers in Hybrid Cloud and Kubernetes

Windows containers are officially supported in Kubernetes, enabling organizations to run mixed Windows/Linux clusters. Both upstream Kubernetes and Red Hat OpenShift support Windows worker nodes alongside Linux worker nodes, managed from a single control plane.

Key architectural points for Kubernetes-based Windows container deployments:

• Windows containers run on Windows Server worker nodes, not on Linux nodes. There is no cross-OS kernel sharing; Windows containers require a Windows host.
• Windows Server licensing requirements mean each VM instance hosting Windows containers requires a valid Windows licence — a cost consideration when sizing your cluster.
• Tools such as Azure Kubernetes Service (AKS) and OpenShift automate workload scheduling across Linux and Windows nodes, handling placement transparently.
• Container images can be stored in the Azure Container Registry and pulled to Windows nodes using standard Kubernetes manifests.

For teams migrating legacy .NET or COM-based applications to a cloud-native architecture, lifting the application into a Windows Docker container and deploying it via Kubernetes is a practical intermediate step — you get CI/CD pipeline integration and horizontal scaling without requiring a full application rewrite.

Choosing an Isolation Mode: Process vs. Hyper-V

Windows Server containers offer two isolation modes. Choosing the right one depends primarily on your trust boundary requirements and hosting environment.

Process Isolation

Similar to the default Linux container model, process isolation runs multiple container images on a shared Windows kernel. Namespace isolation keeps containers separate from each other and from the host, but the kernel is shared.

• Pros: Lower overhead, faster startup, better density.
• Cons: Shared kernel means a kernel-level vulnerability could affect all containers on the host. Not recommended for multi-tenant scenarios.
• Best for: Controlled single-tenant environments where you know and trust all workloads running on the host.

Hyper-V Isolation

Hyper-V isolation wraps each container in a thin, optimized virtual machine with its own kernel instance, running on top of Hyper-V. This provides hardware-level isolation between containers.

• Pros: Strong isolation boundary; suitable for multi-tenant workloads; prevents information leakage between containers.
• Cons: Slightly higher resource overhead compared to process isolation.
• Best for: Public cloud deployments, multi-tenant container hosting, or any environment where workloads from different trust domains share the same host.

To run a container with Hyper-V isolation using Docker, pass the --isolation flag:

docker run --isolation=hyperv mcr.microsoft.com/windows/servercore:ltsc2019 cmd

Note that the default isolation mode differs by platform: Windows 10 desktop defaults to Hyper-V isolation, while Windows Server defaults to process isolation. If you require Hyper-V isolation on a Windows Server host, you must specify it explicitly.

Container Base Image Sizes: A Practical Consideration

One historical criticism of Windows containers has been the size of the base images. Microsoft has been actively reducing image sizes across Windows Server releases. As of the Windows Server 2004 release (circa 2020), the Windows Server Core base image was reported to be approximately 2.46 GB, down from nearly 5 GB in the Windows Server 1809 and 1903 releases.

Building on Windows Server Core rather than Nano Server is generally recommended for containerized .NET applications because Server Core exposes a larger API surface area, reducing the risk of application compatibility issues when lifting existing code into containers.

Tooling and Observability for Windows Containers

Microsoft has invested in open-source tooling to support Windows container operations, including logging utilities hosted on GitHub. Robust logging is especially important in Kubernetes-orchestrated environments where a single application may span dozens of containers across multiple nodes. Teams should evaluate their observability stack — log aggregation, metrics, and distributed tracing — before going to production with Windows container workloads.

Decision Guide: Which Windows Container Approach Is Right for You?

Summary

Windows containers are no longer a niche concern. With Kubernetes support, WSL2-backed Linux containers on Windows, and shrinking base image sizes, the toolchain has matured to the point where DevOps teams can treat Windows workloads with the same CI/CD discipline they apply to Linux services. The key decisions are straightforward: choose process isolation for trusted single-tenant hosts, Hyper-V isolation for multi-tenant or public cloud scenarios, and use standard Kubernetes tooling to manage mixed clusters. Desktop isolation is handled automatically and requires no operator intervention.

The Core Argument: PaaS as a Bridge, Not a Barrier

Red Hat has staked a strategic position on the idea that platform-as-a-service (PaaS) environments will become the primary mechanism through which IT operations teams expose a curated catalog of distributed services to developers—without losing governance or control.

Paul Cormier, then President of Products and Technologies at Red Hat, articulated the thesis: when developers lack access to sanctioned services, they route around IT operations entirely—downloading libraries and dependencies on their own. The result is a sprawling application estate of uncertain provenance, duplicated functionality, and hidden operational risk. A mature PaaS changes that dynamic by making approved services available through well-defined APIs, giving developers speed while giving operations teams visibility.

Why CIOs Are Paying Attention

According to Cormier, Red Hat was increasingly engaging CIOs and senior IT leaders—not just architects or platform engineers—in conversations about OpenShift. That shift in audience is significant. It signals that PaaS adoption is moving from a tactical, team-level decision to a strategic initiative aimed at resolving the historic tension between development velocity and operational stability.

The conversation is framed around a familiar DevOps pain point: developers throwing code “over the wall” to operations, followed by fire-fighting, blame, and slow delivery cycles. PaaS, in this framing, replaces the wall with an API.

OpenShift, Kubernetes, and the Blurring of PaaS vs. CaaS

One of the more consequential technical points Cormier made is that OpenShift’s adoption of Kubernetes as its orchestration layer effectively erases the traditional boundary between PaaS and container-as-a-service (CaaS). In practice, this means:

• Traditional 12-factor applications can run alongside newer, microservices-based workloads on the same platform.
• Deployment targets can span on-premises infrastructure and public cloud environments, with the choice driven by cost, data gravity, or regulatory requirements rather than platform limitations.
• Serverless computing frameworks can sit on top of this substrate, enabling event-driven workloads and cloud-bursting scenarios in heterogeneous hybrid cloud environments.

This convergence matters for teams evaluating platform strategy: rather than maintaining separate toolchains for PaaS and container workloads, a Kubernetes-native PaaS like OpenShift aims to consolidate them.

Mixing Internal and External Services in a Hybrid World

Cormier also pointed to a pattern already emerging in larger enterprises: selectively mixing internal platform capabilities with external cloud services based on performance characteristics. His example was AI/ML workloads—an organization might route a specific inference workload to a particular cloud provider because that provider’s AI service outperforms alternatives for that use case, while keeping other workloads on-premises.

This “best tool for the workload” posture requires a platform layer capable of brokering access to both internal and external services consistently—exactly the role Red Hat was positioning OpenShift to play.

The Goal Is Developer Focus, Not Operations Elimination

A common misreading of DevOps is that it aims to replace IT operations with developer self-service. Cormier pushed back on that interpretation. The goal, he argued, is to maximize the time developers spend building and testing applications—not to eliminate operations teams. PaaS enables this by abstracting infrastructure complexity, so developers are not blocked waiting for environments, and operations teams are not overwhelmed fielding ad-hoc infrastructure requests.

This distinction is important for organizations evaluating whether to invest in a PaaS: the platform does not make operations teams redundant; it reshapes their role from reactive ticket-handlers to curators of platform capabilities.

The Adoption Gap: Why PaaS Uptake Remained Uneven

Despite the strategic argument, Cormier acknowledged that most IT organizations in 2018 had only pockets of PaaS adoption. The majority of applications were still being built and deployed without any PaaS involvement. The most frequently cited reason: early PaaS platforms were perceived as too prescriptive—they imposed opinions on application structure, deployment workflow, and runtime choices that many teams were unwilling to accept.

Red Hat’s bet was that the rise of container-based, microservices architectures would change the calculation. Containers already impose a degree of standardization on how software is packaged and run. Given that foundation, organizations may find it easier to accept the additional conventions of a PaaS in exchange for significantly reduced infrastructure complexity.

Key Takeaways for DevOps Teams

• PaaS as governance layer: A mature PaaS can enforce approved service consumption without becoming a bottleneck, replacing informal workarounds with sanctioned APIs.
• Kubernetes convergence: The PaaS/CaaS distinction is increasingly academic on Kubernetes-native platforms. Evaluate platforms on workload breadth, not category label.
• Hybrid cloud brokering: Platform strategy should account for selectively routing workloads to internal or external services based on performance, cost, and compliance—not just lift-and-shift.
• Serverless integration: Event-driven serverless frameworks can extend a PaaS to cover burst and integration workloads without requiring separate infrastructure.
• Operations reshaping, not elimination: PaaS adoption changes the operations team’s mandate from infrastructure provisioning to platform product ownership.