IPaaS characteristics
Integration platform as a service (IPaaS) is a new integration solution model that uses cloud computing technology. It is elastic and scalable and uses a consumption-based model to achieve major cost savings. An enterprise can achieve a significant return on investment by choosing this solution rather than using a corporate-owned data center. This consumption-based model is calculated on the actual usage, therefore it achieves further cost savings when the CPU, memory, storage, software, and integration services are idle.
Consumption-based model
The essence of the consumption-based model in IPaaS is that the service platform always knows who is using which services, for how long, and when. The primary external metric for the IPaaS consumption model is the use of IPaaS services. Since IPaaS offerings are pre-engineered to provide price smoothing across hardware variables, and also includes considerations for operational and application management support, all of the costs associated with IPaaS are rolled up to the IPaaS service level and associated with the consumption of those services.
IPaaS solutions can be architected to function in either a single-tenant or multi-tenant environment. In situations where a client is looking to deliver a multi-tenant SaaS-based solution to their customer, the underlying IPaaS integration architecture must support that. This is particularly true with inter-enterprise API designs. Even when the solution is clearly single-tenant, IPaaS services are typically enterprise level and must support a range of constituent lines of business and their trading partners. As a result, IPaaS supports multiple views to report on service consumption.
IPaaS service consumption is recorded and reported for two primary purposes:
- Monitoring overall capacity usage in business terms, thereby allowing proper forecasting of capacity
- Providing the ability of charge back or other cost recovery schemes based on the use of IPaaS services
To support this consumption-based model, IPaaS includes the technical capability to apply reporting analytics to business events, correlate participation in business events across multiple IPaaS components, and identify the complete business context around each business event.
Rapid elasticity
Demand can vary for a number of reasons. For example:
- Seasonal or event-specific business patterns may drive spikes and valleys in production usage
- Test usage due to back-end changes, where major system of record enhancements require a full set of end-to-end acceptance and performance tests including IPaaS
IPaaS is specifically architected to expand and contract rapidly to changes in demand. This is attainable because the IPaaS environment builds on the features and functions of the IaaS and PaaS cloud-offerings, so there is no re-inventing these underlying services for IPaaS. An IPaaS service request for more capacity will automatically call on the underlying IaaS and PaaS cloud provisioning services. In addition, the IPaaS catalog has pre-engineered the provisioning request specifically to the IPaaS functional services. This is consistent with the overall philosophy of cloud architecture and open source initiatives like Cloud Foundry, Docker, and OpenStack. This IPaaS pre-engineering also provides for price smoothing across hardware variables, and also includes considerations for operational and application management support.
Services catalog
The services catalog is the key to understanding the richness of the IPaaS delivery model. In the past, the capability of a given ESB was defined as the set of transaction/messaging patterns that it implemented. Now with IPaaS, there is a more powerful approach. IPaaS is defined as a set of standardized and selectable business capabilities (i.e. services). It is helpful to think of these services in three classes:
- Functional: These services define the business capability domains that can be provided by IPaaS; for example, enterprise service bus (ESB), business process management, API management, managed file transfer, and electronic data interchange.
- Non-functional: These services enable the quality of service (QOS) attributes of the IPaaS functional services. For example, a customer may select an ESB service from the catalog, but may have different QOS characteristics in a production instance than in an instance that’s used for testing. Non-functional services allow the customer to select levels of services applicability to their specific QOS requirements (such as high availability, continuous availability, response time, and throughput rate).
- Lifecycle: These are the underlying create/read/update/delete (CRUD) services needed to provide on-demand scalability within IPaaS. For example, it is possible to add additional nodes under an IPaaS functional service and then later remove them or relocate them to another service center.
From this perspective, the IPaaS services catalog can be seen as a three-dimensional model of offerings.
Figure 1. Service classes within the IPaaS services catalog
Image showing a three-dimensional view of functional and nonfunctional services in the IPaaS catalog
Another important consideration of the IPaaS services catalog is that the necessary hardware, software, configurations, topologies, and support are standardized and predefined. This means that there is no new development effort needed to stand up a service from the IPaaS services catalog. It also means that there are no compatibility issues between services in the IPaaS services catalog that might lead to a runtime discovery of a mismatch of IPaaS services.
