Welcome!

@CloudExpo Authors: Liz McMillan, Zakia Bouachraoui, Yeshim Deniz, Pat Romanski, Elizabeth White

Related Topics: @CloudExpo, Java IoT, Microservices Expo, Containers Expo Blog, @DXWorldExpo, SDN Journal

@CloudExpo: Article

API Management – Anyway You Want It

You need to understand the components of API management, your target audience and your overall corporate IT strategy

This article originally appeared on Gigaom.

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

conceptarch_01v2

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

conceptarch03

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

conceptarch02

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

conceptarch04

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.

When we built our API 2.0 platform, by combining Intel and Mashery solutions, we took all of the above into consideration. Not only will we not limit you to a specific deployment model, but also will we help you transition between deployment models with ease.

We just recently announced the combined solution, API 2.0 platform that combines our strengths. Check us out at cloudsecurity.intel.com.

EverythingLocal Virtual PrivateCloud Hybrid SaaS Pure SaaS Custom Built
Initial cost

$$$

$$

$$

$

$$$

Ongoing costs

$

$$

$$

$$$

$$$

Level of Control

High

High

Medium

Low

High

Risk & CompliancePosture

High

Medium

High

Lower

High

Flexibility

High

High

Medium

Medium

Medium

Scalability

Medium

High

High

High

Low

Ideal for

Internal/Partner

Developers

Internal/Partner

Developers

Public/ Partner

Developers

Public/ Partner

Developers

Mostly Internal

Cloudification

Not Offered

Built-In

Partial

Built-In

Maybe

 

The post API Management – Anyway you want it! appeared first on Application Security.

More Stories By Blake Dournaee

Blake Dournaee is currently the product manager responsible for Intel SOA products. As a product manager at Sarvega, he was deeply involved in the development of their flagship XML security, routing and acceleration appliance products. He was a specialist in applied cryptography applications at RSA Security and was a frequent speaker at many RSA conferences throughout the US and Europe. Dournaee is an established author who wrote the first book on XML Security and co-authored SOA Demystified from Intel press.

More Stories By Andy Thurai

Andy Thurai is Program Director for API, IoT and Connected Cloud with IBM, where he is responsible for solutionizing, strategizing, evangelizing, and providing thought leadership for those technologies. Prior to this role, he has held technology, architecture leadership and executive positions with Intel, Nortel, BMC, CSC, and L-1 Identity Solutions.

You can find more of his thoughts at www.thurai.net/blog or follow him on Twitter @AndyThurai.

CloudEXPO Stories
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next-gen applications and how to address the challenges of building applications that harness all data types and sources.
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed by some of the world's largest financial institutions. The company develops and applies innovative machine-learning technologies to big data to predict financial, economic, and world events. The team is a group of passionate technologists, mathematicians, data scientists and programmers in Silicon Valley with over 100 patents to their names. Big Data Federation was incorporated in 2015 and is ...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by researching target group and involving users in the designing process.
CloudEXPO New York 2018, colocated with DevOpsSUMMIT and DXWorldEXPO New York 2018 will be held November 12-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI and Machine Learning to one location.