API Management

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.

Pitney Bowes: How APIs Boost Development Speed

Producing new apps that tap into Pitney Bowes' wealth of data is a key part of the company's "commerce cloud"—its cloud platform that provides a range of solutions, analytics, and APIs. 

But it was a slow, laborious, and costly process before the Stamford, Conn.-based company implemented an API management platform, said senior vice president of technology and commerce James Fairweather. The act of connecting apps to back-end systems involved a drawn-out integration process that had to be repeated over and over, he said.

“By building a common way to integrate applications to our back office, we’ve dramatically accelerated the speed to market and lowered the investment per product,” Fairweather said. “We had programs that would have taken 18 months to get to market. It’s four or five months now.”

Just getting internal developers up and running has sped up dramatically, he added. With an API management platform in place, no longer do they have to deal with figuring out installations or interfaces. 

“There’s a clean site, internal developers go to that site, they get provisioned against a capability, and they start consuming it,” he said. “We manage it in one place, with excellence across all products.

“It’s a huge acceleration for us.”

A less tangible effect that APIs and implementing API management have involves the way partners view Pitney Bowes’ technology competency. Partners are a key part of the company’s strategy—and enable Pitney Bowes APIs to be used in ways never imagined within the corporate walls, Fairweather said.

Without API management, however, integration issues again became a challenge, because very specific domain expertise was required to organize and respond to partner requirements—and all of this takes time, Fairweather said. It painted a picture of Pitney Bowes as a “digital laggard.”

“By having APIs in place, you’re having a conversation about the technology and solving the problem much faster with partners,” Fairweather said. “They see you as a digital leader.”

Philips HealthSuite: The API Platform as Accelerant

When Philips Healthcare markets its new cloud-enabled platform of devices, apps, and digital tools, this platform’s ability to offer smart, meaningful, and seamlessly connected health solutions and experiences is a key message.

But there’s another critical piece of the Philips HealthSuite Digital Platform story that’s helping to propel it to the cutting edge: speed of delivery. And an API platform is the key accelerant, according to Dale Wiggins, general manager of the HealthSuite platform.

API management enables developers who create digital tools for HealthSuite to focus less on technology logistics and more on doing what they do best: building innovative health data apps for the patients and consumers seeking digital solutions to their healthcare needs.

“Each new developer doesn’t have to worry about re-learning that same exercise over and over again,” Wiggins said. “We don’t have some group coming in with some great new idea about how they’d like to do API management.

“As we often say, ‘A platform eliminates a degree of freedom,’ and that can really help in terms of time to market.”

In other words, the simple consistency that an API platform helps speed new digital products to market quickly, Wiggins added.

“It’s a consistent way to provide security, it’s a consistent way by which we can monitor what’s going on in the system,” he said. “That consistency of approach really allows our developers to bring new functionality to market very quickly.”

API Best Practices: Managing APIs Across the Enterprise

New slides

APIs are the lynchpin to the success of digital businesses.

They're critical to evolving enterprise application architectures. All apps use APIs to access application services and data through APIs. These services can be microservices or cloud workloads or legacy SOAP services or IoT.  

Companies need to address challenges that arise in this evolution by managing APIs holistically across the enterprise. It's important to design and build APIs with a focus on ease of use for app developers, consistent security policies, automated testing and deployment, and analytics to gain better insights into API usage and performance.
 

 

Over the last few years, we’ve participated in hundreds of enterprises’ API-led digital transformation initiatives. These slides distill our learnings from these customer engagements and shares best practices about managing APIs across the lifecycle.

Download the slides to learn more.

Microservices Done Right

New eBook: Microservices Need API Management

Is your company scaling up its applications by breaking them up into smaller pieces, and deploying on cloud? Are you sharing and reusing services widely across the organization and outside—well beyond the development team you scrum with? If you answered "yes" to these questions, you've got microservices.

When you’re talking about sharing services, you’re talking APIs. All microservices have APIs. But companies have struggled with security, with a lack of visibility into usage and performance of the microservices APIs, and with building agile microservices for clean reuse.

Managed microservices are the solution; companies are making strategic investments in API management platforms for their microservices success.

In the eBook, "Microservices Done Right: Microservices Need API Management," learn about why and how enterprises need to manage their microservices—in the same way that they manage their APIs.

Download it now.

 

 

 

API Governance in the Enterprise

Webcast replay

An organization's API management program will not be successful without governance. The key to the governance of API management—like any IT system—is people, process, and technology. However, at the same time, the process can't be cumbersome and over-bearing.

Robert Broeckelmann, principal consultant at Levvel, and Apigee's Dino Chiesa discussed the process of implementing API management in large enterprises. They shared will share how to:

  • define API governance
  • explore the goals, requirements, and implementation of API governance
  • look at lessons learned from implementing one enterprise customer's API governance process

 

