Is Microservices SOA Done Right?

Webcast replay

How does microservices differ from the service oriented architecture we saw a decade ago? Find out in this webcast replay, in which Pivotal's Matt Stine and Apigee's Alan Ho discuss:

  • real-world examples of microservices best practices
  • microservices anti-patterns and traps
  • recommended tools and technology to help with microservices implementations


gRPC: The Story of Microservices at Square

Webcast replay

Square's Manik Surtani joined Apigee's Alan Ho to discuss the mobile payments and merchant services provider's collaboration with Google to launch gRPC, an open source RPC framework backed by protocol buffers and HTTP/2 and based on real-world experiences operating microservices at scale. If you build microservices, this webcast is for you.

Manik and Alan discussed:

  • a technical overview of gRPC 
  • use cases and applicability in your stack
  • a deep dive into the practicalities of operationalizing gRPC
  • Square's experience moving from a proprietary RPC framework to gRPC


Belly & Apigee: Conserving Resources with API Management

Create new APIs while minimizing work from back-end teams

In the previous two posts in this series, Belly's director of platform Darby Frey discussed why the popular rewards program needed an API management platform and how Apigee Edge helped the company customize APIs for particular apps and devices.

Here, Darby discusses how Belly used Apigee Edge to quickly assemble new APIs for a mobile app the company was about to launch from existing microservices. Apigee Edge helped Belly avoid expending a lot of back-end developer effort, and led to a successful launch.

“Through Apigee, we were able to build out an API using components that already existed,” Darby said.

Belly and Apigee: Building APIs for Microservice-based Implementations

Why Belly needed API management for its microservices

In our first video post, Darby Frey, director of platform at rewards program provider Belly, explained why the company needed an API management platform for its microservices.

Here, Darby delves into the benefits of using Apigee Edge to customize APIs for particular apps and devices. Each of these customized APIs talk to one or more microservices.

Belly built separate APIs for iOS and Android. Apigee Edge enabled the company to customize APIs by device, which in turn helped Belly create optimal mobile experiences for its customers. Also, the ability to firewall customized APIs reduced regression testing, Darby said.

“We saw a huge benefits from Apigee, because we can make those interfaces completely custom to the products,” Darby said. “Customized mobile APIs makes it easier to sleep at night.”

In the next post in this series, we discuss how Apigee helped Belly conserve precious back-end developer resources.

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.

Pearson: Building an Education Platform with APIs

Pearson, the world’s largest education company and book publisher, is looking to solve new challenges unique to its user base.

Having grown from offering a small handful of APIs to over 50, the U.K. company is trying to make those APIs as easy to use as possible for anyone—including the instructors or university department heads who have no IT staff or budget to take advantage of Pearson's poweful APIs.

“We’re focusing on removing that barrier of ‘You have to be a developer to use our APIs’,” said Allen Rodgers, the director of Pearson's developer program and API network. “We’re looking heavily into technology that allows anybody to leverage our APIs.”

Rodgers, who spoke with us during I Love APIs 2015, said the company also aims to take the lessons learned from its external API development and apply them internally. 

Rodgers acknowledged that that this approach might be viewed as backward, as most organizations begin their journey with internal APIs. Pearson’s approach, however, was driven by its overarching need to open up its education data to external developers and partners. Now that’s it has succeeded on that front (the company has over 300 partners and more than 20 apps have been developed on its APIs) it is working on managing its microservices, Rodgers said. 

“What Apigee is helping us do is understand how to take advantage of the same kind of API management you’d use in a public or partner program and apply that to an internal program,” he said. “We’re looking at extending our external program internally."

For more on choosing the right API initiative, download the free eBook, "What's Your Problem? Internal, Partner, and Open API Initiatives to Fit Your Business Challenge."

Yes, APIs Are That Big

The impact of digital transformation is much larger than you might think.

As a technologist, I have always discounted marketing hype. Frequently, I hear about "helping enterprises with digital transformation." However, every time I hear those words I start to wonder: what exactly is digital transformation? Isn't the entire IT spend already all about digital?

A discussion of "two-speed IT" helps clear this up. In this context, digital is about new user experiences—mobile, the IoT—basically new forms of interactions with enterprise systems. This, however, is still not measurable enough. What does digital really mean? To answer this question, let's start with something we all understand: mobile commerce.

The new digital retail

E-commerce reached its prime during the late 1990s. Since then, it has gone mainstream. Recent estimates of retail e-commerce put it at about $1.4 trillion, or about 22% of overall retail commerce. By 2019, this is going to be about $2.4 trillion, or about 33% of the overall retail commerce. E-commerce was "digital" for the 2000s. But m-commerce (mobile commerce) is digital for 2015. It's not just a new modality—it's a whole new experience. Enabling this experience requires a lot of new infrastructure: APIs, BaaS, big data analytics. This is the digital transformation our retailer customers talk to us about.

