This isn’t an industry that needs more acronyms but there is no stopping the cloud *aaS rocket ship so its better to clearly define new categories that get created as we fly towards the clouds. Integration Platform as a Service (iPaaS) is a new type of service tailored specifically for integration applications. The term ‘PaaS’ is a layer of cloud software that deals with the platform for building applications (if you are not familiar with PaaS take a look at my previous post). This layer is analogous with ‘middleware’ and in the same way middleware was broken into categories such as App Server, ESB and messaging, PaaS will also get broken down.

Gartner released a report earlier this year that broke PaaS down into application Platform as a Service (aPaaS) and integration Platform as a Service (iPaaS). The aPaaS category is the one that most folks are familiar with numerous services including Heroku, Elastic BeanStalk, CloudBees, Azure with some platforms being more aligned with PaaS concepts than others. The category is very new with Mule iON announcing earlier this year and others such as WorkDay have started to emerge.

iPaaS

What is iPaaS?

As the name suggests iPaaS is a development platform for building integration applications.  It provides a set of services and capabilities for integrating applications in the cloud and within the enterprise . The core tenants of iPaaS are the same as PaaS except the services on the platform are geared towards integration. In addition to some base expectations such as multi-tenancy, elasticity and reliability, there is a list of core capabilities that you can expect from iPaaS:

1. Intermediation

Being able to integrate applications and services is paramount for iPaaS. The cloud presents new intermediation scenarios which include SaaS and cloud services, custom cloud apps (iPaaS or aPaaS), on premise applications, and on premise services/resources.

2. Orchestration

I see the main use case for iPaaS is service composition with the services are SaaS and cloud applications, this requires connectivity and the ability to map data between services.  However, simple micro-flows, straight-through event processing and workflow will also be needed for integration applications to reach a broader range of use-cases.

3. Service Container

As well as integrating applications and services iPaaS consumers will need to publish their own services using either RESTful web services or SOAP and Web Service technologies. With many applications publishing a REST API, the ability to publish services will help support different consumers including Browser (JavaScript), mobile/device and machine to machine (M2M).

4. Security

This is a broad topic and a point of contention for the cloud.  Security covers the ability to authenticate and authorize access to any resource on the platform, the ability manage access to SaaS and cloud applications, encrypt and store sensitive data in a multi tenanted environment, secure published services using technologies like OAuth, SAML, and WS-Sec, SSL support, firewall rules and possibly VPN access.

5. Enterprise Data Gateway

There is decades of data behind firewalls, iPaaS offerings need to offer secure channels to access data on premise as well as in the cloud. This requires a gateway to be installed on premise and is used as a proxy to access enterprise data and resources such as databases, file system, applications and other services.

6. Developer Tooling

This is one area where things shouldn’t change. For a platform to be usable it shouldn’t mess with existing development processes. Whether running locally or deploying to iPaaS the development process should be the same.  Ideally the same integration applications should run on an instance locally or out in the cloud.

7. Runtime Monitoring

Runtime monitoring should be all about the application Service Level Agreement (SLA) and nothing else. The SLA is basically a contract that sets some behaviour boundaries for the application. These may define predictable response times, concurrent user limits, traffic boundaries or throughput.  The platform should enable alerts and monitoring as high watermarks are reached. This type of monitoring is very different from what most people are used to. Traditionally  visibility to all types of platform metrics are also available, in iPaaS world, the platform doesn’t need to be managed by the consumer.

For me this is a base list of capabilities and as iPaaS offerings get built out there will be new sets of services to cater for different categories of applications.  On thing is for sure, having all this functionality rolled into a platform will make iPaaS and very compelling option to allow consumers to focus squarely on building their integration application.

Follow: @rossmason@mulesoft

No related posts.

Interested in 3 days of knowledge sharing, hands-on labs, industry focused sessions, and plenty of networking? Register for the premier integration event, CONNECT London »

2 Responses to “Introducing integration PaaS (iPaaS)”

Hercules April 13th, 2011, 10:56 pm

hi Ross Masson:

I am trying to move my aoolication form jini/javaspace to mule, but it is so difficult to intergrate the service on mule.

would you please let me know how I can use mule client on the RMI, JDBC, JMS, FTP , and SOAP transport service?

Hercules

Ross Mason April 14th, 2011, 9:34 am

Hercules, please post generic Mule questions to the Mule user forums. If you need a quicker response or more in depth consultation please send your request here.

Leave a Comment