First there was virtualization, but full operating system virtual machines were too heavyweight, so the industry created containers. The containers didn’t run on a server, so the industry created Kubernetes to manage the virtual machines in a cluster. That led to problems with managing the Kubernetes cluster, getting the cluster itself to be elastic, to grow and shrink on-demand. Now that Kubernetes supports Windows 2019 containers, it’s fair to ask “what’s next?”

Two tools are emerging to try to solve the problem in different ways. Red Hat’s OpenShift enables a team to manage to scale a cluster, while Istio provides more refined insight into what is going on inside the cluster.

SEE: Kubernetes security guide (free PDF) (TechRepublic)

Red Hat’s OpenShift

Red Hat’s cluster manager, which sits on top of Kubernetes, is not exactly new; yet, when the technology was first open sourced in 2012, Docker did not exist as a file format, and Kubernetes was not a cluster manager–that version of OpenShift was focused on managing rack servers. The basic problem it was trying to solve–of allowing applications to expand, contract, and move with demand automatically–was a sort of peanut butter and chocolate combination with Kubernetes.

In 2015, version 3 of the software incorporated Docker and Kubernetes. Version 4 was released in May of 2019, just about the time that IBM was closing its purchase of Red Hat. Then in January 2020, Jim Whitehurst, the former CEO of Red Hat, was promoted to President, the number two spot at IBM.

OpenShift includes a layer of health checks, including auto-adjustments, designed to simplify management, along with build and deployment tools, like built-in Jenkins Continuous Integration and a Kubernetes build operator. That makes building applications “cloud native,” where the natural result of the build is a container that can be checked into an artifact storage, tested, and security scanned before deployment.

As early as December 2018, Steven J. Vaughan-Nichols, a contributing editor to ZDNet, was suggesting Kubernetes as the solution to the hybrid cloud, but the technology wasn’t quite there yet. (ZDNet is a sister site of TechRepublic.) OpenShift can manage multiple Kubernetes clusters–some locally, some in the cloud, or even migrate between the two. The extent to which this can be done automatically is unclear.

Managing scale, clouds, and migrations is the macro view of managing containers; debugging them as they run is the micro view.


By default, Kubernetes pods send all their traffic to every other pod in the cluster; the tool also fails to add security.

Kubernetes does not have debugging tools. There is nothing like the “stack trace” programmers use to understand what line of code failed. Modern distributed applications send messages back and forth, from customer to webserver to database cache to webserver to microservices to the database and so on. If one of those messages fails, the customer will receive an error. That makes debugging critical, yet containers do not provide this out of the box.

Istio, a joint effort between Google and IBM, is designed to address these issues. Istio provides TLS encryption of all messages within a cluster and creates routing rules for messages. This has the side benefit of enabling A/B split tests, where members of a certain group are routed to a new beta web service living in the same cluster. Istio can record all web traffic, store it, publish it, and make it available as a dashboard for debugging.

By sending a message to a recording server for every message and running the recording and dashboard servers, Istio can increase the memory, CPU, and especially bandwidth footprint of your cloud service.

Do you need these container management tools?

With years of support on every major public cloud at the nearly native level, along with options for on-premise and a personal, free plan, OpenShift is clearly a consideration in the market. Istio is supported on the major cloud vendors on top of Kubernetes, but it does require a significant manual install. Jason McGee, CTO for the public cloud team at IBM, agreed with my own experience that without careful configuration, Istio can require a great deal of resources–at least at first.

If you are running a cloud service, don’t feel growth or service reliability pain, and coded your own security features, Istio and OpenShift may not be the place to start. If you are just starting a cloud-native approach, OpenShift is the place to store your containers, and experiment with Istio–perhaps on a dev or test cluster and load test it realistically before running it in production.

Image: 123dartist, Getty Images/iStockphoto