API Management

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. 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 4.16.09.0x 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.

Building the Connected Airport with APIs

SFO's enterprise architect discusses digital transformation

"Digital transormation is a required course, not an elective, for airport operators."

But, as a Boston Consulting Group report explains, a passing grade won't be easy for even the most tech-savvy airports. It requires the digital orchestration of many constitutents and partners: airlines, vendors, security, taxi and rideshare services, and, of course, travelers.

"The airport is like a small city," said Isaac Inkumsah, enterprise architect at San Francisco International Airport. "What it's going to take to scale our services delivery capability to support that entire infrastructure is going to be quite massive."

We spoke with Inkumsah about what's required to help SFO become a "connected airport"—one that improves the passenger experience, increases operational efficiency, and boosts revenue, all via digital technology.

A key to accomplishing this at the scale required for an organization like SFO? APIs and API management.

"We want to be an airport that responds quickly, and with agility, effectively to our passengers, in terms of security, travel experience, and so on," Inkumsah said. SFO aims to break the old landlord-tenant relationship that airports have with airlines and become more of a data broker between the airport, airlines, passengers, and other consitutents. 

SFO is off to a good start; it has developed API-driven solutions to monetize rideshares and optimize taxi queues. But with 30,000 employees and 50 million passengers per year, the airport requires technology that enables the simple and fast sharing of digital services, at scale.

"We expect a fully connected airport to be completely running on services in the future, and APIs are going to be a big part of that," he said. 

Autodesk: Opening New Revenue Streams with APIs

Autodesk has been synonymous for decades with industry-leading 3D design software—but if the shift toward mobile devices and the cloud has shown anything, it’s that marketplace incumbency doesn’t guarantee future success.

That’s why Autodesk has committed itself to digital reinvention, not only moving its award-winning software to the cloud but also investing in APIs to enable new, data-driven revenue streams.

Autodesk’s digital strategy is “really about connecting our data that’s coming out of applications with the downstream consumers,” Autodesk director of PaaS strategy Shawn Gilmour told us recently.

These users include people who might consume, review, model, or visualize design information but aren’t actual users of Autodesk’s full applications. The company’s API platform, built on Apigee Edge, represents an opportunity to integrate these tangential users into the company’s ecosystem.

APIs facilitate this goal because they easily and securely expose Autodesk’s infrastructure, services, and data to developers. This enables both internal and external dev teams to more agilely leverage Autodesk resources for new apps. Some of these apps enrich the experience for existing users, while others extend the brand’s services into untapped markets.

Gilmour said these new apps—and the APIs that enable them—help Autodesk become central not just to design itself but also to the way people work together on design projects.

To many customers, “collaboration became critically important,” he explained. Typically, these collaborators need only partial insight into a project. Just as most of us need weather forecasts but don’t invest in meteorological equipment, these collaborators require some of the application’s data but won’t buy full software suites that cost thousands of dollars.

By charging these people less money for just the resources they need, Autodesk extends its base to include not only professional designers but also their collaborators.

“The problem was the data was created by a proprietary desktop tool that not everybody was going to spend $5,000 or $10,000 to buy,” Gilmour said. “So one of the key things we were trying to do is let anybody get access to that design data for things like design reviews, collaboration on change orders—things that might happen during the design process.

“With our API, [we] open up that ability for others to start consuming that design information,” he added, “which means for us, we now have a completely new customer.”

2016: The Year in Review

2016 was a great year for Apigee, and, more importantly, our customers. We introduced more than 90 new features to Apigee Edge and issued over 150 bug fixes via 35 public cloud and three private cloud releases. We open-sourced our mobile application performance monitoring solution. We added new solution accelerators. We processed over one billion API calls per day, and maintained 99.99% uptime. We even received some high praise from Gartner and Forrester.

Here’s a quick look at many of the new features our customers employed to accelerate their digital businesses.

Security

We introduced several features to help customers tighten down the security screws on their API programs.

Two-factor authentication

At the API administration level, Edge now provides two-factor authentication in both the UI and the management API. Additionally you can lock down management API calls with OAuth 2.0 (using acurl), making it easy to invoke management APIs without repeatedly requiring credentials.

Encrypted KVMs

We've also added important security features at the messaging and API proxy development layer. Encrypted key value maps (KVMs) let you securely persist sensitive data, retrieve data at runtime with variables, and keep sensitive values from appearing in trace and debug sessions. See this October 2016 blog post for details.

Adaptive bot detection and protection

Apigee Sense provides protection from a number of different bot patterns. The new Sense Protection feature completes the “CAVA” (collect, analyze, visualize, and act) lifecycle. It enables an Apigee Sense customer to act on detected abuse and selectively stop abusive API traffic.

Productivity improvements
  • Logs sent to third-party message logging services including Splunk, Loggly, or Sumo (using the message logging policy) can now be securely sent over TLS/SSL.

  • API credentials, developers, and developer apps can now be managed through the management UI. Users can generate multiple key/secret credentials for an app, control key expiration, and assign different keys to different products—all in a single screen. This simplifies API key rotation, where a newer API key replaces an older API key set to expire.

  • Users can also revoke credentials using a cascading model. For example, you can deactivate a developer, revoke a developer app, or revoke individual API credentials.

  • When controlling access to specific API resources through API products, users now have more flexibility when defining valid resource paths with wildcards..

