APIs at Red Hat Summit: Day 3

Application programming interfaces (APIs) let organizations expose and reuse services both internally and externally—making behavior more consistent and code more long-lasting.

In Paul Cormier’s day one keynote, Keith Babo, lead product manager of Integration with Red Hat, showed how APIs can be measured and managed, easily turning an expense into a potential source of revenue with transparent policies and processes. New Infrastructure-as-a-Service (IaaS) tools also make API integration something a non-engineer can do, which may further increase their adoption. Babo’s demo shows you how to take your API from selection, to containment, to deployment. Watch how you can use 3scale by Red Hat® to track the progress—and the success—of your API program.

But that was just a glance into how useful APIs can be. Sessions later in the week explored the motivations, strategy, and processes used by successful API projects and some of the profitable results in practice.

API WHY
Vanessa Ramos, product manager for 3scale and Christina Wei Mei Lin, tech evangelist for Middleware with Red Hat, joined forces to talk about the reasons organizations are flocking to APIs and the ways they could—and should—implement them.

 
Organizations use APIs to gain:

• Agility. APIs and modularity let you iterate and improve your applications fast.
• Innovation. Opening up an API can spark internal innovation. When you’re ready, use it to collaborate externally.
• Awareness. When you open up, you can reach more people.
• Revenue. Monetizing APIs is a new source of revenue. And everyone likes money.

HOW TO BUILD APIs AND INFLUENCE PEOPLE
“APIs are products,” said Vanessa Ramos, “no matter if they are internal or public. They should have a roadmap, a business plan, and organizational support.”

Both Ramos and Lin emphasized the need for APIs to be created within a defined life cycle. “The key to running a successful API program is constantly asking if the APIs are performing and contributing to the business as we envisioned,” Ramos said. “You should constantly be improving through the life-cycle phases.”

A typical organization should have a life cycle with five basic phases:

1. Plan and design
2. Build, integrate, and deploy
3. Operate and manage
4. Share and engage
5. End-of-life (EOL)

Phase 1: plan and design
In the first phase, the most important task is to determine what the users of your API want and need. Lin said, “What it all comes down to is: Do you know your API consumer? Do you know what they want to do? Do you know their goals?”

One of the first things you need to know about your users is what language they want to speak. The Open API initiative works on a vendor-neutral, industry-standard API description format (based on the Swagger specification for describing RESTful APIs).

Once you’ve got agreement on the language front, you can start thinking about how you (and your users) are going to work. Lin recommended a web-based, open source, code-optional application called Apicurio, which is based on github and lets users design APIs collaboratively.

Phase 2: build, integrate, deploy
Before moving into build-stage recommendations, Lin gave a stern warning:

          integration =/= management

“Don’t mix up your integration API code with your management API code,” she said. “Spaghetti code!  I hate it.”

Building code in a modular way helps keep these two tiers separate, and separation helps keep complexity at bay. All composing services and transformations should live in the integration tier, while authentication and authorization processes are management.  

Then Lin introduced Red Hat JBoss® Fuse, which she uses to package code into container images automatically using a Maven plugin. By packaging apps in containers and microservices, the apps stay small. And small apps last longer, are easier to update, and make it easier to isolate any failures.  

Phase 3: operate and manage
Once you’ve got an API written, you have to figure out how to get it going, safely. Unsecured APIs directly access your API endpoints, making the backend accessible from outside. A layer of management in between protects the backend and gives the provider full control of what happens behind the gateway.

Management also offers:

• Access control that lets you authenticate traffic, restrict by policy, drop unwelcome calls, generate overage alerts, and impose rate limits.
• Usage policies grant appropriate access to different parties or for different environments. For example, you might want to only offer expensive resources to your production environment.
• Traffic analytics lets you better understand the consumers you have, what APIs they are using, their traffic patterns, and other sources of data. Once you know these things, you can fine-tune your APIs accordingly.

Phase 4: share and engage
Lin then showed the interface analytics screen from Red Hat 3scale API Management as she talked about the kind of seamless developer experience you need to build. To make your API offerings attractive to potential users and customers, you must:

• Make it clear what the API does.
• Let people sign up immediately. (Don’t make them wait—they won’t come back.)
• Provide access that is free (at least initially).
• Be transparent about pricing and trial policies.
• Create useful documentation.
• Create a useful developer portal. (3scale offers one out of the box.)

 
Lin emphasized how a useful developer portal can really affect adoption. “This is not only for your typical developer evangelist, but in this case it might include others within and without the organization who can promote it.” A successful portal, like the Oxford Dictionaries API, can be customized to appeal to even more casual users.

