Istio service mesh hits OpenShift GA, but upgrades are slow
Istio service mesh, Kiali and Jaeger are generally available for Red Hat OpenShift 4, but it will be some time before users are ready for the latest version of the platform.
Red Hat OpenShift has rolled out its integration with Istio service mesh, along with cloud-native monitoring and distributed tracing tools, but the move to OpenShift 4 will remain a major hurdle for Red Hat and its customers alike.
Red Hat OpenShift Service Mesh consists of Kubernetes Operators for three open source applications: Istio service mesh, Kiali monitoring and visualization and Jaeger distributed tracing. Istio is among the front-runners in emerging service mesh technology, which gives users fine-grained control over network observability, orchestration and security in container environments. OpenShift Service Mesh installs all three components as a single package with built-in configuration logic, such as memory limits, that use the main OpenShift 4 Kubernetes cluster Operator to automatically tune the system. It also automatically adjusts settings in the Red Hat Enterprise Linux kernel to optimize the performance of hosts that store service mesh telemetry data via Elasticsearch. As with other OpenShift Operators, Red Hat will send ongoing updates, including security patches, for OpenShift Service Mesh by default.
But while a few OpenShift users are ready to tackle cutting-edge IT automation concepts, the bulk of enterprise IT shops have a long way to go before OpenShift 4.1, and OpenShift Service Mesh, reach production, analysts say.
"OpenShift 4 introduces a lot of new core functions – it's not just an incremental change," said Tom Petrocelli, analyst at Amalgam Insights in Arlington, Mass. "It's the realization of OpenShift as a complete platform rather than just container cluster management software, and version three and version four will coexist within enterprise organizations for a while."
Red Hat OpenShift Service Mesh includes a Kiali UI visualization of Jaeger distributed traces.
Red Hat shops put Istio service mesh on the back burner
Red Hat shops are interested in OpenShift Service Mesh, as they were in the overall platform architecture introduced with OpenShift version 4 in May, an overhaul that's based on the Operators IP that Red Hat acquired with CoreOS in January 2018. But a heavyweight migration process and the additional complexity of service mesh management make it a long-term goal for mainstream IT shops.
"We do want service mesh, but right now it's pushed out well into the future because of the migration [from version 3.11 to 4.1]," said James Anderson, senior principal enterprise architect at Sabre Corp., a travel industry software provider in Southlake, Texas. "It's on the back burner -- the same people that would assess the migration path are installing and managing version 3.11 right now."
Before it migrates to OpenShift 4.1 and rolls out service mesh, Sabre must finish a project to install version 3.11 in a second AWS region for public cloud redundancy and update its on-premises OpenShift infrastructure to that version. So far, that process has taken most of 2019.
"It's not mandatory to install 3.11 first, but we know our tooling and integrations will work with that version, and we want all three environments to be homogeneous and stable" before beginning the migration to version 4, Anderson said.
Ultimately, Sabre wants to use service mesh for automated service discovery in its container infrastructure, along with mutual TLS that will push security away from the underlying server layer and closer to applications. It will be easiest, in Anderson's estimation, to use Red Hat's Istio service mesh integration with its existing OpenShift platform to get those features, but that doesn't mean it will be trivial.
"We've also looked at HashiCorp's Consul, which can intermesh with Istio, and Solo.io [API gateway Gloo], which can help us control multiple meshes, so we can also add mutual TLS and proxy-based service discovery to our non-container resources," he said. "Lots of additional moving pieces need to be working."
OpenShift shops need time to adjust to automatic updates
Red Hat hasn't said what proportion of its user base has made the jump to OpenShift 4.1, and acknowledged that the upgrade will require careful planning when OpenShift 4.1 became available in May. The disruptive migration requires users to shift their existing Kubernetes namespaces into clusters on the new platform to accommodate the Operators-based architecture shift. Red Hat officials advised attendees at the company's annual user summit in May to use an open source migration tool based on Heptio's Velero to automate some of the work.
Once past the initial migration, automated software patches and updates will also take some getting used to for OpenShift users, and Red Hat officials have seen this firsthand.
"[OpenShift Service Mesh] is one of the first add-on products Red Hat is shipping like this, that broadens the platform beyond just Kubernetes," said Brian Harrington, principal product manager for OpenShift Service Mesh at Red Hat. "It's an adventure for the entire organization as we rethink how we build and ship software."
We've seen with cloud services like Amazon Aurora that live 'push' updates can be helpful, but even once we have that in lower environments we'd still probably have someone manually apply changes to production.
James AndersonSenior principal enterprise architect, Sabre Corp.
Operator-based automatic updates for OpenShift bring a SaaS-like approach to software maintenance, but let it run in customer environments, which changes the management equation significantly, Harrington said. Red Hat has less control over users' on-premises OpenShift deployments as it would over pure SaaS, and it has had to navigate how to handle situations such as when a customer shuts off automatic updates.
In that case, Harrington said, Red Hat's Plan B is to warn customers of major security vulnerabilities that require manual patches if automated updates are turned off. But he predicted Red Hat customers will undergo a similar adjustment period as CoreOS users did, where they first shut off automated Operator updates, then turned them back on manually once a week, and gradually grew to trust the automated system enough to leave it on all the time.
Sabre's Anderson predicts it will take a similar burn-in process for his company to trust automated updates with OpenShift 4.1.
"We'll try them in lower environments before they get to production," he said. "We've seen with cloud services like Amazon Aurora that live 'push' updates can be helpful, but even once we have that in lower environments, we'd still probably have someone manually apply changes to production."
