SUMMARY:
The key challenge that comes with the shift to using APIs as an extension of their enterprise IT is choosing the right deployment model. Here’s a look at some popular ones.
Enterprises are building an API First strategy to keep up with their customer needs, and provide resources and services that go beyond the confines of enterprise. With this shift to using APIs as an extension of their enterprise IT, the key challenge still remains choosing the right deployment model.
Even with bullet-proof technology from a leading provider, your results could be disastrous if you start off with a wrong deployment model. Consider developer scale, innovation, incurring costs, complexity of API platform management, etc. On the other hand, forcing internal developers to hop out to the cloud to get API metadata when your internal API program is just starting is an exercise leading to inefficiency and inconsistencies.
Components of APIs
But before we get to deployment models, you need to understand the components of API management, your target audience and your overall corporate IT strategy. These certainly will influence your decisions.
Not all Enterprises embark on an API program for the same reasons – enterprise mobility programs, rationalizing existing systems as APIs, or find new revenue models, to name a few. All of these factors influence your decisions.
API management has two major components: the API traffic and the API metadata. The API traffic is the actual data flow and the metadata contains the information needed to certify, protect and understand that data flow. The metadata describes the details about the collection of APIs. It consists of information such as interface details, constructs, security, documentation, code samples, error behavior, design patterns, compliance requirements, and the contract (usage limits, terms of service). This is the rough equivalent of the registry and repository from the days of service-oriented architecture, but it contains a lot more. It differs in a key way; it’s usable and human readable. Some vendors call this the API portal or API catalog.
Next you have developer segmentation, which falls into three categories – internal, partner, and public. The last category describes a zero-trust model where anyone could potentially be a developer, whereas the other two categories have varying degrees of trust. In general, internal developers are more trusted than partners or public, but this is not a hard and fast rule.
Armed with this knowledge, let’s explore popular API Management deployment models, in no particular order.
Everything Local
In this model, either software or a gateway that provides API metadata and traffic management are both deployed on-premise. This could either be in your DMZ or inside your firewall. This “everything local” model gives the enterprise the most control with the least amount of risk. This is simply due to the fact that you own and manage the entire API Management platform. The downside to this model can be cost. Owning it outright might cost less in the long run, but the upfront cost of ownership could be higher than other models because your Enterprise needs the requisite servers, software, maintenance, and operational expertise. However, if the API platform drives enough revenue, innovation and cost reductions, the higher total cost of ownership (TCO) can be justified with a quicker return on investment (ROI). This model serves internal developers best and helps large Enterprises that want to start with ownership and complete control of their API management infrastructure that can be eventually pushed out to a SaaS model.
Virtual Private Cloud
In this model, either software or a virtual gateway is deployed in a virtual enterprise network such as an isolated Amazon private cloud or virtual private cloud (VPC). Depending on the configuration, the traffic can either come to the DMZ or go directly to the private cloud. The traffic that comes to the enterprise DMZ can be forwarded to VPC and the VPC direct communication can be enforced based on enterprise governance, risk and security measures. A VPC deployment may be ideal for trusted internal developers and partner developers, and allows the Enterprise to experiment with elasticity. The VPC model with multi-homed infrastructure also allows API metadata to be accessible from the Internet, but done with a soft-launch and not a big-bang. As partners grow, the infrastructure can scale in the private cloud without the need to advertise the API metadata to every garage developer out there. This option gives the enterprise similar control as the local datacenter model deployment, but with a slightly elevated risk but more elasticity. 
Hybrid SaaS
In this model, the API traffic software/gateway is installed on-premise but the developer onboarding and public-facing API catalog (or portal) is deployed in a public SaaS environment. Though the environments are physically separated from each other, they are connected through secure back channels to feed information in a near-real time basis. Communication includes information flow from the API management catalog to the API traffic enforcement point which includes API keys, quota policies and OAuth enforcement. The API traffic management pushes traffic analytics, statistics, and other pertinent API usage information back to the SaaS public cloud.
This model provides for a good developer reach and scale, as developers can interact in a shared cloud instance while keeping the traffic flows through the enterprise components. Also, this model allows you to have a split cost model; the API metadata is charged as a service (without a heavy initial investment) and the data flow component is a perpetual license, giving the enterprise a mix of both benefits. The API traffic can still come to the enterprise directly without a need to go to the cloud first which will let the enterprise use components, thereby reducing some of the capital expenditure (Capex) costs. This configuration maximizes enterprise control and security and combines that with maximal developer outreach and scale with a utility cost model.
This may seem like the best of both worlds. Why even consider other models? In practice this model may be extended and combined with the others. For example, by adding a developer portal on-premise to better serve internal developers with improved latency and more IT-architect control. It’s not about exclusive choices, but about understanding the benefits of each of the interconnections.
Pure SaaS
This is the full on-demand model. In this configuration, both developers and the API traffic are managed in a multi-tenant SaaS cloud. In the pure SaaS model, API traffic hits the cloud first and is managed against Enterprise policies for quotas, throttling, and authentication/authorization. Analytics are processed in the cloud and the API call is securely routed back down to the Enterprise. The SaaS portal is skinned to conform to the customer’s branding, has the ability to integrate web content of the customer’s choosing, and is branded with URL of the customer’s choosing so that as far as the developers are aware, the portal is owned and operated by the customer.
Due to the fact that enterprises use the cloud elastic model in this case, both for scaling and for costing, the Opex prices can be multitudes cheaper than the heavy initial investment that might be required in the previous models. In one sense, this is comparing apples and oranges: In the opex model you trade the higher up-front costs of running and maintaining your own servers with a lower monthly fee, but as we mentioned before, there may be reasons for both: A large Enterprise may run a SaaS API program for their marketing department and an internal API management program for their IT department supporting a new mobility strategy. The SaaS API option maximizes developer scale and has the lowest maintenance costs. Plus, the enterprises will require fewer resources to run and maintain the deployment. This is the option best suited for having instant updates to the API management platform with minimal downtime and high performance through CDN caching and managed fail-over and resiliency
It is never one size fits all when it comes to API management. Each situation is different based on specific needs. Examine the different deployment options carefully, and see what will work best for you, keeping in mind that these deployment models are NOT mutually exclusive as you can combine them.
A
No comments:
Post a Comment