API Management

Apigee’s Top API Editorials of 2017

2017 was a big year for APIs.

They continued to solidify their position as the mechanism through which value is exchanged in modern economies, with literally quadrillions of API calls connecting apps, data, and systems throughout the world each day.

Apigee experts published dozens of editorials last year, both externally and via our Medium publication, to help developers, IT architects, and business leaders understand how to maximize the value of APIs and keep pace with constant technological change.

Here are some of our top articles from 2017, organized by some of the year’s biggest themes. Thank you to all of our readers, and stay tuned for more in 2018!

API management best practices

The nitty gritty details of API management can be challenging, but Apigee experts are here to help with their observations from the field. Be sure to check out “KPIs for APIs and Digital Programs: A Comprehensive Guide” by Michael Leppitsch and “Building an Outside-In Approach to APIs” by Chris Von See.

APIs and digital transformation

Virtually all companies understand the digital transformation imperative: if you don’t continually use technology to evolve your business, you’ll go out of business.

John Rethans explains why APIs are central to this imperative in his Forbes article, “APIs: Leverage for Digital Transformation.” And to explore why the technologies that businesses have been using for years are simply no longer good enough, read Brian Pagano’s “Legacy IT: Like a Horse on the Autobahn.”

To maximize the leverage John discusses in Forbes, APIs must be managed as products that empower developers—not as middleware. For details, see my article “How APIs Become API Products,” which includes real-world examples from Apigee customers Pitney Bowes, Walgreens, and AccuWeather.  

To appreciate the full scope of an API-first business evolution, check out “Lessons from Magazine Luiza’s Digital Transformation,” in which John interviews the CTO of one of South America’s hottest companies. And to understand where multicloud strategies fit into the mix, read David Feuer’s “Multicloud: Taming the Rookery.”

Caught up on how APIs are used today? For a glimpse into the future of digital transformation and the role APIs will play as new technologies emerge, don’t miss our article in Business Insider,How APIs are Key to Successful Digital Transformation.”


New software vulnerabilities and attacker techniques emerge on a daily basis, so security remained a leading concern for enterprises in 2017. David Andrzejek wrote two of our top articles on the topic. “Using Behavior Analysis to Solve API Security Problems” in Help Net Security examines how user behavior can be monitored in near-real time to identify suspicious behavior and block malicious actors, and “Grinch Bots are out to Spoil the Holidays” in VentureBeat explains how businesses can stop a trend that plagued many online shoppers last year: attackers who use bots to buy up the most in-demand, supply-constrained items.

Digital ecosystems

To adapt to shifts in customer behavior and the competitive landscape, a business doesn’t need to become a platform company, invent new machine learning technologies, or build loads of new software in-house. Instead, it should leverage what others have built to complement its own capabilities, reach new user groups, and explore adjacent markets.

Anant Jhingran and I discuss these ideas in our CIO.com articles “APIs, Ecosystems, and the Democratization of Machine Intelligence” and “Do You Really Want to be a Platform?” For a deep look at these ecosystem dynamics, including a set of simulations, check out Anant and Prashanth Subrahmanyam’s CIO.com article, “3 Golden Rules for Winning in Software-Driven Ecosystems.”

Industry trends

APIs are playing into business strategies in virtually all industries, but there are still scores of specific trends, use cases, and regulatory requirements from one vertical to the next. Some of our top industry-specific stories from 2017 included David Andrzejek’s “Why Haven’t More Banks Embraced Digital Platforms?” in The Financial Brand and Aashima Gupta’s “Voice Interfaces Will Revolutionize Patient Care” in VentureBeat.

Image: Flickr Creative Commons/Jlm Ronan

Creating Value from Data? Three Ways APIs Are Key

For the last half-decade, ever since terms like “big data” hit the mainstream, CIOs have been under increasing pressure to derive value from the vast amounts of data their organizations collect and generate.

The process was slow-going for several years as many organizations grappled with the reality that even an astronomically large amount of data isn’t useful if it’s not combined with the right technologies and assessed with the right use cases in mind. Some of these struggles persist, but after a few years of starts and stops, many enterprises have begun to embrace best practices for turning data into higher revenues, expanded brand reach, improved efficiency, smarter strategies — or in the case of particularly sophisticated organizations, all of the above.