Phase 5: EOL
It seems odd to think about the end of a project when you’re just beginning it. But when planning your APIs, that’s what you must do. Proper retirement and change management means that you can avoid the problems associated with aging interfaces and sprawl.

However, keep these things in mind as you plan for the sunset of your APIs:

• Big changes mean retirement. Carefully consider whether changes you make are breaking or non-breaking. When you remove an endpoint, or drastically change how much data an API provides, you can overload or disrupt your users. Starting over is usually smarter.
• Create a communications and migration plan. Clearly communicate with your customers. Give them plenty of time to make plans of their own.
• Honor contracts and API terms. Violate the trust of your users, and you will no longer have them.

API STRATEGY
Red Hat’s Manfred Bortenschlager works with customer companies to help establish API strategies. “Sustainable API success,” he said, “only comes from a well-crafted and well-executed strategy for the API.”

Before talking specifically about APIs, Bortenschlager discussed strategy and the changing market trends that breed the demand. “All digital initiatives are already underway or will be enabled by application programming interfaces.” Many things feed into the demand for digital transformation, including:

• Growing mobile access and improving mobile user experience.
• Communication channel expansion from just a few channels (face to face, phone, and website) to many (those plus text, email, and multiple affiliates or partner channels).
• Lack of control over communication channel enablement and management.

The lack of control over communication channels is a problem that can be solved with API management.

When Bortenschlager works with a customer, he starts with three strategic questions:

1. Why do you want to implement APIs?
2. What concrete outcomes do you want to achieve?
3. How do you plan to execute the API program to get these outcomes?

And he identifies which of the six use cases apply:

1. Mobile and Internet of Things (IoT) support
2. Customer ecosystem
3. Partner ecosystem
4. Content and transaction channel
5. APIs as a business (charging for the API directly)
6. Internal agility

Some customers target more than one use case at a time, and certain patterns or progressions are common. Amsterdam Airport Schiphol, for example, started with an internal adoption (6), then expanded to include partners (3). Their next target was mobile (1), and in the future they plan to do more with customers (2).

Seven best practices for creating APIs:

1. Focus on the value of the API.
2. Create a clear business model.
3. Design with the user in mind. Make it simple, flexible, and easy to adopt.
4. API operations are critical.
5. Create a valuable, useful developer experience.
6. Marketing is critical.
7. Plan for retirement and change management.

All of Bortenschlager’s recommendations about APIs and API strategy can be found in the book he published on the subject, The API Owner’s Manual.

AMSTERDAM AIRPORT SCHIPHOL
Mechiel Aalbers, senior solutions architect at Schiphol, took the session stage with the solutions architect from Red Hat and an integration specialist from Rubix that helped the airport use APIs to share data with the airport community.

“It all starts with ambition. We want Schiphol to be the best digital airport in the world by 2018.” - Mechiel Aalbers

Schiphol requires high levels of automation to handle 65 million passengers and more than 50 million pieces of luggage. As one of the 5 busiest airports in Europe, that’s an awful lot of data. Schiphol wanted to create smart services that maximized their reach to customers, brought in new revenue, and (most importantly to Aalbers) triggered innovation.

Schiphol, already a Red Hat customer, first wanted to create an API gateway. After a hackathon exploring possible solutions, they selected 3scale for the technology and their flight API as the first test project. After creating a RESTful API and testing it with select customers, they had their first API. The process took about three months, and the API was hosted on the same system that held the airport’s critical data.

"They asked themselves: Is this flexible enough? Is this really the future-ready solution we want? When the answer wasn’t an immediate yes, they got back to work."

Schiphol took the project even further, building requirements that included a true hybrid cloud environment, a mature container platform, and systems and processes that supported DevOps culture.

With help from Red Hat consultants, Schiphol used Red Hat JBoss Enterprise Application Program (EAP) (and its associated tools) to rewrite the original API, and to migrate it to Red Hat OpenShift Container Platform. Its developer portal is now live and available to the public.

Schiphol plans to take their API project even further with management and automation additions. Eventually their goal is to have the critical flight info running on-premise in an OpenShift cluster. For this airport, the sky is truly the limit.    

APIs FOR EVERYONE
With so many organizations looking for ways to better collaborate with partners, customers, and users, it’s no surprise that opening up APIs has broad appeal. Though sharing in this way is not without risk, by using consistent tools and approaches, adhering to standards and best practices, and planning strategically for the complete API life cycle (including its end) will help you build beneficial and useful APIs.

Learning from the experiences of other customers—which is what Red Hat Summit is all about—can help you make the most of this (and every) opportunity.