API Best Practices: Microservices

How to ensure the rush to microservices doesn’t create silos with inconsistencies

In a previous post, we discussed best practices in API security. Here, we’ll cover the important role an API platform plays in managing microservices architecture.

Nearly 70% of organizations claim to be either using or investigating microservices, and nearly one-third currently use them in production, according to research from NGINX.

Why? Because microservices enable businesses to innovate faster: development teams can independently develop, deploy, and scale components of large applications. The adoption of the cloud, containers, and continuous integration/continuous deployment (CI/CD) tools has made microservices implementation much easier, leading to more and more modern software being built as a set of microservices.  

App development teams implement microservices using a variety of microservices stacks like Kubernetes, Netflix OSS, and Mesos, depending on their needs. All these microservices use web APIs as the mechanism to communicate with one another.

There’s a challenging side effect, however. As app development teams rush to implement microservices, they inadvertently create silos with inconsistencies in security, visibility, documentation, and governance. Many of the APIs that connect microservices are not secured consistently across the organization.

They might not be accompanied by standardized documentation, or access control mechanisms. These microservices and associated APIs are often difficult to reuse, analyze, or even to discover for use by other teams.

How do organizations wrangle with this problem?  Many organizations implementing microservices use API management platforms to deliver consistent security, visibility, and improve discovery and reuse of microservices and APIs.

Secure and monitor your microservices

When it comes to security, there should be no distinction between internal and external APIs. A microservice could be used by another app in the cloud today and an external partner tomorrow. Teams implement APIs with varying levels of security. Some deploy microservices in the public cloud, neglect to deploy common API security standards or consistent global policies, and expose the enterprise to potential security breaches.

Companies like TrustPilot and Autodesk assume a zero-trust environment for microservices. They use API platforms to implement security and governance policies like spike arrest, injection threat protection, and OAuth2 across all of their microservices APIs.

Transition to microservices transparently

For many who adopt microservices, initial projects involve decomposing existing monolithic applications into microservices. Often, many applications take advantage of services from your monolithic apps. So transitioning to microservices has to be done in a way that’s not disruptive to other applications and developers using the monolith’s services.

Magazine Luiza, a fifty-year-old retailer in Brazil with more than 700 stores and 43 million customers, created a modern API facade with an API platform to deliver modern (RESTful, cached, and secured) APIs for the monolithic app’s legacy SOAP services and to  securely expose the new microservices. This enabled mobile and web app developers to keep innovating despite the underlying transition to microservices.

 

Remove barriers to consumption

As app development teams implement microservices with disparate runtimes and tool environments, it can be difficult for other teams to discover and reuse these microservices.

Organizations like Autodesk use a developer portal to enable internal and external developers a single place to easily discover APIs, access interactive documentation, consume microservices, and measure performance and usage.

Gain insights into microservices usage

Without data about the usage and performance of microservices in an organization, it’s difficult to get the full benefits of this architecture. The problem is especially acute when microservices are used by other teams in a large enterprise or as external APIs for partners and customers.

Trustpilot uses out-of-the-box, fine grained analytics and reporting capabilities available in an API platform to measure API usage, developer and partner engagement, microservices adoption, and traffic composition. Organizations use API analytics to monitor API performance by analyzing total traffic, throughput, latency, and errors.

Manage APIs beyond microservices

Beyond microservices implementations, organizations tend to have many APIs that expose legacy services that are used by variety of apps. These APIs might have inconsistent security,  limited (or a lack of) API documentation, poor version control, and limited reusability.  All of this leads to confused developers and reduced agility—the very opposite result you expected from employing microservices.

Organizations like Belly, Autodesk, and TrustPilot use API management platforms to not just manage microservices APIs, but all of their APIs. A distributed API management platform enables you to deploy and run your APIs close to your application and microservices environments, while enforcing consistent security and governance policies across all your APIs. This approach gives you a single pane of glass to monitor and manage all APIs across microservices and other monolithic apps.

Organize for success: Beyond technology

Organizations that have successfully executed microservices projects have also adopted modern software development practices.

Two-pizza teams are small, independent, and cross-functional, and they focus on delivering just a few microservices. This approach was championed by Amazon and proved to be useful in ensuring effective communication within the team and driving agility. Netflix has more than 500 microservices delivered from more than 30 independent teams.

Agile/scrum methodologies deliver functionality faster rather than the lengthy waterfall development processes. As the pace of arising business needs has increased significantly, agile scrums enable IT to deliver software that better satisfies those needs.

Continuous integration / continuous delivery processes and tools help organizations benefit from microservices. This makes it easy to independently deploy microservices. Amazon, for example, deploys code to production hundreds of times of day.

Using microservices, innovative organizations have found a path to enjoying the agile benefits of building software fast, while enabling the reuse of shared services. Getting started the right way requires a consistent security, visibility, and discoverability framework using an API management platform.