One recent study, for example, predicts 40 percent of IT projects will create new digital services and revenue streams that monetize data. This particular approach to monetizing data isn’t the only way to generate value from data, of course. Companies can leverage data for better internal operations, for example, or to generate actionable intelligence to inform smarter strategic decisions. But the stat demonstrates the momentum building around specific approaches.

Though the uses cases are growing in number, one thing unites many of the common tactics: they’re all enhanced by, if not reliant on, robust API capabilities. Indeed, in many ways, if a company wants to build up its data capabilities, it needs to start by looking at its API capabilities.

Read the full story on Medium.

Image: TaxCredits.net

The Apigee Edge Platform: An Overview

Webcast replay

Learn about the Apigee Edge API platform, and how it securely enables the delivery, management, and analysis of APIs, data, and services inside and outside an organization.

In this webcast replay, we'll provide an overview of our Analytics Services, Developer Services, and Management Services, and walk you through a demo that illustrates how Apigee Edge simplifies management of the entire digital value chain. 


Which App Modernization Pattern Is Right for You?

Webcast replay

App modernization projects are hard. Enterprises are looking to cloud-native platforms like Pivotal Cloud Foundry to run their applications, but they’re worried about the risks inherent to any replatforming effort.

Fortunately, several repeatable patterns of successful incremental migration have emerged.

In this webcast replay, Google Cloud’s Prithpal Bhogill and Pivotal’s Shaun Anderson discuss best practices for app modernization and securely and seamlessly routing traffic between legacy stacks and Pivotal Cloud Foundry.

This session covers:

  • How to decompose a monolith into logical business domains
  • How to approach modernization using domain driven design
  • How API management can be used to modernize applications while keeping the business running



Simplifying Microservices Management

How Apigee and Istio can bring APIs and microservices together

If you base your IT technology strategy on what you read in the blogs, then you are already building your entire technology stack as a collection of microservices, built by “two-pizza teams,” running in containers, and deployed to the cloud using a container orchestration product like Kubernetes. There are a lot of good reasons to adopt such an architecture, from agility to resilience.

But if you’ve actually tried to follow through on all this, you probably discovered that it’s harder than it sounds. (For instance, what if you have team members who can’t or won’t eat pizza?)

But between pizza breaks, your teams are probably asking how a service in one container can locate another service, since the containers will be coming up and down all the time. Of course, there are facilities in Kubernetes for this, but they’re not enough.

What if one of the microservices is unresponsive from time to time? How do all the API calls between microservices remain encrypted in transit using the proper protocols and cipher suites? How do you control which microservices are authorized to talk to others, while preventing insiders from directly accessing sensitive data from their command line?

Building and deploying microservices is hard

After contemplating these problems and others, we realized that building and deploying microservices the right way is a lot of work.

That’s why, when Apigee joined Google last November, we were happy to learn that Google not only had solved many of these problems for its own services, but that Google has been working on an open source project aimed at solving these same problems for the rest of the microservices world.

So, we’re excited that today Google, along with IBM and Lyft, is announcing Istio, an open source project designed to ease the pain around connecting and securing a network of microservices.

Within Google, the Apigee team already runs a diverse set of services on a variety of platforms, and we’re expecting to deploy more. Istio will help us solve the very problem it’s being advertised to solve—making a mesh of microservices secure and reliable. But we think there’s a lot more to this project.

Most Apigee customers are talking about microservices, and many of our customers are adopting them. We expect that the presence of Istio in the marketplace will give them a great framework for building those networks of services. So we won’t be surprised when our customers ask us, “Will Apigee work with Istio?”

The answer is “yes,” and we’re working with the Istio community on exactly that today.

Microservices require API management

We feel that Apigee and Istio are a great fit. Istio is built with containers and microservices management in mind. The Apigee Edge API platform provides common visibility and management across both APIs and microservices for organizations of any size.

For instance, within a single Kubernetes cluster—and even with Istio helping mediate—an unreliable or slow microservice can drag the SLA of an entire application down along with it.

The kinds of sophisticated analytics that the Apigee platform provides can help administrators and product managers see these kinds of issues and react to them before it’s too late.

