momius - Fotolia
Cloud-native vendor consolidation key to container technology adoption
Production deployment of containers and microservices currently requires the best technologies. Cloud-native vendor consolidation will simplify decisions but limit choice.
As the enterprise Java space matured around the turn of the century, vendor consolidation quickly reduced the number of viable application server offerings. Stalwarts like JRun and Borland's Enterprise Server quickly became passé, and other application server providers were either bought or were overshadowed by the IBM WebSphere and BEA WebLogic offerings. Vendor consolidation in the Java EE space reduced the number of offerings to just two or three big vendors, with a couple of competitive open source offerings thrown in for good measure.
Today, almost 20 years later, the age of the server-side application server is said to be dead, if not, slowly dying. We are now living in a new age of stateless microservices writing to NoSQL databases, deployed into Docker containers that are hosted on virtual machines whose hypervisors are provisioned by pay-as-you-go clock cycles in the cloud. It's a brave new world, but it's a fragmented world as well, not dissimilar to the way things were when the enterprise Java specification was originally released.
Proselytizing containers and microservices
Every evangelist with enough strength to stand atop a soap box is preaching the benefits of migrating to container-hosted microservices. Unfortunately, stepping through an online tutorial on how to create a Java-based microservice and subsequently run it in Docker is merely a fun first step. Production-ready microservices that are deployed into a set of individual containers require quite a bit of plumbing if an enterprise expects to do cloud-native computing right.
First and foremost, there's the challenge of doing dynamic container orchestration. For reliability and stability, a cloud-native application needs monitoring and alerting. Troubleshooting becomes more complex when using the cloud, containers and hypervisors, because code can be running in any number of hosting environments, and those environments are scattered across the globe. For the same reasons, distributed tracing becomes a challenge, too. Service discovery, authenticating remote procedure calls (RPC) and the provisioning of container runtimes are just a few more of the challenges with which organizations who throw away their application servers in favor of a purely cloud-native future must grapple.
CNFC to the rescue
Fortunately, these early adopters of the cloud-native, container-based approach are not scrambling through some unknown wilderness alone. The challenges associated with cloud-native computing are well known, and ways to address those challenges are becoming increasingly well defined. The Cloud Native Computing Foundation (CNCF) hosts nine open source projects under their umbrella, each of which tackles a unique subset of challenges that organizations planning to deploy containers and microservices at scale might face, including:
- Kubernetes for managing containerized applications at scale
- Prometheus for metrics and alerting
- OpenTracing for tackling the challenge of application tracing in an abstracted and distributed environment
- Fluentd for unified logging
- Linerd for resilient failure handing and routing
- gRPC for remote procedure calls
- CoreDNS for service discovery
- containerd for providing a container runtime
- rkt for providing a pod-native container engine for Linux
As you can see, those who are going cloud-native are in very good company, with plenty of intellectual firepower helping them secure their beachhead based on microservices and containers.
There is nothing bad that can be said about any of these projects. However, it is difficult for even advocates to deny that when all of these projects are listed together, it becomes very intimidating to the middle manager who has to make important technology decisions. And it should be noted that this is simply the listing of projects that full under the purview of the CNCF. There are innumerable competitors in each of these spaces, whether they are separate open source projects, proprietary implementations or simply vendors building customized products on top of these aforementioned projects.
The benefits of vendor consolidation
Technology aficionados love this type of disruptive, Wild West-type environment where multiple answers arise to each new problem that is encountered. But decision-makers hate it. This is why the future of this space is vendor consolidation.
Currently, making a cloud-based, container-backed, microservices environment work means choosing from many technologies. The big vendors in this space are looking at ways of hiding the names of the various projects that make cloud-native computing happen and, instead, blanketing those names with a well-established brand and logo. Decision-makers don't want no-name offerings, as they tend to create a great deal of uncertainty and risk. Instead, they want to simply be able to choose between Oracle and Red Hat, or between Microsoft and IBM.
Red Hat is certainly leading the way in helping to make the decision process easier with their OpenShift platform, as is Pivotal with their Cloud Foundry offering, but there are far too many competitors in this field, and too many subsegments to assert that any single one is leading the charge. Organizations like the CNCF, and vendors like Pivotal, will work hard to move the industry forward, but in the background, the big players like IBM, Oracle and Microsoft are looking to acquire a variety of technologies to produce a single offering that makes deployment easy, centralizes application management, boasts DevOps integration and provides high-level governance and policy enforcement. And what's funny is that this final offering will end up looking very much like what we've always known as a traditional, server-side application server. So much for those who prognosticated the enterprise application server's demise.
You can follow Cameron McKenzie: @cameronmcnz
Interested in more opinion pieces? Check these out:
- Why the Amazon S3 outage was a Fukushima moment for cloud computing
- Software ethics and why ‘Uber developer’ stains a professional resume
- It was more than user input error that caused the Amazon S3 outage
- Don’t let fear-mongering drive your adoption of Docker and microservices?
- Stop adding web UI frameworks like JSR-371 to the Java EE spec
