iPaaS Requirements: Must Respect Data Gravity
The two most common questions we hear from enterprise CIOs are:
- Cloudification: Which apps will be moving to the cloud and when?
- Data Gravity: Will our corporate data ultimately reside behind the firewall or in the cloud?
My previous post outlined what we at SnapLogic believe are six primary requirements for a modern cloud integration platform. The first requirement is a True Cloud Integration Service, based on the principles of software defined networking, which decouples the ?control plane? from the ?data plane.? (Gartner recently delivered an interesting presentation on Software Defined Architecture – registration is required.) In our recent TechValidate survey we asked about the drivers for adopting a cloud integration platform. The #1 driver was speed and time to value. On the other hand, we asked why not use your legacy, on-premises tools to address your cloud integration requirements:
- 43% took issue with the requirement for costly hardware purchases and software installation and configuration
- 37% found on-premise integration tools to be too expensive due to the perpetual licensing model;
- 35% noted that change management is painful where end point changes mean integration re-work.
But lately I?ve been seeing more and more ?cloud washing? in the data and application integration market. It?s not that some of the new and legacy vendors don?t have the ability to stand up an instance of their on-premises technology on Amazon Web Services (AWS). That box has been checked for some time. It?s more of a ?hybrid cloud wash,? where the vendor introduces a feature-light cloud service, which is really an on-ramp for a boatload of on-premises software that?s required for any complex integration use case. In some cases, the cloud service is only a run-time environment for monitoring integration workflows. Advanced integration design, management and configuration features require complex developer tools built well before world of SMAC became a reality. At SnapLogic, we believe that the integration platform as a service (iPaaS) must be a true, multi-tenant cloud service and it must be able to handle simple and complex, muliti-point use cases. We also believe that right architecture is software defined:
- The ?control plane? is the brain. Delivered as a multi-tenant cloud service, this is where you do you work – design, manage and monitor your application and data integration workflows (we call these pipelines). The metadata repository enables features like ?smart linking? and reusable Snap Patterns and other self-learning features.
- The ?data plane? is the work horse (we call our execution network the Snaplex). It respects data gravity and can run in the cloud, behind the firewall or as a native YARN application in a Hadoop cluster.
- Snaps are our connectors. They are for a wide variety of data sources, technologies, applications and APIs. There is also a Snap SDK that allows customers and partners to build their own Snaps.
This software defined integration model supports distributed deployments and delivers maximum agility to both developers and the business. We’ll dig into these iPaaS requirements in a future post. In my next post, I?ll talk about the requirement for a single cloud integration platform for Big Data, Applications and APIs.