Once services are used beyond a single team and outside a single cluster, a different set of API management capabilities are necessary. For instance, by enforcing API quotas, an API product team can help control how much load a particular team can place on the whole collection of microservice.

Apigee is used by many organizations to enforce these types of quotas, allowing API teams to dynamically adjust how much API load is consumed by each organization who uses an API.

And, when services are exposed outside the corporation, capabilities like security based on OAuth, intelligent threat detection, and “bot” detection become important. Often, services exposed outside the organization won’t be adopted unless the API team uses a platform like Apigee Edge to enable developers to learn about and access APIs quickly via self service.

In short, we feel that the microservices movement is creating an explosion in the number of APIs in the world—and in the end, that makes API management tools even more important.

For that reason, we’re excited to be working on integrating our suite of API management tools with Istio—including our open source, software-as-a-service, and on-premises products.


Experian: Security, Agility, and Simplicity with APIs

“I’m very much looking forward to the day when I can look at the Experian portfolio of applications and we’ve modernized the entire portfolio of externally facing applications and we can drive the pace at which we can innovate much more quickly.” -- Experian CIO Barry Libenson, Computerworld, March 2017

The leading information services company took a big step toward fulfilling Libenson’s vision when it adopted an API-first strategy and implemented an API platform.

In a recent conversation, Experian’s vice president of strategy Alpa Jain explained how API management not only grants the company the agility and flexibility to quickly create new products, but also provides both the security required to protect and manage consumer credit data and a facade that masks the complexities of disparate back-end systems.

Experian offers data and analytical tools to help businesses manage credit risk, prevent fraud, target marketing offers, and automate decision making.

A key business for the company is empowering consumers to check credit reports and credit scores to protect themselves against identity theft. Managing credit data to enable these services requires top-notch security, Jain said.

“We have invested a tremendous amount of dollars over the last three years to continuously improve our security posture,” Jain said. “The API management layer helps us add that additional layer of security that’s needed.”

The ability to offer a range of secure and innovative products would be severely hampered without a platform that effectively masks the complex environments, disparate data repositories, and siloed processes that exist among Experian’s several business units, she said.

“API management … helps me focus my time and efforts on the consumer and the clients,” Jain said. “It takes away all the heavy lifting from an IT perspective behind the scenes.”

Another advantage of API management, Jain added, lies in how it facilitates the use of microservices to piece together new products and services in unexpected ways.

“We can now take APIs and break them up into little pieces,” she said. “Internal and external users can pick and choose what they want to use and how they want to leverage it to create different product sets and different solutions that add more value.”

New segmentation tools, methods of marketing products to consumers, and ways to help consumers monitor ID theft—all can arise by enabling microservices, Jain said.

“Innovation can happen at all different levels.”

How to Get Started Using the New Apigee Edge Experience

New video series

Last year, we unveiled a brand new approach to designing, developing, and publishing APIs using Apigee Edge. Thanks to the Edge platform's APIs, the new Apigee Edge experience sits on top of the same great platform that that powers the "classic" Edge experience but adds several enhancements, particularly in the areas of API design and publishing.

To help you get started using the new Apigee Edge experience, we're rolling out a video series, available at: https://docs-new.apigee.com/videos.


Two-minute overview: this provides a quick look at the new Apigee Edge experience and highlights what’s different from Classic Edge.


Design your API: Plan the interface you'd like to expose to consumers, and describe it using the OpenAPI Specification format. The new Apigee Edge experience includes a spec editor to make it easier to write and manage your OpenAPI specifications.


Publish your APIs: Using the new Apigee Edge experience, you publish your APIs to enable app developers to access and use them from your portal.

Stay tuned! More videos will be posted soon to help you navigate through all phases of the API lifecycle using the new Apigee Edge experience.

RMark Bio: Why We Adopted an API-first Approach

In 2015, rMark Bio, Inc. set out to build a deep learning and analytics platform for the life sciences industry. Today, applications running on the CoRE Platform deliver real-time insights of global health data and prioritize strategic partnership recommendations for life science organizations.

To build our initial minimum viable product, we had four primary goals:

  1. Consistent access to global healthcare data
  2. Consistent access to customer health data
  3. Exposure to evolving insights and analytics
  4. Agile learning models that could be modified without disrupting application developers