To learn more, read the Apigee eBook, "Maximizing Microservices."  

Developers Who Use Their Own Products Build Better Products

I have always admired Google :). The company delivers kick-ass technology, but it also delivers a kick-ass experience. Take Google Docs. Instant changes, no “Oh crap, I forgot to Ctrl-S, I am screwed.” I’m typing this in a Google doc. While it’s not the only reason (or even the main reason), I do believe that an important reason for Google’s quality is that Googlers use their own product, and they’d never let an embarrassment go out.

Contrast this with enterprise software. I have built database technologies for decades—yet, for a long time, I never used it (I mean really used it, as opposed to testing or demoing it). This is true for tons of enterprise software technologies. The developers who build it and the developers who use it are not one and the same.  

What about open source software like Cassandra? Isn’t it built out of needs, and aren’t the developers who build it the developers who use it? Only partially. Apps use databases. Database developers build databases, whether it’s DB2, or Cassandra. Neat architecture, pretty bad user experience.  

Technologies that work well are technologies that are built and used by the same developers. No ifs, ands, or buts about it.

That brings us to what I am doing now. I am immersed in microservices and API management. There are some things our developers will never have a good feel for. SAML 2.0 for connecting to SAP R/3? How could a developer in a 300-person startup have that intuition?

We have to call upon general product management, security, and enterprise software knowledge to build something that we hope is functional and usable, and then have a good feedback loop. The developer building the technology and the developer using the technology are different.  

But microservices and APIs are different. We produce software for other folks to deploy APIs on. How do we do it? With small teams that aspire to the right set of microservices principles. With clean APIs. Each service needs to scale up and down.

The deployment of these services can have errors, so we have to implement the right blue-green deployment infrastructure. Teams are independent, so they need clean APIs, with documentation as contracts between them. Our developers employ microservices and API best practices. The software they build is a reflection of what they need, day in and day out.

Whenever you evaluate software, ask the vendor: “Do your developers use it?” It will help you make better decisions.

Image: The Noun Project/Kevin Augustine LO

L.L.Bean's API Journey: Digital Commerce Done Right

Webcast replay

APIs are a critical part of how leading retailer L.L.Bean creates powerful digital experiences for its customers across mobile and online channels.

In this webcast, L.L.Bean’s Kristopher Kleva walks us through the company’s digital commerce API platform, and explains how APIs enable the century-old company’s multiple marketing, retail, and big data systems, in addition to supporting its multiple mobile apps and mobile web site.

Join us to:

  • learn about the state of retail APIs in 2016
  • gain tools and tips to accelerate your digital commerce initiatives
  • walk through a demo of Apigee's Commerce APIx solution

 

 

Why Apigee Auto-Scaling Matters

API demand is unpredictable. Apigee helps you scale appropriately.

Shankar Ramaswamy (our head of engineering) and Anant Jhingran (our CTO) will introduce key new features of Apigee in this engineering blog channel. We'll typically have a co-author—a key member of the team that made it happen. We can’t wait to discuss the awesome things we're doing for our customers.

We run a complex cloud infrastructure at Apigee, with hundreds of paid and tens of thousands of free and trial customers, all on shared, multi-tenant infrastructure that supports their API management needs. Our customers’ API needs are diverse—and while the law of large numbers tends to smooth out variability within our customer base, it still is the case that the workload of any one customer varies tremendously.  

There are two patterns of variability that are pretty common:

The pattern on the left represents “flash sales.” While not very common, they contribute to a significant uptick in load, and, if we don’t scale up and down appropriately, result in wasted capacity and money being donated to Jeff Bezos. The pattern on the right is very common (daily and weekly variations) and might result in 50% wasted capacity if not scaled up or scaled down appropriately.

As an Apigee customer, why would you care? You’re most likely paying by call volume* (the area under the curve) and not by peak. There are two reasons why this matters to you:

  1. A better experience As we detect load increases, we scale it for you. You don’t have to watch, inform us, create a support ticket, whatever. Over time, for predictable increases (like the flash sales on the left in the image above), you can even self-service an increase in capacity in anticipation of the sales.
  2. Cleaner whitelisting for the backends A big reason to avoid auto-scaling is that now new IPs will pound on the backends, and your security teams will disallow them. However, we’ve introduced a NAT (network address translation) layer, which pushes the scaled MPs (our API run time workhorses) one level behind—so backends only see NATs, and these NATs need to be scaled up and down much more slowly. So now you get whitelisting that is stable, and auto-scaling that is transparent. Win-win :).

We are rolling out these changes for our cloud customers now—soon, all of our customers should have auto scaling groups transparently.

Welcome to another benefit of Apigee’s cloud-native architecture.

 

*This applies to customers on the current licensing model only. Legacy license model customers can contact their account representative or sales@apigee.com.