Did you know you can get started with Intel Expressway API Manager on AWS Marketplace today with only a few clicks? You can have instant API Management and enhanced EC2 security for applications and services exposed from public or hybrid cloud environments.
The offering is available from Amazon to anyone with a valid Amazon account. If you haven’t tried Amazon’s AWS marketplace, you can have an instance of the gateway up and running in a few minutes.
Are you looking to mobile enable an Enterprise application need to expose an API? Are you looking to try a flexible DevOps model for cloud bursting? Are you looking to provide a centralized API governance, security and throttling layer for Enterprise applications? If so, Expressway can help.
Here are four things you can do today with Intel Expressway on Amazon AWS Marketplace:
1. Publish a Mobile Ready API
Here is the scenario – you have data you want to make available to an HTML5 mobile application, but it’s split up among different application services in your Enterprise environment. Each service sends its reply with different data formats, some are XML, some are JSON, and some are text, and becasue these services weren’t designed with mobile in mind, they send too much information. What you want is a mashed-up, filtered subset. Worse, authentication for this data is also based on different types of credentials, such as a username/password or Kerberos ticket.
You’ve considered custom development work to bring together these services to expose an API, and you’ve also considered trying to parse, transform and filter the data on the client, but you feel the app experience would be negatively impacted due to client performance. Each alternative is wrought with development costs. What to do? Expose the API through a gateway.
To test it out, you can load sample responses from your services directly into Expressway, and design a proof-of-concept in the cloud. When you are read to move to production you can either migrate your applications to the public cloud or stand-up a gateway in your internal network. To facilitate testing, you can also rely on mock-up services such as mocky.
2. API Data Protection & Compliance
Here is the scenario: Suppose you are using Amazon’s DynamoDB, a standard SQL database or another cloud-hosted Big Data solution. Your application collects personally identifiable information (PII) or PCI information for CRM or lead management and communicates using APIs.
You you want to ensure this data remains protected in the cloud, and more importantly, when it is made available to API clients, such as a smartphone or partner web service, the caller should only be able to view protected information if they have the proper authorization.
You need a way to enforce fine-grained compliance on API content. Worse, you want to enforce security in the same way, no matter what persistence technology you may switch to in the future. It’s SQL today, but it could be NoSQL tomorrow. What to do? Protect API content using a gateway.
In the previous example sensitive information such as a social security number, driver’s license, credit card, or bank account information can be encrypted and protected before it is stored in the cloud. Data protection is enabled by a pii protection policy in Expressway and inserted directly to the persistence layer using RESTful APIs or through the use of the Expressway Java extensibility framework.
Protection here means format preserving encryption which preserves the data type and output length of the original plain-text, minimizing application changes compared to traditional symmetric encryption which operates on padded octets.
Further, data can only be decrypted by the gateway layer and access is enforced using strong identity management, OAuth 2, X.509 certificates or 2-factor authentication, adding an additional layer of compliance to API content.
3. Extend Your ‘API Network’
Here is the scenario: You want to enforce API governance but don’t want to migrate all of your back-end applications to the public cloud. Or perhaps you want to migrate some back-end services, but not all. On top of this, you have to consider an efficient network architecture, which means network latency is an important factor. What to do?
In the previous diagram, the network design allows the Enterprise to immediately expose APIs with minimal application changes. The gateway is deployed in a VPC in a multi-homed configuration with a public IP address and an IP address in a private subnet connected through a hardware VPN. This means services can stay where they are.
The gateway acts as the enforcement and API exposure point (see the first use case), receiving API requests from mobile devices on the Internet that eventually route to services in the Enterprise Datacenter or in the Amazon Virtual Private Cloud (VPC).
This network architecture also provides improved client latency compared to a pure on-premise approach as additional network hops can be skipped compared to a case where the Enterprise has to expose an APIs through its DMZ.
4. Design an API Governance Layer
Here is the scenario: Suppose you have exposed a few APIs to support your mobile and partner strategy with some success. Perhaps you’ve exposed APIs directly by the smart use of open source frameworks such as Jersey, Microsoft, Node.js, RESTlet, or Ruby on Rails.
You’ve been successful with a handful of developers and have implemented security, throttling, authentication and API design with careful and deliberate project management. Now you need to scale from a handful of APIs to hundreds or even more. You need a consistent way to expose APIs with policies, not code. You need screaming performance and scale with built-in perimeter defense and application level denial of service protection.
Also, you need to ensure your APIs are available to the right developers at the right time to drive value throughout your organization. You also need API sharing. What to do? Design a scalable API Governance layer.
Here you can use the gateway and the examples described above as a design pattern for an API governance layer, which can be scaled in the Amazon cloud or in a hybrid architecture.
This means the API definitions, associated policies and the sharing of API definitions to developers is all handled at the gateway layer. You design your API interfaces independent of how the APIs are implemented. Today it could be a Microsoft .NET web service and tomorrow it could be Node.js. All of the security policies, API plans, authentication, data mediation and API sharing options are managed at the gateway. The gateway layer becomes the API consolidation point.
Intel provides both on-premise, partner and SaaS based API sharing options depending on your level of scale, control and security. The API sharing layer is available as an add-on component to the gateway, please contact us for more information.
How to Get Started
Want to see more? We’ve got a technical tutorial video here, the AWS API Tech Tutorial that runs through the sample application provided with the gateway and the offering is available from the link Intel Expressway API Manager link on AWS Marketplace.
It should be noted that some of the features above are enabled through the use of our visual policy editor, which is available at no cost to marketplace subscribers while others use the built-in policy editor available on the web interface.
Features that require the editor include Websockets, OAuth enablement, advanced protocol and data format mediation, database support & enterprise identity management. Please contact support to request the policy editor which is available at no extra charge to valid subscribers.