Governance

We added some powerful capabilities to cater to our customers’ governance and compliance requirements. To enable standardized governance of API proxy functionality, shared flows enable executing a group of policies (OAuth, spike arrest, and message logging, for example) consistently across all proxies. Flow hooks let you reference those operational behaviors before or after the proxy execution in the request and response. (See this October 2016 blog post for details).

Reliability and scale

We added several continuous reliability and performance improvements under the hood. We switched to the Nginx router for better API traffic performance (for both public and private cloud deployments).

For public cloud deployments, in 2016 we began releasing product updates using "blue/green" deployments--where a small amount of traffic is initially routed to the updated product so that we can monitor for potential issues (read more in this September 2016 blog post).

We also added support for automatic scaling in Apigee Edge Cloud. This helps maintain availability and enables customers to scale capacity up or down automatically based on policies. This has helped us deliver a more predictable API platform.

Developer productivity

In 2016, we spent a lot of time working to make API lifecycle management more intuitive and powerful—from design to development to publishing to analytics.

 
Integrated OpenAPI editor and spec repository

"New Edge," released in October, offers a new model for API proxy development and documentation. You can use the integrated editor by creating an OpenAPI specification to define your API, without leaving the Edge UI. You can generate an API proxy directly from the spec, create an API product, generate API documentation, and immediately publish it  to the New Edge developer portal. The new spec repository enables collaboration of OpenAPI specs and fosters team-based, iterative API development. Read more in this November 2016 blog post.

New API proxy editor

The API proxy editor in the management UI became easier to use by including full XML views of API proxy configuration, search, more options for adding policies, endpoints, and scripts, as well as an analytics dashboard that shows proxy performance. Regarding proxies that interact with SOAP services, the proxy builder evolved to provide even stronger support for SOAP passthrough messages by hosting the service WSDL in Edge, as well as more reliably generating policies that handle RESTful calls to backend SOAP services.

Proxy chaining and policy enhancements

Another cool enhancement we delivered is called proxy chaining. It lets you call one proxy from another proxy directly without having to call it via its HTTP/S URL. The platform does it for you. This saves a lot of time, particularly when the proxy being referred to changes.

Other notable proxy development enhancements include refactored policy error codes, deploy-time validation of proxy bundles to catch issues before runtime, new JavaScript crypto functions, providing more control over converting XML to JSON arrays, and improved rendering of JSON payloads generated by policies such as Assign Message and Raise Fault.

On-demand, lightweight developer portal

With New Edge, there's virtually no lag time between creating your API proxies and giving developers API documentation. A new lightweight portal framework lets you instantly provision  multiple developer portals, including API documentation that's automatically generated from your OpenAPI specs. You can use HTML/Markdown to create pages and add CSS styles on the fly for complete control over styling and layout. And we provide a new type of samples framework that lets users browse different types of Edge samples, deploy them, and learn more about them without leaving the UI.

Self service

Several customers wanted a more holistic view into their adoption and usage of the platform, so we delivered a broad set of information via Apigee 360. It offers a view of account information accessible through the Edge single sign-on,  including monthly API traffic volume, statistics for apps and developers, availability percentages, Edge features used and purchased, support cases and statistics, and server information.

We also rolled out a new mechanism, Apigee Advisory, to display messages in the Edge management UI. These advisories inform customers of availability and security issues that could impact their APIs.

Our web site, apigee.com, also underwent a significant redesign that provided clearer, more comprehensive information about Apigee products and solutions, as well as improved discoverability of our thought leadership content.

Business impact and reporting

A modern and scalable analytics platform was launched in 2016 built on big data technologies. This new architecture makes it easy to handle high traffic throughput, enable a variety of data queries (by time, tenants, applications, developers, clients, plans, and products), and provides flexibility to build new data-driven applications.

There was also a fundamental change introduced in the means of delivering the daily email digest. Rather than pushing out an email with all the report content, users now receive short summaries along with links back to the full report.

Finally, for customers who have APIs that record custom attributes using the Statistics Collector policy, they can request the creation of custom aggregation tables that can improve the query performance for those custom metrics if they are used on a regular basis to generate analytics reports.

For customers using monetization, several enhancements provide more control over charging models and notifications when users get close to (or exceed) their plan limits.

These enhancements include:

  • A new adjustable rate notification plan that enables a user to set different plan limits per app developer
  • Support for webhooks to notify developers and companies when they near or exceed their plan totals, as well as support for several different conditions under which notifications are triggered, including a new criterion based on combined transaction totals
  • A tool that migrates developers into the monetization framework (for users with an existing non-monetized developer ecosystem who later decide to use monetization)
  • A new API that lets users suspend and unsuspend developers (to support stronger control of developer participation)

Edge Private Cloud

The on-premises version of Edge got several improvements, including a simpler, more RPM-based code-with-config installation and upgrade framework, which enables easier product installation and upgrade with fewer errors.

