How Serverless Can Shape Enterprise Integration

Introduction

With a serverless platform, a programmer can write business logic and directly run it in the cloud without worrying about hardware, operating systems, or servers. Consequently, developers can focus on the business logic in their applications, with minimal understanding of the underlying infrastructure, since these details are handled in the cloud. At the same time, serverless technology raises several natural questions: how it might change the technology landscape in general, and, more specifically, how it could impact integration?

In response, we have studied the effect of serverless on the integration domain in depth. Based on our findings, we have arrived at two conclusions. First, we believe that most new applications will move to the cloud in the next three to five years where they will run on either a serverless or Kubernetes platform. Second, the difference between building apps and building integrations is fast disappearing, and the serverless environment will need an integration language to support those use cases. The rest of the article discusses our findings.

Applications Are Moving to the Cloud

There are several developments driving applications to the cloud.

First, APIs are on the rise. If this trend continues, most apps will use at least one API. On the other hand, the latency imposed by wide area networks (WAN) is up to 300 times higher than latencies within data centers. Such high latencies have a significantly greater effect on applications that uses APIs. Consequently, if applications are composed of APIs, applications will be better placed in the cloud close to their APIs, which have low latency. This development will create incentives for both apps and APIs to move to the cloud.

Second, for an application developer looking to implement a microservices architecture (MSA) in the cloud, a serverless environment is a natural candidate. Furthermore, an MSA can be easily moved to serverless platforms, since the functional decomposition already has been done. Furthermore, the cloud reduces the high cost of observability and DevOps associated with microservices due to its distributed nature.

The third development is that, with the adoption of Kubernetes, the complexity of systems is rising, and to address this complexity, systems need observability and complex DevOps, driving additional systems to the cloud. Let’s explore this. Almost all cloud vendors have adopted Kubernetes, effectively converting it to a portability layer for cloud applications. Although it brings flexibility and efficiencies, Kubernetes deployment and management is complex. The same applies to other additions, such as service mesh. Moreover, as the number of components in the systems increases, these components become harder to deploy and manage. Therefore, these deployments require observability and DevOps for managing complexity, which in turn is pushing more systems that provide this functionality to the cloud.

The three developments above, coupled with standard cloud advantages, such as cost savings, agility, and faster time to market, making the cloud the platform of choice for most applications.

Against this backdrop, developers who want to write an app or an integration in the cloud have two choices. They can choose to run integration logic on top of Kubernetes using integration middleware, or they can decide to run integrations as serverless functions. In a nutshell, serverless computing provides usability while Kubernetes provides portability.

It is not clear which one will attract the most apps. Historically, usability has won. Kubernetes is trying to match the usability of serverless computing by building layers, such as KNative. One possible future is having KNative also matching a “serverless platform-like API.” However, Kubernetes has a lot of catching up to do in terms of a wide range of platform services, such as databases, message brokers, and identity services. Another possibility is that future integration tools can enable users to write integrations and directly produce serverless functions that can run on either a serverless platform or Kubernetes.

Consequently, we believe serverless computing is poised to become one of the key infrastructures upon which future applications will be built.

Programming Future Applications

The difference between building apps and building integrations is fast disappearing. The rise of the cloud, APIs, and serverless architectures are making app development much more like integration, effectively making integrations ubiquitous. Applications are composed of APIs, and the logic required to write those applications is similar to writing integrations. Consequently, the need for integration-like technology will be much more commonplace in future systems. This development will significantly widen the available market for integrations while driving existing programming languages and platforms to provide first-class support for writing integrations.

We can program simple integrations using programming languages, such as Java, Go, and Python. However, complex integrations in serverless architectures also inherit most of the problems that occur in enterprise integration settings. For example, those integrations need to be built by composing APIs from different vendors, which leads to timing, data format, and context mismatches. Using a programming language, such as Java, to do so requires a great deal of detailed code. Furthermore, with the wide adoption of microservices and APIs, the number of services involved in an integration will likely rise, increasing the complexity of integrations and services alike. To handle such scenarios, Enterprise service bus (ESB) vendors, such as WSO2, Mulesoft, and IBM, have provided integration languages. It is likely that similar tools are required for integrations in the cloud as well.

Historically, early integrations were written using classic programming languages, such as COBOL, C, Java, and C#. However, most integration use cases involve communicating between services, APIs, data sinks, and data sources and then matching their inputs, outputs, timing, and control flow. Classic programming languages do not have first-class constructs for service invocations or dealing with data formats such as XML or JSON. Hence, developers need to re-implement the logic from first principles, which leads to code that is verbose, complicated to write, and hard to maintain. To address this challenge, on-premises integration vendors have supported domain-specific languages for programming integrations.

Currently, serverless platform users rely on languages, such as Java, to implement their integration use cases. However, as more complex use cases move to serverless architectures, we are likely to rediscover the limitations we faced with those languages years back. Therefore, the lack of higher languages supporting integrations continues to be a challenge faced by serverless computing.

This can be solved using several means:

• Users can run integration middleware within an infrastructure as a service (IaaS) solution and use it to integrate serverless applications.
• Cloud providers can support integration middleware as one of their platform as a service (PaaS) services.
• Cloud providers can support integration languages—e.g., Ballerina or domain-specific languages (DSLs)—as languages supported by a PaaS.
• Solution providers can expand visual programming support for general integration.

Conclusion

While exploring the impact of serverless on integrations, we have arrived at two conclusions. First, we believe that most new applications will move to the cloud where they will run on a serverless or Kubenetes platform. Second, the difference between building apps and building integrations is fast disappearing, and the serverless environment will need an integration language to support those use cases. We believe these two observations will help organizations in planning the long-term strategy for their systems.

We found that serverless platforms within integration use cases have a significant impact demonstrating that these are feasible. Assuming that serverless platforms will support an integration language, we expect to see many new applications adopting serverless architectures in the next three years. Since these applications use APIs and interact with external systems, as applications move to the cloud, integration use cases will move to the cloud with them. The full report of our findings can be found here.