API Management

Belly Up to the Microservices Bar

Why Belly, a leading rewards plan provider, needs API management

If you’ve ever walked into a store and seen a rewards program displayed on a tablet at the checkout counter, there’s a pretty good chance that it is powered by Belly. The loyalty and rewards plan provider, which was recently featured in TechCrunch for its mobile marketing suite, employs API management to build mobile APIs from legacy services and newer microservices.

We recently spoke with Belly’s director of platform Darby Frey to learn about the technology that lets Belly “Move fast and not break things.”

In the first part of this series of short videos, Darby explains why Belly needed an API management platform.

Belly faced several challenges in building mobile APIs from legacy services:

  • Its architecture consists of one legacy monolith and many new smaller microservices.
  • Moving to microservices introduced lots of operational complexity.
  • Mobile apps need to consume microservices efficiently.

Belly’s architecture had a single Rails app in front of microservices, and it didn’t scale or perform particularly well. All of this set the company on the path to find a robust, scalable API management platform.

In the next post, Darby will discuss why Belly needed an API management platform for its microservices.

Advanced Security Extensions in Apigee Edge

Webcast replay

In this webcast replay, Apigee's Dino Chiesa and Vinit Mehta demonstrate Apigee Edge's advanced security features. All of the implementations are shown in Java. 

In this session, Dino and Vinit demonstrate:

  • how Edge can generate or validate JWT
  • how to generate or validate JWS signatures
  • how to encrypt and decrypt using JWE

 

Bootstrapping: Improving Apigee with Apigee

As a grad student at U.C. Berkeley, I was blown away when I read that the C compiler is written in C. Seriously? Since then, I came across many, many more examples: again, as a grad student, I learned that tables in a relational database are themselves described as tables, so the language (SQL) to access database information could itself be used to access the metadata. My head spun.

It’s a very powerful concept—one unique to computer science, maybe—though I am sure existential philosophers could and do tie themselves in knots on this concept. When I look at the sky and wonder in awe about how this beauty came about, I’m drawn to the bootstrapping argument, and, at some point, have to give up thinking about it.

Similarly, in computer science, bootstrapping can’t be extended back to t=0. Niklaus Wirth wrote the Pascal compiler in FORTRAN, even if later Pascal compilers could be written in Pascal.  Reductio ad absurdum, maybe? Okay, I'm mixing too many metaphors, but having fun nonetheless.

When I came to Apigee, I had the fortune of sitting next to Greg Brail (and I still do)—a man of brilliance if there ever was one. As our chief architect, he created the product that we sell today. One fine day, he observed: “We should use our own product to improve our product.”

I said, as you might have guessed, “Seriously?” And then I said, “Aha—you mean ‘bootstrap ourselves?’”  He said, “Whatever—instead of theorizing, just listen to my ideas.”  So I did.

We (he, really, but, because I‘m telling the story, I have inserted myself into it) considered the fact that we tell our customers to manage their APIs with us. Because our product is nothing but a set of APIs (deploy a proxy bundle, create a user, and analyze the traffic through a set of REST calls), why don’t we use our product to manage these APIs?

As we considered that question, we realized that the benefits would be the same as for our customers:

  • We can describe the APIs in OpenAPI (formerly known as Swagger).
  • We can mediate them and change their syntax to have uniformity across all APIs.
  • There’s consistent security.
  • We can create API products for partners.
  • We have clear visibility.
  • We use features like throttling, traffic management, and monetization (based on what the customer has purchased).

So now, our APIs are managed by an org called apigee-internal. We get all the benefits that you get when you use Apigee as your org.

Sweet, right? Bootstrapping to the rescue.

Thank you, Greg!

Modernize SOA with APIs

Webcast replay

Service-oriented architectures were not built to handle the demands of a modern, digital organization. In this webcast replay, you'll learn how one large enterprise modernized its distributed SOA by deploying Apigee Edge Public Cloud. The existing infrastructure manages SOAP, XML-based services, and some REST APIs built on an IBM integration stack (including WebSphere and DataPower).

Consultant Robert Broeckelmann Jr. joins Apigee's Dino Chiesa to discuss lessons learned from deploying an API management solution in a large enterprise, including:
  • the architectural justifications
  • requirements and use cases
  • best practices for modernizing your SOA architecture

 

 

APIs: The Only Fast, Affordable, Scalable Path to Digital

Build digital with the right foundation

What does it mean to be a digital business?  It means delivering the seamless connected experiences demanded by today’s customers, partners, and employees. It means securely unlocking the value that companies have already built in their data and systems of record. It means doing it all with app store speed and agility and internet scale.   

The only way to forge the path to digital quickly, scalably, and in a cost-effective way is with APIs. They make it possible for developers to build and connect the experiences and apps we use every day and unlock the value of an organization’s data and assets.

See how Apigee’s intelligent API platform enables businesses to build, secure, manage, scale, analyze, and connect all their APIs and build the foundation for a company’s digital future.

 

API Management: It's a Twofer!

APIs need to be managed. So that’s the first problem API management solves. But the second is equally—if not more—important. Enterprise architectures are showing their age and cannot compete with the architectures of the digital natives, which focus on scale and lower costs through new paradigms such as eventual consistency.  

