Kubernetes and Traffic Lights

By Published On: January 8, 2020

A few years ago, a major Chicago highway leading into downtown undertook a reconstruction. The public braced for the construction by planning alternative methods and routes to get to work. One of the alternative routes runs parallel to the highway. In preparation, the City of Chicago upgraded the traffic light orchestration system to dynamically control the traffic light system along this passage. The infrastructure improvement eased congestion along the alternative route. I don’t recall many if any people asking or debating on the orchestration system needed to improve traffic light efficiency. Everyone only cared about reducing traffic congestion.

My interface into the infrastructure the city built was the traffic lights. I received the benefit of reduced congestion in the form of faster travel times to get to work. Kubernetes is an enabling technology aimed at supporting faster application development. The only problem is Kubernetes isn’t an invisible orchestrator.

I’m uneasy about Kubernetes because it’s insanely popular at a point that we need to care too much about the orchestrator to receive the real benefits. Michael Dell shouldn’t be talking about Kubernetes doing X or Y. Michael Dell should be saying to other CEO’s, “Dell systems are optimized traffic control systems that will decrease the congestion needed to create applications.” (Not that one of the world’s wealthiest entrepreneurs needs my advice)

Name Spaces are the Jam (avoider)

So, if Kubernetes is the invisible stoplight orchestrator, how does a developer see the benefits? The benefits of Kubernetes is the ability to consume the infrastructure without knowing anything about Kubernetes. Kubernetes disappears when you embrace namespaces. Namespaces continue to be one of the greatest innovations of basic computer science. Look no further than Internet DNS as an example of its value.

An example of a company that gets this is Solo.io, who presented at Cloud Field Day 6. What if you wanted to build a new micro-services application that uses blockchain to track produce from farm to table. From a workflow perspective, you need transaction information from your SAP system. What scares some IT executives is that integration point.

It’s not only the integration of two different technologies. The integration involves two different cultures of application development and management.

Wouldn’t it be nice if you could provide your developer with a namespace endpoint that queries SAP ECC for the information you need? There’s no need to teach the developer SAP APIs. Come to think of it; you could replace ECC with some other transactional DB and in-theory your farm to table application will continue to work.

That’s the promise of moving to micro-services. It doesn’t matter if the underlying infrastructure is a container, VM, or Cloud-based. Just as long as the namespace is consistent in asking and answering requests, your code needs no modification.

Solo.io’s SuperGloo is the glue to make this happen. It works with service meshes such as Hashicorp’s Consul, another Cloud Field Day presenter. Consul enables service discovery and communication (stoplight orchestration), while SuperGloo provides that front-facing interface (the stoplights).

The integration is written to and executed against the API Gateway (SuperGloo). The backend calls are controlled using the service mesh (Consul). The code running the services can run in containers + Kubernetes, VMs, SaaS, or Mainframe. The value is in making the orchestration invisible to the developer.

CTO’s Take

Before you rush off to start putting your VM’s into containers, think through what problem solve. What are the bottlenecks in your application development? Are these systems, skills, or process-based? My bet is like most business problems; it’s a combination of all three with the people and the process being the most important to identify.

Share This Story, Choose Your Platform!