Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Future of Integration

DZone's Guide to

The Future of Integration

Integration is an old subject, but it's still alive. Let's have a look into what could be its future.

· Integration Zone ·
Free Resource

WSO2 is the only open source vendor to be named a leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report. Download the report now or try out our product for free.

The subject of integration is often an unloved subject, yet it remains and will remain a core subject. New technologies are emerging without openly shouting that they are integration technologies. I think of the API Management, whose success is not denied, but also others like GraphQL and Data Virtualization. So this is indeed a very actual topic and one that will continue to make headlines. It is, therefore, interesting to ask ourselves what future we can prepare for.

If I had to make it very simple, I would say that the two drivers of integration are the ever-increasing costs of integration and the changing technological landscape. These costs may eventually represent 50% of the costs of major projects according to Gartner. As for the technological evolution, I retain the following points:

  • Cloud and multi-cloud issue

    • Cloud providers such as AWS are constantly evolving their offer both in terms of cost and technological content. It is, therefore, necessary to be able to monitor and support the integration of these bricks. At the same time, we are seeing the emergence of multi-cloud, where companies want to integrate several clouds between them. This obviously pushes the integration bricks to be agnostic of the cloud provider. But I think it also pushes these application bricks to "virtualize" the cloud. Imagine you want to integrate data between AWS and Azure. You can install the integration tool on AWS or Azure. But are you interested to know where it is installed? Is the developer interested in this information? And is it relevant for all uses cases to have your integration running on AWS or Azure? The idea would be that the integration solution would be a kind of hatched solution, managing itself the execution location of your code, according to performance, reliability and cost criteria. You would develop your integration on a platform specific to the integration solution, focusing on the business need for integration, without asking yourself the technical questions.

  • Microservices to serverless

    • I often read articles on microservices, and I often make the same remark: is this really what we want to do? We are told how to configure Nginx, Istio, and Kubernetes, but is that the purpose? It reminds me of some amateur photographers. They are aware of all the new material, know the technical characteristics by heart, but for all that, their photographs have nothing artistic. What matters is the end result, the 'why,' but not the 'how.' That's how I see it, and that's how I think the development of microservices is going to move towards the ability to focus only on business code. Moreover, we see clearly in the technologies that appear around microservices, that the goal is to simplify the work of developers. That's what makes me think we're heading straight for the serverless at full speed. Certainly, the cost curves are not in favor of serverless versus in-house microservice on large projects. But with the reduction in costs that will mean that the differences in absolute value will decrease, and the failure to take into account in the cost curves that can be found on the Internet that do not take into account the costs of Ops, it is likely that we will do microservice without knowing it, with serverless.

  • Integration as a product

    • This is already a major trend accompanied by the rise of API Management. It's about making integration easily available and off the shelf to application developers. It's also about making this accessible to project managers, promoting its integration capabilities, and even reselling them. The API has been able to do this with the services but still needs to do it for data, events, and processes with ad hoc tools.

  • Big Data and ELT

    • Big Data projects often show schizophrenia. They say they don't integrate, they don't like it, and yet they use a number of tools to integrate data into their Big Data platform. And yet it is out of the question for them to cede these tools to integration managers. Integration in the broad sense will have to take up this subject.

  • New Integration technologies

    • Not only software stacks evolve, but integration also follows motion. We can talk about GraphQL, Data virtualization, and RPA, for example. GraphQL and Data Virtualization on the accessibility of the data, RPA as a palliative for an integration that sometimes had difficulty proving its ROI on tight scopes.

    • We can also predict that event-driven technologies are next on the list to see the emergence of new technologies that will simplify our lives.

Read the WSO2 Methodology for Agility to see how you can transform your integration projects from semi-agile to a scalable continuous agile approach.

Topics:
integration ,the future of integration ,cloud ,microservices ,serverless ,integration as a product ,big data ,new integration technologies

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}