M+E Daily

When it comes to the integration of the Red Hat OpenShift enterprise Kubernetes container platform with native AWS services, there are a few options that organizations can consider, according to Ryan Niksch, senior solutions architect at Amazon Web Services.

During the Sept. 21 webinar “Red Hat OpenShift Integrations with Native AWS Services,” he discussed how to enable prescriptive self-service adoption of AWS native services to complement application workloads running on OpenShift

He also explored open Service Broker application programming interface (API) solutions, Kubernetes operator frameworks, and AWS Service Catalog.

There are “a few options for integrations that customers can take advantage of so that they can bring native AWS services, prescriptive self-service interaction with those services into the picture to help them use our services to complement workloads running in OpenShift on AWS,” he said.

“How did we get to this bizarre sort of requirement?” he asked rhetorically. The answer: “Businesses have been going through a state of digital modernization for some time now and, from one business to the next, digital modernization means a different thing. For some customers, it is changing the tools, the technologies that they use. It might be moving from a very traditional, legacy way of building applications towards something like microservices. For another customer, that might be embracing virtualization or moving to the cloud and looking at their cloud services.”

Whichever route the customer is taking, “whether you’re changing technologies, whether you’re changing infrastructure, whether you’re changing development processes or whether you’re just changing process in general, [with] modernization, the end goal is ultimately to be able to move faster, to be able to be more agile, to be able to service customers faster,” he explained.

“Many customers start their modernization journey by changing one thing and then later that evolves to the point that you want to bring something else in,” he said. As an example, microservices “lead you to the cloud and then you start seeing the value of other services on the cloud and you want to bring those services into the picture to help complement the application stack,” he noted. “But then you deal with things such as application development teams might be using one tool and infrastructure teams are doing another set of tooling. How do you build a bridge between those two? How do you, for example, get developers access to native AWS services in a simple, faster way and allow them to consume those with applications running in something like OpenShift?”

The Benefits of Deploying OpenShift on AWS

The reasons why customers deploy Red Hat OpenShift on the AWS cloud include: scalability, availability, security, elasticity, service portfolio, and cost, Niksch pointed out.

“What stood out for me was many customers were saying they had selected AWS because of the native service offerings: Things like relational databases, things like Aurora” and also the artificial intelligence and machine learning services, he said.

“It created a situation where developers wanted to be able to utilize these services but they didn’t want to have to step outside of their platforms [or] swap hats [or] change interfaces. They wanted an easier, more prescriptive self-service mechanism of touching these things,” he explained.

So developers are using platforms including OpenShift now, which “gives them developer productivity and they’re dealing with containerization, they’re dealing with orchestration of Kubernetes,” he noted. “But how do I bring other AWS services into that picture to complement them?”

The Challenges

“The challenges with things like open Service Broker technologies is though they are rather mature and though they have existed for some time and they’re very relevant in older versions of OpenShift, they’re losing favor in the industry and they’re losing support in the industry,” Niksch said.

The AWS Service Broker is “very relevant to customers [using] OpenShift 3, very relevant to customers on the early versions of OpenShift,” he noted. But, with the shift towards Kubernetes operator, the AWS Service Broker is becoming less and less relevant. So we’re seeing less and less customer adoption of the Service Broker.”

Therefore, he recommends a different solution if somebody is looking to integrate in the future, he noted.

Since OpenShift 4, there has been a shift from service brokers to operators. So AWS created Amazon Controllers for Kubernetes (ACK) that he said is an “operator framework that installs into OpenShift and allows customers to interact with  native AWS services through that operator framework model.”

It is “very good for enabling developers or a team that is using something like OpenShift and you want to be able to control those AWS resources directly from within the application platform,” he explained.

For customers where everybody isn’t using an application platform – for example, where some business divisions are using OpenShift and others are using native AWS container services and you want to “consistently provide a self-service prescriptive model to all of those business units, irrespective of the platform they’re using, then something like an operator or a broker doesn’t quite work,” he said.

AWS Service Catalog is an option that will work for those customers. It allows organizations to create and manage catalogs of IT services that are approved for use on AWS, according to the company.

However, “the challenge that we face with the Service Catalog right now is, unlike brokers and operators, something like Service Catalog does create a gap for a developer, Niksch said. “You will see a team consuming something like Service Catalog having to leave OpenShift, go to Service Catalog, provision that resource and, once that resource has been created, then go back into OpenShift and create a configuration mapping for your applications to consume it.”

He predicted “we may see some evolution in the future where that challenge is alleviated, where there are better integrations.” But, “as it stands right now, there is a bit of a disconnect for developers,” he noted.

Considerations

Niksch went on to explain what considerations an organization should take to figure out the best solution for it.

“If you’re looking for a prescriptive control mechanism, you want prescriptive self-service of AWS services but you want to provide that across all business units, Service Catalog would be a very good fit,” he said.

On the other hand, “if you’re looking to enable developers with insight [into] specific application platforms, something like ACK might be a better option for you,” he noted.

“If you’re looking for very tight policy control constraints, again Service Catalog is a consideration,” he said.

But “if you’re looking for something that provides a unified experience, where teams are not swapping interfaces, swapping tools, swapping consoles and doing everything from inside OpenShift, as it stands right now, ACK would probably be a better option for your business units,” he pointed out.

And if you have business divisions with no AWS console access, “Service Catalog is probably not going to be a good fit for you,” so ACK would be better, he said.

Organizational structure is another important consideration, he added. If development teams have access to their own AWS accounts, either technology would be helpful. If not and the company has a separate cloud infrastructure team, the company would have to weight the benefits of each technology, he concluded.