Until now, organizations have addressed the connectivity issue with middleware or enterprise application integration infrastructure with some form of enterprise service bus at the core. However, today’s cloud-native applications may require new types of platforms and data sources, which is why Red Hat delivered a unified cloud-native integration platform in February 2018.

RELATED CONTENT: Agile integration bridges the gap between legacy and modern systems

Red Hat’s Integration has enabled, among other things, organizations to transform their traditional middleware architectures into a more agile framework.  Sameer Parulkar, Red Hat’s product marketing director for middleware integration spoke, with SD Times, underscoring that he believes organizations that are looking to roll out modern, cloud-native applications should embrace agile integration as a core component of their application architectures.

SD Times: What is agile integration?
Sameer Parulkar: We started talking about agile integration at Red Hat Summit in 2017. We were looking at the integration space and the capabilities that we offer as well as some of the challenges from the customer perspective of adopting these integration capabilities, as well as providing faster and competitive solutions. And then we spoke with a lot of our customers and there was consensus that integration should be more agile and align with DevOps. One of our key motivations with agile integration was to essentially position integration as a key business capability, enabling differentiated services for customers.

In what way does Red Hat Integration make integration agile?
Agile integration is based on three key capabilities: distributed integration, the ability to distribute your integrations across your applications; APIs, essentially using API’s to create your integration; and having an API-first approach and leveraging technologies like containers to essentially host and connect your integrated applications. As customers are adopting microservices, DevOps and cloud, and they are developing continuous services, integration capabilities should be just part of that. With a focus, investment and innovations in cloud-native integration capabilities, Red Hat Integration provides customers tools to adopt and implement agile integration architectures.

How is the architecture different from your typical enterprise application integration or middleware platforms?
When you look at technologies like enterprise service bus or traditional integration technologies, they have been here for 10-plus years in the industry. I used to be an architect before moving to Red Hat eight years back, and I implemented several of those technologies. There are incredible benefits of that architecture and proven technologies for traditional technical challenges.

So, middleware is no longer suited for today’s environments?
Frankly middleware technologies and how customers deploy them have evolved, especially with the adoption and popularity of cloud-based services. From a technology perspective, there are benefits to traditional enterprise service bus technology and one of those benefits was the ability to control the environment. All the integrations are done using the enterprise service bus that is deployed in one place. Everything connects to that one thing. What happens is you get control, efficiency of solution and you know what’s going on. The challenge is that this enterprise service bus technology has become a monolithic application by itself.

When you say monolithic, do you mean legacy?
What I mean by that is, if I’m deploying an enterprise service bus, depending upon how it was done and deployed, that itself became a monolithic application. Now, with the adoption of cloud, API-based digital solutions, more customer-centric solutions, more event-driven solutions and with the necessity today of doing things much more quickly, like with DevOps or microservices, it is incredibly difficult to retool your centralized ESB based services, to be part of DevOps processes, or to connect as well as create microservices. From organizational perspective, oftentimes the ESBs were being developed and managed by centralized integration teams, that are oftentimes called ICCs or integration competency centers. Those are typically like the integration specialists. Now, with a specialist, they bring a lot of expertise in terms of integration– they’ve been doing this for several years. And the integration oftentimes is hard, but they know how to do it. We believe the ICC teams should be enablers of innovation and work with the application development teams. But they need tools and technologies that can adapt with fast changing requirements as well as leverage existing assets. Technologies that allows them to deploy capabilities embedded or distributed with applications.

Have you found that organizations are willing to move away from this centralized focus to the more distributed approach?
Since we introduced it back in 2017, a lot of things have changed, especially with the adoption of containers. Customers are adopting containers to create and scale their environment, adopt hybrid cloud architectures. Now, with an approach like that, one of the key capabilities of agile integration is that we are now seeing much more adoption of this type of technology within the marketplace.

