An interesting trend is gathering steam. SaaS vendors are trying to extend their services to the enterprise infrastructure (aka “behind the firewall” applications) by offering connectivity to their cloud services by means of API integration.
3 questions arise:
- Why would SaaS vendors try to connect to the old on-premise world?
- Why would they do that using API integration (e.g. literally forcing their customers to hand-wire it)?
- What is the best way to extend cloud services to on-premise and behind the firewall applications?
Some context:
When enterprises began adopting SaaS applications, security concerns arose. Cloud security vendors (CASBs, gateways, brokers..) emerged to provide enterprises with a measure of security and control over public SaaS applications.
As time went by, enterprises increasingly adopted the cloud, building and deploying enterprise applications in private and public clouds. These applications were/are provided as a service, but only to the enterprise’s users (employees, contractors etc.).
Some people call them “cloud applications” because they are staged and run in the cloud. This created confusion between these applications and SaaS applications. The confusion has recently exasperated as they are become known as “enterprise SaaS” and “IT SaaS”.
Let’s put things in order.
SaaS (e.g. salesforce) and “enterprise SaaS” are NOT the same
It’s all about ownership and control:
- If it’s owned and controlled by someone else (i.e. NOT by the enterprise), and is publicly available to all, it’s SaaS.
- If it’s owned and controlled by the enterprise, is located behind the enterprise firewall and available only to the enterprise’s users, it’s “enterprise SaaS” (even if it’s run on AWS or Azure).
SaaS is not driving enterprise applications to extinction
Not every enterprise application is destined to become SaaS.
For many reasons (security, compliance, special customization) not every application that can be sourced as SaaS, will be sourced as such. Enterprises do not easily surrender their data and resources to external service providers.
Many legacy enterprise applications are moving to the cloud. But enterprise applications running in private or public clouds are the same good old behind-the-firewall enterprise applications. They just changed location and form of delivery. Nothing else has changed.
Cloud computing revived the life of enterprise applications, allowing internal applications to be delivered as a service. It also created a thriving DevOps scene. DevOps means one thing: MORE enterprise applications.
Cloud services at large, SaaS in particular, were not designed to provide services to enterprise applications behind the firewall
SaaS applications were designed as integrated service platforms to accommodate many users (and other SaaS applications) coming in to them. They were not designed to build pipes and connectors to environments that are not cloud-based.
But the “behind the firewall” market is huge. Actually it’s still much larger than the SaaS market. So how do SaaS vendors meet that temptation? — provide APIs to integrate to behind the firewall infrastructure…
About APIs and cloud services
API integration means letting the enterprise customer hand-wire the cloud service to its internal IT. Obviously, this is not a scalable model. Worse: It means MORE complexity. APIs do not simplify life (or costs) for IT staff.
APIs are by nature insecure.
API integration means the enterprise exposes its internal services to external (and thus untrusted) entity. APIs are poking holes in the enterprise network. So they require the customer to add another layer of security — API security — to the already too-complicated and hardly-manageable IT.
But cloud is all about LESS wiring and less IT complexity, is it not?…
So what is THE way to integrate native cloud services into behind-the-firewall environments?
In order to do that, one has to have a footprint in the enterprise network. A footprint which is minute enough to be easy, simple and painless to set up, yet advanced enough to increase simplicity, flexibility and security.
As a matter of fact, at Soha we did just that.