Our platform needed be pliable enough to adapt to the changing needs of our clients and the changing accessibility of healthcare data. We decided to use an API-first development strategy in order to meet our goals. By launching our new features as microservices with API access, we could stitch together key portions of our application without having to wait for the complete development of the platform’s other components.

Watch my recent presentation with Apigee's Anant Jhingran at Google Cloud NEXT '17

Once we decided to focus on developing our API first, we knew we needed a third-party solution to help us build and support our APIs, and eventually manage the monetization. Partnering with Apigee enabled us to meet all of our needs while providing a unified interface to support our platform and services.

There are several advantages we realized by choosing to build our API in parallel with the complete application. An API-first strategy made it simple for us to optimize, extend, and even replace services of our application as needed. This meant any future developmental efforts could occur independently from one another, and it forced us to thoroughly document and test our processes from day one. Further, opportunities to monetize select data services also became apparent early on due to our API-first approach.  

Like all startups, we had our fair share of challenges to overcome. Building our API first meant much of our early conversations centered on congruity of interfaces as much as they did on product features. Orchestrating all of the various moving parts proved to be yet another hurdle we would have to face, one that required careful organization and coordination. With the Apigee Edge platform, we were able to securely resolve these challenges while quickly scaling our services and applications.

In order to keep up with the dynamic needs of our customers, rMark Bio needed to hit the ground running as soon as we entered the market. Working together with Apigee not only gave us the tools to deploy a modern API in the cloud, but also provided us with insight into our performance and the ability to expand our platform when needed. As a startup, using an API-first strategy was critical in bringing our product to market to meet the immediate demands of life science companies and their employees.

Jason Smith is CEO and cofounder of rMark Bio, Inc., which was recently named one of the 10 most disruptive AI companies in Chicago. He's a leading-edge technologist and product executive with over 19 years of industry experience. Jason has held positions in early-stage companies, large multinational corporations, and venture capital incubators, and has driven the licensing of a wide variety of technologies and IP in the fields video, graphics architecture, processor design, and security.

Walgreens, API Management, and the Evangelist's Tool Belt

It’s hard to find a better example of a traditional business that has embraced the API economy—and seen tangible results because of it—than Walgreens. Whether through its Photo Prints API or its rewards and prescription refill APIs, this leading pharmacy store operator has successfully built an array of digital services with an important question in mind: What’s in it for developers?

This “outside-in approach” has paid off in measurable and impressive ways. One of the clearest measures of the success of its APIs: a customer who visits a Walgreens store because of a digital interaction (say, the prescription refill app or an online coupon) spends six times more than a customer who just walks in.

So it’s clear that Drew Schweinfurth, Walgreen’s developer evangelist, has an important role to play in the success of the Walgreens API program, and how that translates into the success of the business.

We recently spoke with Drew about the impact API management has had on the Walgreens business and the critical role it plays in enabling him to do his job.

What was it like at Walgreens before and after implementing API management?

The before and after transition is drastic. When you look at the original way of doing APIs, services, architecture, and management, you maybe have a couple documentation pages or PDFs that are passed around internally to different business leaders and developers.

There’s no real security piece in there either. You have these services you make available only to certain environments inside of your system, right? Exposing those blows the minds of business leaders, who are saying, “Oh I thought we were only giving this to internal people?”

That’s where API management comes in. You say “OK, get your external developers set up with an API key. Have them come in to use your services that are setup through proxies in this API management software and bring them back in to hit the services that your team has built internally.”

Tell me about the “6X spending metric” that Walgreens’ digital program is so well-known for.

Customer X comes into the store, and they know what they need and are going to buy. When we bring them in through our convenient services, whether it’s a photo print, a prescription refill, Balance® Rewards for Healthy Choices, rewarding them with Balance® Rewards points, or even a digital offer like a coupon click—we see them spend six times more than we would have with them just walking into the store. This is a result of the convenience provided by the digital service.

Customers come in for the prescription and then buy Band-Aids, they buy the candy, they buy the soda pop, they buy anything else that we sell in our stores six times as much as they would’ve just walking in. This is really exciting for us because it’s grown not only the value of our store, but it’s grown the value of the API program which provides all these services.