Are companies actually implementing this approach?
We have several customers, like UPS, who have been longtime users of our integration technology. And now they’ve started to adopt more of a DevOps approach, a continuous approach with their application development, and adapted their integrations with the new architecture. Another one is the Government of Canada, Innovation Science and Economic development (ISED). One of their innovation departments started using APIs where they can now share the government services within different departments to provide citizen services. They have adopted our integration technologies like our 3scale API Management with container technology. Swiss Federal Railways is adopting API management capabilities with our OpenShift Container Platform to bring their applications to market faster. And Ally Bank is trying to digitize their banking services and is now adopting much more of a DevOps microservices process, which again is enabled from containers, and also now the integration technologies is helping them do that.

What are the biggest drivers of this architectural change?
Providing a differentiated customer experience, which is sometimes called digital experience, is becoming extremely important. And that is driving a lot of this innovation and they want to do this faster with more agility. To deliver that, they are adopting different approaches. And an API approach helps because if you think about your services as APIs, that in turn helps to create those differentiated services, to connect with customers, suppliers and to connect with partners by essentially creating an API platform or API type of services. Not every customer is doing that yet but it’s something we’ve seen changing over the last few years.

Where does introducing API management fit into this?
APIs are essential to provide digital services and also to create ecosystems with customers and partners. As APIs become important managing, securing, scaling, measuring those APIs becomes even more important. That is API management. When adopting an API management model an important aspect is the gateway, which controls access to the APIs. The next challenge is how do you want to deploy that capability? A common approach we often see is when you configure your API for security and policies, you can deploy your gateway across your enterprise. In a hybrid architecture, That has a lot of advantages in terms of the flexibility but also, in terms of how you actually go about developing your API. New technologies like service mesh provide service-to-service communication especially for microservices. API Management capabilities are complimentary to service mesh.

With the recent release of OpenShift 4, how has that advanced your agile integration and API-first approach?
A key focus is on a capability we call Operators, which in a container environment, allows you to build and manage Kubernetes-native applications. It provides an automated way in which you can deploy your services into that container environment. You can actually define it as a service and then use tools to deploy those services directly into your environment.  The advantage of that is you are now going to have an operator for different sets of capabilities. For example, you may have an operator for API management capability, or you have an operator for your messaging capability or you have an operator for data streaming. Then you can just use the operator to define how you want to configure and install that capability in your container environment. Once you configure it it’s easier to automate those deployments across your environment. Operators provide a mechanism to automate deployment of integration services and making it easier for them to be part of DevOps process. 

Would you explain how the whole notion of how an API-first approach changes the integration process?
When you look at an API-first approach, it’s about the services that you deliver. It’s about providing your services or functionality as APIs. What it forces you to do is think about how you can actually share those services with your other customers and partners.  This enables you to create much more differentiated services.

To what extent are organizations applying real-time messaging into these new scenarios?
Real-time messaging is a key requirement as it directly helps access to the most updated data and just-in-time data. Now we are also seeing more data streaming capability. And the idea behind that is with technologies like Apache Kafka you can get streams of data from one place to the other and you can share it among different entities. With data streaming, capturing say customer behavior, and the streams of information that are coming in with Kafka, really provides a great way to do that. We can analyze the streams of data to make more real-time decisions and further processing. With Red Hat Integration, we support real-time data streaming along with traditional enterprise messaging.

Are most people starting out with a pure cloud type environment or are they doing it in a more hybrid?
Quite frankly, I would say they are typically more in a hybrid environment because they have their existing assets and those aren’t going away, and then there are a lot of assets that are born into the cloud. And so agile integration actually becomes like a really a bridge for them to adopt hybrid cloud technologies.

How do you see that changing?
We are seeing that progressing much more now because when you look at it from a container adoption perspective, containers enable you to create a hybrid cloud deployment architecture. When you say hybrid cloud or multicloud, containers provide you the layer to deploy your applications on-premises in a private cloud or in a hybrid cloud. Plus, you may have procured multiple SaaS apps. You need to connect all of this together and manage all of this together. So, I think adoption of hybrid cloud is essentially contributing to a customers requiring agile integration.

 

Content provided by Red Hat and SD Times