A new monitoring tool lets on-premises customers understand the health of various components (routers, message processors, ZooKeeper, Cassandra) as well as HTTP error codes for various orgs and environments in their deployments. The tool lets customers take a snapshot of their dashboard data and share it with Apigee to help resolve support incidents.

 
 

Partner ecosystem

We continue to demonstrate our commitment to multi-cloud and cloud native deployments. Integration with Pivotal Cloud Foundry was a big focus area for Apigee in 2016.

The first new enhancement was Pivotal Cloud Foundry integration with Apigee Edge (public or private cloud) using the route services feature, which enables developers to use Apigee Edge as a Pivotal Cloud Foundry Service. The Apigee Edge service broker (see more details in this May 2016 blog post) approach brings simplicity and consistency to the range of services that customers typically use when developing apps.

More recently we announced the general availability of Apigee Edge Microgateway on Pivotal Cloud Foundry. This complements the previous release by providing a hybrid deployment option which is suitable for low-latency use cases.

We also announced Edge integrations with Amazon AWS (this enables users to proxy AWS apps and services such as AWS Lambda), Microsoft Azure (this enables users to deploy the Edge Private Cloud) and Google Cloud Platform (this enables GCP customers to use Edge Cloud for their API management needs).

Community and learning

The Apigee Community continues to be very active. We’ve have received great reviews from developers about our 4mv4d (four-minute videos for developers), which demonstrate how to use Edge policies, implement error handling, and much more.

Our product documentation received several additions and enhancements, notably a set of documentation for the New Edge release. The Private Cloud documentation also emerged from behind the firewall and joined our publicly accessible cloud docs.

Our docs team added deeper set of API development samples, redesigned tutorials for speed and ease of use, upgraded navigation and search for easier content discovery, and translated key sections of the cloud docs into Japanese. You can see more detailed lists of doc enhancements throughout the year in the Apigee Community.

Apigee Edge got to where it is today thanks in large part to our community and customers. As many of you know, we became part of the Google family. We look forward to an exciting 2017 and expect to do more amazing things for our customers as part of the Google Cloud Platform team.

Join us at our Adapt or Die World Tour stops in Sydney on Feb. 8 and London on Feb. 23, and in San Francisco at Google Cloud Next '17, March 8-10. 

 

Arity: Building an Ecosystem with Data and APIs

Twenty billion miles of data from a million drivers. 

Leading insurer Allstate knew it had a crown jewel in the information it had gathered from six years in the connected car business. But how to best turn these valuable insights into a business platform?

The answer: create a technology spin-off imbued with an API-first philosophy. 

Arity was born last year to create rich insights into how safe drivers are—via telematics, big data, and analytics—and offer them to partners via APIs. APIs and API management are essential to scale quickly and begin building an ecosystem that requires integrating with other large financial services companies’ complex infrastructures, said Arity president Gary Hallgren.

“API management is extremely important to the success of our business,” he told us recently. 

The young company aims to offer its unique insights into accident-prone traffic areas to companies like Google-owned navigation app Waze, Hallgren said. But it's a two-way street, Hallgren adds. Arity also plans to incorporate information from mapping or weather companies to improve it’s ability to show which roads are safest to drive on. API management makes this data exchange fast, easy, and scalable, he said.

“We know we can’t do this alone.” Hallgren said.

API Best Practices: Managing the API Lifecycle

New eBook: Design, delivery, and everything in between

As businesses evolve into digital businesses, the technology stack is advancing, too. Enterprise application architectures are evolving from integration-centric enterprise service bus (ESB) architectures to application-centric, microservices, platform-as-a-service (PaaS), multi-cloud, and API-driven architectures.

APIs are the lynchpin to the success of these digital businesses. All applications use APIs to access application services and data through APIs. These services can be microservices, cloud workloads, legacy SOAP services, or IoT. To ensure that applications and developers can effectively use these services to build partner, consumer, and internal apps, companies need to deliver secure, scalable, easy-to-use modern APIs.

Over the last few years, we’ve participated in hundreds of enterprises’ API-led digital transformation initiatives. The new eBook, "API Design: Managing the API Lifecycle," distills our learnings from these customer engagements and shares best practices about managing APIs across the lifecycle.

Download this free eBook today!

 

HP's APIs: From Tactic to Strategy

A key product for the newly independent HP Inc., the computer, printer, and graphics business of the former Hewlett-Packard Co., is PrintOS, a print production operating system that offers web and mobile apps for HP print press and graphics users. As HP's Evan Scheessele describes it, PrintOS is “essentially an API product.” 

As such, it’s “one of the first, most prominent API products that our company has deliberately offered,” said Scheessele, HP's platform architect and engineering lead for cloud-computing practices and business delivery.

The importance of PrintOS elevates APIs from a product delivery tactic to a key strategy, Scheessele said.

“APIs are now becoming an essential part of the product story,” he said. 

With the prominence of APIs in HP's strategy, API management has become a key way to help teams within the company adopt new interfaces to build new platforms, and do so quickly, without the need to learn the ins and outs of different services.

“Where you can automate things, you can test them faster, which means you can release them faster, which means you have more business agility,” Scheessele said.