What’s next for Walgreens’ API program?

The ecosystem has had a new service or product added to it every single year. So we started with photo, we went to prescription, we then went into a microservices approach. Rewarding customers for making healthy choices was the third year. This last year we started looking at the retail product space.

We had the digital offer service that allows customers to clip coupons directly to their Balance® Rewards card. In the next year we’re focusing more on that retail product space: looking at how we can utilize the services we’ve built internally to make things like a product search API or product inventory API, allowing developers access to build apps that allow their/our customers to see what exactly is in our stores. I think it’s a really amazing space for us to approach this year.

Explain how Walgreens views and uses microservices.

Microservices are a new way of thinking about service oriented architecture. In the past, you had these giant systems where it’s SOAP requests being passed back and forth between each other and one of the things we focused on is making our services as light as possible and easy to develop on a small infrastructure.

With our Balance® Rewards for Healthy Choices service, we said there are a lot of different moving pieces involved with our loyalty and rewards systems. Everything including patient information associated with their pharmacy account. We said, let’s just scrap this whole idea. Let’s build an OAuth login service that allows customers to log in through third-party applications and connect their account with that application using an access token.

The developer can then make POST requests on behalf of the activity data that’s happening inside of the third party’s application, in turn giving the customer Balance® Rewards points for allowing that connection to happen and any healthy activities that customer makes with their connected device/application. That service in itself, just being a tiny request to send over my step data, send over my blood glucose data, or my blood pressure data and then giving the customer Balance® Rewards points is how we look at building a microservice.

Walgreens is really an amazing story, being a 115-year-old company that has built an industry-leading digital platform. How did it start?

With Walgreens, it’s how do we bring that value back into business models that might not be valid anymore. You have a lot of disruption in the technology space—photo is one of those. If you look back at 2008, we had smart phones. Smartphones came out with a camera on them. People weren’t taking their cameras with film and bringing them to Walgreens stores as much.

We banked on that and said: "Alright, let’s disrupt our own photo business. Why bring the customer into the store twice when they only need to be in there once?" So we built a photo experience allowing developers building apps for smartphones to kind of play into that create, edit, share, or store photos space and connect to Walgreens to print out those photos so we could make a better customer experience for that photo customer.

It’s also a better experience for a developer who says, “I’m building an app. I need to bring in revenue, why don’t I call the Photo Prints API by Walgreens to get that revenue”—and now we’re bringing value back into that photo business and helping grow a third-party ecosystem.

Being on the cutting edge of technology and making sure that we aren’t killing our business is really a big challenge that I think API management has immensely helped out with. I think disrupting yourself is something that you need to do. There’s lots of companies out there that are not technology companies. Long-time companies like Walgreens that have been very successful in the way the economy and society have used their business or their products.

There’s a lot of technology companies now who are coming out of Silicon Valley building things where traditional business models break in older institutions. I think there has to be a fear, an internal fear, that these guys could potentially beat us. So why don’t we focus on breaking our business model and disrupting ourselves to bring value back into our business?

How important is API management to a developer evangelist?

Developer evangelism requires not only a certain attitude toward life and how business works, but also having the appropriate tools you need in order to make developer evangelism happen.

Looking at API management tools—being able to track analytics on your proxies and your endpoints, then getting that information to the business lines where they can say, “Hey, we see the developers are hitting our refill prescription endpoint a X times a second" [enables] the business leaders to say, “Oh wow, that’s actually bringing value into our business.”

Every single one of those requests that comes in is a prescription that gets refilled in our stores, and on top of that, we know that it’s six times the norm being spent by this customer which came in through that channel. Being able to find those stories and using the tools API management software can give you to tell those stories is very crucial.

Drew (in his own words) is a self-proclaimed geek with a passion for mobile and a hard-coded background in web development. He stays motivated by moderate amounts of bacon, beer, and beautiful cities (he claims Chicago is the best). At Walgreens, Drew manages developer relations for the Walgreens API team and also serves as the editor-in-chief of developer.walgreens.com. In the last year he has also taken up the responsibility of developing proof of concept web services and APIs for Walgreens.

Apigee Edge Private Cloud 17.01 Is Here!