But something else is happening in this retail digital transformation. The channels (physical, web, and mobile) are blurring. Who has not seen the "Buy online and pick up in store" option in your favorite retailer's mobile app? This is omnichannel, and it's also the new digital.

Enabling this experience of course requires the APIs, BaaS, and big data we mentioned above to power every channel. In addition, it requires a consistency of experience through common APIs, and new business and data logic to sit in or near the API layer.

So mobile commerce + omni-channel = the new digital retail, right?

Not quite. There's more. Retailers need to form new business partnerships. Rewards, points. Social. Payments. Photos. Name a physical function or a physical partnership, and it needs to become digital. This is all the new digital of retail.

So mobile commerce + omnichannel + new partnerships = the new digital retail, right?

Almost. There is one aspect of retail that is the same as every other industry: IT. In order to deliver these new experiences, over time, backend systems need to transform. More DevOps, more microservices. This is the new digital backend, in support of new experiences in the front.

So in retail, mobile commerce + omnichannel + new partnerships + new services = the new digital retail.

APIs: the key to all interactions

Guess what? The only constant in these four elements is APIs. They're the underpinning of all system-to-people, system-to-system, and business-to-business interactions. That's it. One common factor.

How big is this? Mobile commerce is supposed to be $2 trillion by 2019. So APIs will drive at least $2 trillion of commerce. With omnichannel, this number could easily be $4 trillion (all of e-commerce). Or even larger, if physical commerce gets transformed.

APIs are that big.

Now look at travel. When was the last time you walked into an airline booking center and booked a ticket? Or walked up to a hotel lobby and booked a room? It's all digital now, and, increasingly, mobile. Mobile travel bookings are growing at 3x the rate of web travel bookings, easily surpassing the latter to be at least $1.5 trillion by 2019. All mobile bookings, ratings, and browsing happen through APIs, so it follows that at least $1.5 trillion of travel sales (out of an industry total of $6 trillion) will happen through APIs.

APIs are that big.

Take financial services. Or health. Or media. Or real estate. Or any industry (okay, not mining, perhaps). A shift to digital. A shift to mobile. Trillions of dollars of activity through new digital. All powered by APIs.

The new digital is that big. APIs are that big.

And then look at the trend of microservices. How are the services talking to each other? Through APIs, of course!

Image:Dan Draper/The Noun Project

Microservices at Amazon

As popularized by Yegge’s Google platform rant, Amazon is regarded as the first company that got microservices and APIs right. Chris Munns, business development manager of DevOps at AWS, provided an excellent talk at I Love APIs 2015 about how enterprise microservices are really built at Amazon, and what makes them work at enterprise scale.

Chris wasn’t the only one to discuss microservices; people from several businesses presented at I Love APIs 2015 on how to build microservices including Verizon, Magazine Luiza, Netflix, Burberry, Belly, and Zoosk.

Chris started his discussion with an architectural overview, the main points of which were:

  • Lots of microservices talking to lots of services
  • Fifty million deployments per year
  • Connect only through APIs over HTTP
  • Mostly black box between services


Amazon internal services architecture circa 2009


He gave us an overview of how Amazon organizes to deliver enterprise microservices:

  • Run by two-pizza teams (team size limited to two pizzas for a team meal)
  • A team owns one or more microservices; no microservice should be bigger than what a two-pizza team can run
  • Teams control their own destiny (product planning, Dev, Ops, and QA)
  • Teams exist as part of larger orgs, such as Amazon.com (retail) or Prime, for example


On the tooling front, Chris said that Amazon:

  • Had to build lots of tooling itself because no company deployed microservices at Amazon’s scale
  • Built tooling as a set of microservices
  • Created Apollo, a custom deployment tool that enables integrated health checks to ensure new software functions as expected and one-click deployment and rollbacks
  • Created Pipelines, a continuous delivery tool supporting Amazon development workflows that enables automated action taking and alerting


Chris also described a host of Amazon best practices:

  • Mostly no coordination between teams when deploying services
  • Each team releases on its own schedule resulting in 50 million deployments annually
  • Lots and lots of monitoring
    • Host metrics (is the infrastructure I’m running on sound?)
    • Service metrics (am I meeting my performance SLAs?)
    • Log analytics (is something erroring out?)
    • Build metrics (did someone check in crappy code?)


Building all services, all the time, in parallel

