iPaaS. What is it exactly? is it on-premise software running on IaaS?

As cloud adoption continues to rise, the so called 'second wave' of cloud computing becomes less of a prediction and rather a reality we have to deal with. In the past 2 years or so for example, almost in every customer engagement I've had, 'the cloud' has been at the very least a topic of discussion. In most cases it has actually been within the scope of our activities.

This is not surprising of course as the term 'cloud' itself can mean ten different things to ten different people. The sad part is though, that is has been years since the first wave of cloud (started by Amazon) and there's still a fair degree of confusion in the topic.

In fact, I still often refer to the NIST definition of cloud to explain what cloud computing and PaaS actually is and how traditional on-premises middleware installed on IaaS isn't PaaS or iPaaS. This is in fact one of the main motivators of this post.

iPaaS

The term Integration Platform as a Service, or just iPaaS, is generally used when referring to integration capabilities delivered entirely on PaaS cloud infrastructure.

In terms of integration capabilities, iPaaS can deliver the same (and in many cases more) capabilities than the ones available in traditional on-premise middleware. Such capabilities should be sufficient to satisfy the main types of integration requirements:

Types of Integrations

It is perhaps because of such similarities that, in my experience, there still is a fair amount of misunderstanding of what iPaaS actually is, what it brings to the table and how it's different to traditional on-premise integration middleware.

Some for example wrongly believe that installing a traditional integration product (i.e. IBM BPM or Mule ESB) on IaaS infrastructure will make it iPaaS.

Well this is far from truth. Let me elaborate on why:

iPaaS characteristics

The following diagram is a summary of NIST definition of PaaS, it characteristics and how iPaaS relates to it:

iPaaS Characteristics

As the diagram suggests, for an integration capability (aka integration platform) to be truly iPaaS, it must comply with NIST's 'essential characteristics of cloud computing'. Following my own interpretation of such:

1. On-demand and self-service: it should be possible, at any given point in time, to go to a cloud vendor website (i.e. https://cloud.oracle.com/en_US/integration), browse through the different iPaaS offerings, select the one wanted/needed, purchase it online, using a credit card of course, and in minutes get an email with all details of the instance (already installed and running), how to access it and even use it. No need to talk with a sales representative, negotiate license costs, provision infrastructure, install/configure the software, and so on.
2. Broad network access: This is perhaps one of the most important characteristic. Network connectivity to/from iPaaS to other applications has to be fast, reliable and secured. Open internet connection can be unpredictable therefore the cloud vendor must provide alternative means to deliver dedicated high-speed connectivity. For example Oracle Cloud provides a service called Fast Connect, and Amazon a similar one called Direct Connect.
3. Resource pooling: Compute resources (i.e. cpu, ram memory, disk space) should be allocated on-demand (without human-intervention) based on resource utilisation or via configuration if desired. It should be possible to increase or reduce resources either on demand and/or based on pre-configured rules.
4. Rapid elasticity: During periods of high demand (i.e. black Friday), predicting resource usage can be almost imposable. A true iPaaS platform should be able to autoscale based on configurable rules and resource demand. Idea is that transaction peaks can be handled by scaling horizontally or vertically -without human intervention. When transaction throughput becomes stable, platform resources should reduce automatically to its original size. It should not be the case that it's possible to rapidly add more capacity, but not the other way around... 
5. Measured service: pay-per-use / subscription-based charging model with complete transparency and visibility over usage and billing. For example, if a given iPaaS is charged based on number of connections to other applications, it should be possible to know exactly how many connections are being used -at any given point in time. If the number of connections is reaching the limit, a notification should be sent so it's possible to allocate more connections. If on the other hand, the number of connections is in average less than subscribed for, a notification should be sent suggesting to reduce the number of subscribed connections.
6. Automatic application patching and upgrades: Although not explicitly mentioned, this is another key characteristic and possibly the one that makes iPaaS more distinctive from traditional on-premises middleware. Cloud vendors should be fully responsible for periodically applying patches and/or software upgrades to the purchased cloud infrastructure. It is the vendors responsibility to ensure that patches and upgrades applied are backward compatible and won't break any application.

Considering the aforementioned characteristics, it should hopefully be clear that iPaaS can't be simply delivered by installing traditional on-premise software on cloud infrastructure. 

Be watchful though: Some vendors might try to sell you 'the wooden bicycle' by simply rebranding their on-premises software as iPaaS when all they're doing is provisioning exactly the same on-premises software but on cloud infrastructure (i.e. Amazon EC2). This is known as Cloud Washing.

iPaaS & on-premise integration platforms co-existance

Even though iPaaS can independently satisfy cloud-to-cloud integration needs, it doesn't actually mean that on-premises middleware is no longer required. Quite the contrary.  Most organisations have already made considerable investments in on-premises integration capabilities. In such organisations, even the thought of replacing such capabilities will raise a few eyebrows. 

Instead, on-premise capabilities can continue to be leveraged not only to satisfy on-premises only integration use cases, but also to co-exist with an iPaaS solution to satisfy cloud to/from on-premises integration requirements.

The following diagram illustrates how typical integration patterns can be satisfied with a combination of iPaaS and on-premises integration capabilities.

Hybrid Integration Patterns

Another thing to bear in mind though, given that most software vendors are moving towards a cloud-first delivery model, new products, features, capabilities and even bug-fixes will be made available first to cloud applications and then (if so) to on-premise software.

Therefore in scenarios where for example a new integration capability (i.e. API management) is required which is not already available on-premises, it makes complete sense to consider the adoption of an iPaaS solution instead. Specially those that deliver flexible deployment models whereby runtime engines can be deployed on any infrastructure (cloud and/or on-premises) whilst the management console remains on the cloud.

Conclusion

The adoption of cloud (in all of its flavours: SaaS, PaaS or IaaS) combined with need for organisations to become more digital and user centric, mean that data is not only becoming more and more federated but accessing it in real time and from virtually anywhere is an absolute must. 

However there is no need to 'boil the ocean'. Organisations should continue to leverage their existing integration investments but in parallel define new integration strategies that identify what new capabilities are or will be needed in order to satisfy emerging integration requirements resulting from the adoption of cloud computing and digital transformation.

When possible iPaaS capabilities should be considered not only because they provide more cost-effective licensing models, but also because capability wise, they are better equipped to handle modern and emerging integration requirements. iPaaS also requires less effort to install, configure and run -as most of the work is done by the cloud vendor, including on-going patching and upgrades.

Lastly, avoid cloud washing by ensuring that the selected iPaaS platform satisfies all NIST's 'essential characteristics of cloud computing'. Read my previous blog for a nice comparison of different iPaaS vendors.