How to effectively build a hybrid SaaS API management strategy
February 1, 2014 1 Comment
Summary: Enterprises seeking agility are turning to the cloud while those concerned about security are holding tight to their legacy, on-premise hardware. But what if there’s a middle ground?
If you’re trying to combine both a legacy and a cloud deployment strategy without having to do everything twice a hybrid strategy might offer the best of both worlds. We discussed that in our first post API Management – Anyway you want it!.
In that post, we discussed the different API deployment models as well as the need to understand the components of API management, your target audience and your overall corporate IT strategy. There was a tremendous readership and positive comments on the article. (Thanks for that!). But, there seem to be a little confusion about one particular deployment model we discussed – the Hybrid (SaaS) model. We heard from a number of people asking for more clarity on this model. So here it is.
Meet Hybrid SaaS
A good definition of Hybrid SaaS would be “Deploy the software, as a SaaS service and/or as on-premises solution, make those instances co-exist, securely communicate between each other, and be a seamless extension of each other.”
Large enterprises are grappling with multitudes of issues when they try to move from a primarily corporate datacenter to an all-out-in-cloud approach. Not only that is not feasible, but also it will result in wasting millions of dollars in sunk costs invested in their current datacenter.
The current NSA actions have muddied up the public cloud safety, further undermining enterprise control over applications and data in the cloud. Yet, the pressure to have a mobile first, a cloud first or some API-centric model means enterprises must move some operations to the cloud.
So enterprises are trying a hybrid model to entertain the seemingly contradictory need for agility and security. In doing so, most organizations are building two different flavors of the same services leading to different silos. Obviously the cloud version is more geared towards fast, easily provisioned, low cost and the self-owned data center version would be geared more towards complete integration with existing eco-system. Often, this leads to two different silos.
Most software versions today don’t support Hybrid SaaS because they are not designed to operate both as a service and/or as an in-house install. A true Hybrid SaaS model allows you to install components that operate in both places with similar (if not the same) functions. In addition, there will also be a connector that allows the continuous integration between the components to make this seamless.
Some savvy organizations are intelligent enough to build the consolidated hybrid API model that we have seen.
One API, Expose Anywhere
The ultimate goal is to publish APIs to the right audience with the right enterprise policies, right amount of security, and just the right amount of governance. The motto here is scale when you can, own what you must. What is the right amount for you? It depends on who your developers are, where your APIs are located now, and what sort of security and compliance requirements you have.
The concept of One API is to publish and be available in multiple places, accessed by multiple audiences (internal developers/applications, external developers, and partners) and be available for multiple channels (mobile, social, devices, etc.). All demand a different experience, which is where the hybrid model really excels.
So how does it actually work? In a hybrid API management deployment the API traffic comes directly to the Enterprise and the API metadata is available in two places: on premise and in the cloud. The API metadata available from an on-premise portal is usually targeted to an internal developer.
Here the metadata and API documentation might be slightly different – an internal developer may require a different response format (XML for instance) for integration with internal systems and have a different access mechanism (API keys or internal credential) compared to an external or zero-trust developer. In this case this means that API traffic never goes to the cloud or any developer portal for that matter – this is often a point of confusion in the hybrid model.
Metadata that is available in the cloud would be described differently and use common standards for access such as OAuth and JSON, with rich community features to encourage the adoption of APIs. While the endpoint information is advertised in the cloud, the traffic itself is sent directly to the Enterprise datacenter, with policies enforced by an API gateway. Also, the UX and the registration process is lighter and faster to attract wider audience.
Hybrid SaaS API Management
This allows a number of different benefits for the Enterprise – they have increased control over the API definitions they choose to advertise to external developers and zero-trust developers can interact in a shared cloud that provides API metadata for a collection of APIs – public developers can sign in once and get access for a set of useful tools. Further, runtime traffic enforcement is always handled by the Enterprise, providing full visibility into API transactions as well as the API responses themselves.
The hybrid model is implemented through policy retrieval and the pushing of analytics data: API key, endpoint configuration, and access policies are defined in either developer portal and pulled down and cached by the API gateway. On the push side, analytics information is sent both portals for analytics. The hybrid design allows Enterprises to take one API and deploy it anywhere with maximum security and control.
Talk to us to find out how Intel can help you build such solutions. Intel/Mashery has the most mature API solution in the market, and has helped over 100+ companies realize their dream.