Finally, Chris described how AWS released developer tools that were battle-proven for building microservices at Amazon, including CodePipeline (the AWS version of Pipelines), CodeDeploy (the AWS version of Apollo), and API Gateway (hundreds to teams all talking to each other requires properly protecting services and revoking keys to keep running).

If you want to learn more, please let us know in the Apigee Community. Stay tuned for more on this topic from us; we’re also planning webinars with Amazon on enterprise microservices, so let us know if there’s anything you’d like us to cover.

Further reading:

I ♥ APIs 2015 Loves Developers

Amazon, Hortonworks, Atlassian, Pivotal, Netflix, Verizon, and SmartBear. Want to learn how these companies build APIs, microservices, and developer communities? Want to peer into the minds of developers-turned-founders, including Mike McNeil, creator of Sails.js and CEO and co-founder of Y Combinator-backed startup Treeline, and Jakub Nesetril, founder and CEO at Apiary?

All this, plus workshops, labs, and sessions on APIs, microservices, the IoT, big data, and apps will be crammed into three days at  I ♥ APIs 2015 in San Jose, Calif., on Oct. 12-14.

If you still haven’t registered, here are five more reasons professional developers need to be at I ♥ APIs 2015:





  1. API design The API knowledge at  I ♥ APIs runs deep. Netflix’s Dan Jacobson and Swagger’s Tony Tam will share their thoughts on designing best-in-class APIs. Peter Reinhardt, CEO and co-founder at Segment, a Y Combinator-backed startup, will detail API design tradeoffs like readability, simplicity, granularity of control, and backend infrastructure costs. Apigee’s own Jeremy Whitlock will explain how to “flip the paradigm” and create design-driven APIs with Node.js and Swagger.
  2. Microservices The promise of SOA has become reality in microservices architecture, but the complexity of scaling up the number of services needed to support modern enterprise software is no easy feat. At I ♥ APIs, you can take advantage of lessons learned from real-world implementations of microservices at scale, like Amazon’s thousands of services and Verizon’s hundreds of mobile microservices.
  3. Open source The Usergrid team will explain how they architected a BaaS that scales horizontally past 10,000 requests per second while providing a flexible data model and graph database API using Cassandra and ElasticSearch. Tony Pujals, a member of the io.js evangelism working group and CTO & co-founder at Atomiq, will discuss building APIs deployed as Docker-based microservices. Darby Frey, director of platform engineering at Belly, a leading national loyalty platform, will share lessons learned in building an API layer on top of an existing SOA and will discuss the open-source tools they created to streamline the development workflow and empower their team to react to product changes quickly. Pivotol’s Kenny Bastani will teach about the new ways for Java Spring developers to quickly build and deploy REST APIs.
  4. Workshops and labs Join me for a hands-on workshop on building APIs powered by Node.js, and then build an API-powered, hybrid mobile app for iOS or Android with AngularJS and the Ionic framework. In the IoT lab, you’ll learn to build a networked security system and walk away with an IoT kit that includes a BeagleBone Black worth $75. API program managers and developer marketers can learn the secrets of attracting developers and partners to their API program in the “How to Build Successful Developer Programs” masterclass, or learn from other "digital doers" in the "Getting **it Done: Apply Agile, Test-driven Techniques to Delivering on your API Initiative" workshops.
  5. The IoT Check out what the future is made of at the IoT showcase. Who needs Soylent when Sereneti Kitchen is bringing us Cooki, a robotic chef capable of preparing delicious meals? Why buy your next pair of glasses when you can print them with the Autodesk Spark open and connected 3D printing platform? When you visit the Spark booth, you’ll get exclusive access to the Spark API beta program and be a part of developing the future of 3D printing.

If that wasn’t enough to convince you, then maybe lunch grub from 12 food trucks, networking, and fun at the two conference parties (Monday and Tuesday evenings)—and $400 off your ticket to the developer forum when you register using the code API-95 will make the decision an easy one.

See you there!


Using PaaS to run APIs and Microservices in Production

Webcast & podcast

Microservices, containerization, and platform-as-a-service (PaaS) represent some exciting new areas of API management. What is PaaS and why adopt one? How do APIs and microservices go hand in hand with containerization?

In this webcast replay, Cloud Foundry CEO Sam Ramji and Apigee's Ed Anuff and Martin Nally engage in a lively debate about API management and the roles that PaaS, APIs, and microservices play in providing services to applications.

Sam, Ed, and Martin discuss:

  • PaaS as the platform for developers and administrators to practice DevOps
  • use cases for APIs and microservices in the enterprise
  • using containers and Cloud Foundry to run APIs and microservices in production