Red Hat Embeds Amazon Web Services into OpenShift
Red Hat’s introduction of on-premises Amazon Web Services capabilities in OpenShift on Tuesday made it seem as though the company had worked out a competitive alternative to Microsoft’s Azure Stack, which effectively replicates Microsoft’s cloud services for on-premises installations. But in a demonstration to Red Hat Summit attendees Wednesday morning, Amazon and Red Hat architects revealed a certain kind of magic behind the curtain, relying on a line of visibility somewhere in the chain between servers running OpenShift containers and Amazon.
“No matter where OpenShift is running — whether you’re running it on your laptop, in your own data center, using one of our services, or running it yourself in a public cloud,” explained Matt Yanchyshyn, AWS’ partner solutions lead architect, “if you can see Amazon Web Services from OpenShift, we expect you to be able to use Amazon Web Services with OpenShift.”
It may take a round of Clintonian parsing to nail down exactly what Yanchyshyn meant by “see” in this context. Arguably, thanks to the Internet, every Azure Stack deployment can “see” Azure in the public cloud. Microsoft’s documentation makes it clear that use of Azure Stack does require a connection with Azure. So one could conclude OpenShift’s connectivity requirement is virtually no different.
Yet evidently, Red Hat’s and Amazon’s choice of language here is very intentional. A Red Hat corporate blog post published just minutes after the demo, echoed exactly this phraseology: “As we mentioned during the keynote demo, if you can see Amazon Web Services, then we expect you to be able to use Amazon Web Services for your applications in OpenShift.”
But the matter is by no means trivial, especially for any development team whose business is technicalities. Verifying a host’s subscription status may be a simple enough matter to accomplish, but a persistent connection between AWS and a large set of microservices may introduce the potential for latencies, for which any distributed services architect will need to account.
With a much fuller list of AWS services being made available on OpenShift made official Wednesday, and with that list including network connectivity and big data services, developers being asked to pay less attention to the infrastructure will certainly be concerned about just how often those services will require being seen.
In a pre-recorded video, AWS CEO Andy Jassy revealed a much more complete list of Amazon services that will be packaged natively with, and available to run on, OpenShift platforms, wherever they run. The AWS Lambda serverless service, which was mentioned Tuesday and which drew a question mark in response from some Red Hat officials, was on the top of Jassy’s list. Serverless architects should be enthused.
Also on the list are: Relational Data Services, the Aurora MySQL and PostgreSQL compatible database, the Redshift data warehouse service, EMR (Elastic MapReduce), the Athena interactive query service, the CloudFront content delivery network, the Route 53 DNS service, and Elastic Load Balancing. The CEO then left the door open for “others” to join the list.
“It’ll also allow application developers who are using OpenShift,” Jassy continued, “to move much more quickly, so they’ll have that more consistent environment between on-premises and the cloud. And then we’ll also provide a single path of support for both Red Hat and AWS… such that you can deploy your applications in production with confidence.”
This support channel was discussed during Tuesday’s Red Hat press conference, and will enable Red Hat support personnel to deliver AWS-accredited support for its components running on OpenShift platforms. The arrangement appears similar to the deal Red Hat struck with Microsoft in 2015, enabling both companies to serve as points of contact for support with deploying and managing Red Hat components, such as RHEL, on Azure.
Jassy also said containers’ access to these services will be arbitrated using AWS’ native service brokers, although Red Hat’s blog post Wednesday specified that communication with these brokers will take place using the now-standard Open Service Broker API.
Conceivably, OpenShift may need to “see” AWS in order that it may keep each of its components in the system current. But as Red Hat engineers demonstrated Tuesday, the OpenShift.io hosted service — and, presumably, the main OpenShift 3.5 platform — will offer deployment templates that let teams quickly make use of CI/CD pipelines and Agile development practices. In demonstrations, they showed how the least complex of these pipelines could still raise appropriate flags when a component of a containerized application failed to pass a production-ready test. Unless multiple versions of AWS services are available simultaneously, so that newer versions may be tested prior to service upgrades, one can easily imagine a sea of red flags popping up on OpenShift developers’ horizons.
That is, unless there is a more robust relationship between the OpenShift platform and AWS’ native platform, besides what’s implied by the verb “to see.” A Red Hat spokesperson told The New Stack late Wednesday that “see” means, effectively, the ability to connect to OpenShift. As for what kinds of bindings between software components may be required, we’re told, “This is dependent on the nature of the OpenShift app/service and the AWS service being utilized.” In other words, we may have to wait and… um, see.
Red Hat is a sponsor of The New Stack.
Feature image via Pixabay.