We’re excited to announce the general availability of Apigee Edge for Private Cloud 17.01. This release includes several features that help you better control and secure your APIs, standardize deployment, enable reusability of existing infrastructure components, and make it easy to manage developer apps.

Shared flows and flow hooks

Shared flows let you operationalize functionality in API proxies. By combining conditionalized policies and resources into a shared flow, you can reference the shared flow from any API proxy to execute single-source, reusable logic. For example, a shared flow might verify the API key, protect against spike arrests, and log data.

Flow hooks let you attach these shared flows at key enforcement points (pre-proxy, pre-target, post-target and post-proxy) within the API proxy lifecycle. This make is easy to enforce some common compliance and security requirements such as OAuth, threat protection, traffic management, and logging across all API traffic without having to rely on the API developer to do that in each and every proxy. See additional details about this feature here.

Encrypted key value maps

Key value maps (KVMs), which were already an Edge feature for long-term persistence of key-value pairs, can now be encrypted for stronger data security. You can now store service accounts, system credentials, or any secure information to access third-party APIs.

Encrypted KVMs are encrypted with an Apigee-generated AES-128 cipher key. Just like regular KVMs, encrypted KVMs are scoped. They can be scoped at the “organization,” “environment,” or “apiproxy” level.

Multi-data center API BaaS

API BaaS provides developers with access to a flexible data store and enables you to quickly integrate valuable features into your app, including social graphs, user management, data storage, push notifications, performance monitoring, and more.

In the past you could only install API BaaS in a single data center. With this release, API BaaS can be deployed in multiple data centers. Any data collection that is created automatically gets replicated across the different data centers. With this, BaaS can be supported in a active-active configuration and provides higher levels of availability.

RPM-based install for the developer portal

In previous releases you had to download and install the developer portal from a tarball. But now the Developer Services portal is installed from RPMs, using the same repo and tools as Edge and API BaaS. This means the admins can use  the same process for deploying the developer portal as they use for installing rest of the Edge components. It makes for a seamless installation experience.

Fewer components

The Developer Services portal now uses Postgres (used for analytics) as its database and Nginx (used as a router) as its web server. Customers upgrading to 4.17.01 from a previous version continue to use MySQL or MariaDB (for all new installations, the portal uses Postgres as its database instead of MySQL and MariaDB). New installations also install Nginx as the web server. Customers upgrading to 4.17.01 from a previous version continue to use Apache.

Developer apps

Developer app management in the Edge UI has gotten more powerful, thanks to several enhancements. You can revoke and approve apps (in edit mode) in a new "App Status" field. API key expiry dates are now shown on the Developer App Details page, and keys are organized by expiry dates in a "Credentials" section. Additionally, you can generate API keys with specific expiration times or dates (or with no expiration).

Other improvements

  • You can now display a consent banner when a user first accesses the Edge UI. The consent banner displays HTML-formatted text and a button that the user selects to proceed to the log-in screen.
  • We have updated versions of Cassandra and Qpid.
  • When you create a "pass-through SOAP" proxy based on a WSDL, Edge hosts the WSDL and creates a flow in the proxy to let you access it. You can access the hosted WSDL at http(s)://[edge_domain]/[proxy_base_path]?wsdl, which is the new service endpoint URL for clients calling the SOAP service through the proxy.
  • We added “data for average transactions per second” (average TPS) to the main proxy traffic dashboard. In addition, when you hover over individual data points on the proxy traffic and proxy performance charts, TPS for that time interval is displayed in the tooltip.
  • This release also contains a bunch of bug fixes. Some examples include “Intermittent errors (such as SNI errors) on JavaScript service callouts,” “Invalid URL parsing returns a 500 status with ApplicationNotFound,” “SOAP WSDL passthrough operation name issue,” and “Error in creating node.js API Proxy when Enable Cors option is selected.”

How to upgrade

We strongly encourage customers to upgrade to this new release as soon as possible. You can update Apigee Edge version to 4.17.01. If you have a version of Edge previous to version 4.16.01, then you must first migrate to version 4.16.01.x and then update to version 4.17.01.

Hope you’re as excited as we are about this new release. There’s a lot more to share than what can fit in here; additional details can be found in our release notes. We strongly encourage customers to try out these new features, ask questions, and provide feedback on the Apigee Community.