Is Kubernetes becoming the driving force of enterprise IT?

Now and again, enterprise technology comes along that seems like a beautifully simple solution to a complicated problem. Take Kubernetes—the open source platform that automates Linux container operations, eliminating many of the manual processes involved in deploying and scaling containerised applications. It is exciting to see how Kubernetes is evolving to meet the challenge of running mission critical workloads at scale.

Container use will only continue to increase. A recent Red Hat survey found that 62% of organisations have minimal (less than 10%) container use today, but only 20% say that will still be the case in two years’ time. Meanwhile, the percentage with more than half their workloads containerised is expected to almost triple—to 28%—over the same period.

Gone are the days when containers were purely seen as a new way of packaging applications, for infrastructure architects tasked with finding better ways to run applications and reduce virtual machine costs. Now, container platforms are recognised as enablers of innovation first, and infrastructure second. That’s why every CIO agenda should include a viable container platform and a way to orchestrate it.

What is Kubernetes?

Only a few years ago a technology battle emerged between different container orchestration platforms. Then Kubernetes hit the market. Once open sourced, Kubernetes became one of the fastest-growing open source projects. Nearly 8,000 developers attended Kubecon in Barcelona in 2019, making it one of the biggest open source conferences in Europe. Kubernetes has won the container orchestration space and the industry has converged on the technology: there are now over 90 certified Kubernetes offerings on the market.

When should you consider moving to Kubernetes?

Cloud-native computing is more popular than ever. You may have already moved your platform to the cloud — but now, as your business grows, you’re realising how hard it can be to coordinate and orchestrate your platform. This is especially true if it’s distributed across multiple services. Read here

As a vendor-agnostic cluster and container management tool, Kubernetes provides a platform for automating the deployment, scaling, and operations of application containers across clusters of hosts. In an era where hybrid is the predominant cloud strategy, Kubernetes clusters can span public, private, or hybrid clouds. For this reason, Kubernetes is an ideal platform for hosting cloud-native applications that require rapid scaling like real-time data streaming.

However, Kubernetes relies on other open source projects to fully realise its power.

What Kubernetes is not

An enterprise-class container platform should consist of several important tools beyond Kubernetes orchestration. These include registry, networking, storage, telemetry, automation, and services. These all rely upon metrics, logging, monitoring, ingress, authentication and authorisation, languages, frameworks, middleware, and databases and, not least, security. A business needs to think about security throughout the layers of the solution stack before deploying and running a container, and address the security of Kubernetes in an integrated and continuous way, mindful of where Kubernetes security ends and a business needs to strengthen it further.

So while installing Kubernetes and experimenting with it is viable for many, establishing it as a central platform to run business critical applications takes a lot more work. Anyone building their own container platform will have to vet, test and harden individual technologies throughout the stack. They’ll need to keep up with each component individually throughout its lifecycle, and make sure that they all work together. If there is an issue anywhere along the line, Kubernetes being an upstream open source project lacks a formalised support structure, so a business would need to work on a solution in that instance.

Maintaining and managing Kubernetes

Many organisations start out with a small Kubernetes install. When they want to scale out and start running mission critical workloads, they can find they have underestimated the complexity and overhead of integrating, testing, updating and managing various cloud-native components. This is when the mantra “there is no such thing as Vanilla Kubernetes” can become all too clear, as piece by piece you end up assembling a Frankenstein’s monster. Maintaining and managing this creation as it grows can become increasingly costly, particularly while digital skills are in high demand.

How to drive successful transformation through cloud native architectures

Michael Allen, VP and EMEA CTO at Dynatrace, explains the benefits that cloud-native architecture offers businesses, as well as giving advice on how companies can overcome the cost and time barriers involved with re-building applications from scratch. Read here

Channelling innovation

In a world where innovation and time to market is a top priority, Day One developers need to be able to efficiently provision infrastructure and get coding. Using a managed platform that provides ready access to everything needed to run containers and Kubernetes consistently across a hybrid environment (including support and security) means application and developer teams can spend more time solving business problems.

Many organisations will want their hybrid environment to include multiple public clouds. This means they need to be aware of how much flexibility and freedom they’ll want for using the technologies of their choice—including emerging innovations like Quarkus, which lets you build cloud-native applications; or Operators, a way of packaging Kubernetes-native applications for easier management. Ultimately, this means understanding the difference between an open platform and a proprietary one.

An example of this is Deutsche Bank, which established an open source-powered platform-as-a-service to standardise and streamline developer access to compute capacity and other application resources across its business. Deutsche Bank built Fabric, a containerised, microservices-based application development platform. Fabric provides faster resource access, helping developers work more efficiently, so now applications can go from proof of concept to production in 2-3 weeks instead of 6-9 months.

DevOps mobile app development: benefits and challenges

Olivia Diaz, technology observer at, discusses how DevOps has transformed mobile app development and the mobile industry as a whole. Read here

Meanwhile, Cathay Pacific embraced an enterprise-grade Kubernetes platform in an open hybrid-cloud environment. As well as gaining on-demand scalability and portability across private and public infrastructure, it increased collaboration between teams, creating more efficient and cost-effective work processes. The airline can now do 200 deployments per day, compared to one per week, and move applications without needing to rewrite them.

How is Kubernetes evolving?

In recent months, we have seen cloud-native technologies become easier to use and more accessible for developers, via capabilities that automate the set-up and management of Kubernetes environments. Developers can now focus on building the next-generation of enterprise applications without requiring in-depth Kubernetes expertise.

Today there are ready-to-use developer services that address needs around service mesh, serverless execution and cloud-native continuous integration/continuous delivery (CI/CD) pipelines, all of which are designed to help fuel developer productivity around Kubernetes-based applications.

When beginning the move to containers, it’s important to consider the bigger picture of how you’re going to run them in production over time. Ultimately, what do you want your teams to focus on? If the answer is building world-class services for customers and getting them to market faster than ever before, then Kubernetes would be a potent weapon in your armoury.

Written by Graham Berry, EMEA sales lead, OpenShift at Red Hat


Editor's Choice

Editor's Choice consists of the best articles written by third parties and selected by our editors. You can contact us at timothy.adler at