A good API management solution is typically built to these new architectural principles and enables the API proxy layer to scale at cost. The beauty is that this architecture also serves as a Trojan Horse in the enterprise stack: new services can be written that leverage the API management layer to achieve scale at cost. In other words, it becomes a good Platform as a Service (PaaS) for a certain class of services.

Let’s take an example. Apigee’s API management platform not only proxies our customers’ APIs (i.e. built-out services), but also welcomes new APIs to be written entirely or partially in the API management layer. It does that by letting you  “BYOC” (bring your own code) that implements the API.  

The API then scales, as does the management of that API. Consider a shopping cart API. The shopping cart “service” could be delivered through an existing backend legacy system (one that dates from the e-commerce days), and its APIs could be managed in the API management layer. But the shopping cart service by itself can sit in the API management layer, implemented as Node.js code leveraging BaaS as the persistence layer.

The API to the shopping cart (/add, /remove) can further be managed (secured, analyzed, exposed, and documented) by the API management layer. If the API layer is implemented in the API management layer, the enterprise gets the scale at cost. And, as an added benefit, there is one less artifact that has to be deployed.

A predominant new pattern is “API-first.” This pattern dictates that all new services be designed from the API down. For this pattern, the API and API management become one and the same. Scaling the API is the same as scaling the API management, and is the same as scaling the service.  

We provide architectural building blocks to scale API management: stateless scaling of routers and message processors; stateful scaling using Cassandra and BaaS; analytical scaling using Postgres and Spark; clean contracts for APIs; and the ability to add intelligence to API management. Enabling BYOC provides the same building blocks to scale the APIs (i.e., the services).

As Apigee moves toward a more containerized architecture, this distinction between running the API and running API management will quickly blur.

So API management like Apigee’s is a twofer. Buy it for API management, but use it as a PaaS for running more and more of your services!

What "services" naturally belong in the API management layer? Join the discussion in the Apigee Community.


Start a discussion with Anant by posting a question on the Community—remember to mention "@anant." 

Telstra: Speed, Scale, and Security with APIs

Technology projects don’t usually move fast at large enterprises, but for Telstra, the biggest telco in Australia, APIs have helped create an exception.

"When you talk about delivery, you tend to measure things in terms of years, not months or weeks,” said Charlotte Yarkoni, president of Telstra Software Group.

However, moving from scratch to going live with the company’s first public API took a mere four months, said Yarkoni, who spoke with us during I Love APIs 2015. 

“That was huge for us,” she said.

Similarly, Telstra set a 30-minute internal goal for the first developer to get from registration to “hello, world.” It was easily met, Yarkoni said. But for a company where quality of service and security are differentiators, speed wasn’t the only consideration, she added.

When it came to selecting an API management partner, Teltra had a specific set of standards it expected any company to meet, Yarkoni said.

“We have a very, very high integrity brand,” she said. “Our customers associate Telstra with someone they can trust and someone that delivers a high quality of service.

“Apigee was one of the few API vendors … that could come to the table and offer that,” Yarkoni said. “It’s a lot about the enterprise class and scale, but it’s also about doing it in a trusted way with integrity around the data and the customer relationships that you’re driving through this platform."

Apigee Edge Microgateway

Deep-dive webcast replay

Apigee Edge Microgateway is a lightweight solution that enables enterprises to manage their APIs in a hybrid cloud deployment setup, where API traffic flows through a gateway running close to the application while being managed centrally through the Edge Public or Private Cloud.

In this technical webcast replay, Apigee's Prabhat Jha:

  • discusses Edge Microgateway features
  • explores use cases for hybrid cloud API management
  • conducts a microgateway demo

 

Morningstar: Building Excitement with APIs

APIs are nothing new to Morningstar. The Chicago-based investment data and research provider has been using internal APIs for a very long time, said the company’s head of architecture and core services Steve Engelhardt. 

What is new is Morningstar’s push to gain better control, governance, and visibility with its APIs, and expose them in a way that makes building apps against them easy for internal and external developers alike, Englehardt told us during I Love APIs 2015.

“We want a platform that can help us bring this vision together—a single, common, global API platform that helps us expose our APIs together, provides developer portals, authentication, analytics, abuse detection and prevention. So we chose Apigee,” he said.

Fostering the ability for developers to take the powerful data that Morningstar provides and mash it up into new experiences is a key goal, Engelhardt added.

“As an API provider, when you see all the applications people built using your APIs, and they use it in creative ways that you never expected, that’s really exciting,” he said.

MapQuest: Hyperfocused on the Developer Experience

"Our sole purpose in life is to create great APIs"

About two years ago, digital mapping company MapQuest decided to become an API business. With that shift, the Denver-based company became “hyperfocused” on creating a much better developer experience, said MapQuest general manager Brian McMahon. A major part of that push involved simplifying the process of using its APIs.

“Our sole purpose in life is to create great APIs,” said McMahon, who sat down with us at I Love APIs 2015. The transformation has been succesful so far, with one measure being the Digital Accelerator Award that MapQuest won for “Best Developer Experience.”

The company, which has 40 million monthly users, has come a long way from the days when developers actually had to send MapQuest a fax in order to receive an API key, McMahon said. 

Thanks to Apigee, MapQuest also is able to analyze the reams of data about the developers who build on its APIs.

“We had thousands of developers using our platform, but we had no idea who they were, what they were using, or why they were using it,” McMahon said. “Partnering with Apigee, we have a much more detailed understanding."