The Single Pane of Glass and the Future of API Platforms
It’s been a fun ride since joining Mashery in the early days of 2008 and being part of our growth and the success of our customers. We’ve launched well over 200 API programs over the years, and I’ve had a front row seat to many of them. Some of our client friends at those early customer projects have been promoted given the success of their visions. That’s super rewarding to have been a part of.
Over the past year or so, I’m starting to see a new phase emerge in at least a few industries: retail, media, and travel. In those early years of 2008 in these industries, most programs were pilots. Yes, they were important to the business and showed great vision, but they were small bets in overall stature and importance to the rest of the business. They might have powered a few mobile app projects. Maybe they were attempts at innovation through partnering or affiliate network growth strategies. But other than a few, they rarely felt all in.
That’s changing. Business people get it. Architects get it. The analysts get it, and are even retooling the language they’ve used for a decade around Service-oriented Architecture (SOA). Competitors have poured in from a variety of integration middleware segments realizing they missed the business value story (oops). Mashery is no longer pushing a vision rock up a hill and hasn’t had to in some time. RFPs from the Fortune 500 crowd became quite good and weren’t just templates from their preferred vendor. And finally, the world’s largest software companies have woken up and are getting in, sometimes (ahem) through acquisition.
That’s all good. It’s rewarding to see a full-blown market emerge in our space.
But what’s exciting now is the API platform vision is going prime time in a big way. We’ve talked until we’re blue in the face about the general trend of people spending less time behind desktops. Connected screens have become ubiquitous. New screen types emerge every day. We all get this now. And we’ve realized that a critical component to adapting and innovating to address these expectations is the humble web API.
So what architectures are people going all in with? The most aggressive are re-platforming their businesses. Some were early to this realization, but it’s headed for prime time into very large organizations. We are seeing this in media, retail and travel for sure. These are segments that have massive multi-channel needs. They have large teams that take care of their websites, while the API programs almost always sat on the side of the core ecommerce platform. In the early pilot phase, they would take some smart guys and have them figure out how to find APIs they could use that existed, or start building something adjacent.
With the success of those pilots, they are going all in. They are building API management platforms that every single digital experience will grow from. The website is becoming just one of those experiences. They have seen the future and realize that their website is becoming just one channel that maybe over time is even less important than the others. Think of how exciting, disruptive and political these decisions must be in a big retail or travel company. And it’s absolutely right.
Therefore we build a data access and business logic tier, which insulates all developers from the complexities of the underlying systems. This allow them to do their internal builds faster and expose what makes sense externally. Then tomorrow, we can tear those apps down and build something new because the world has changed again.
That brings us to the API Management tier and why it’s so important. I have complex systems and it’s only getting more complex. Some are legacy, some are vendor-bought, some are SaaS provided. I need a way to get all those APIs built and managed under one roof. Remember, we’re doing this to make building our digital experiences easier. Last thing in the world I want to do is make it hard for my engineers or our partner developers to discover and access them. And what if those APIs are actually produced and exposed by SaaS applications that you use (Salesforce.com, Concur, Bazaarvoice, ExactTarget etc.)? All of which are really important systems to my business that I can’t just leave out of my API platform. And clearly, we’re not going to extract all our of business data from the SaaS systems, bring it into our datacenters, just to put an API on top of it. No way, I’m trying to hide all that complexity to make it easier to get things done.
All of this leads us to why hybrid API Management systems are critical. I need to create a single façade for all of my APIs. We need a single API home that internal engineers, partner engineers and external engineers go to. Developer experience is important. Reuse is important. We need this to be a platform from the perspective of the developers that are building the applications. What’s underneath can be complex and varied. What’s on top needs to be nice and clean. So traffic management needs to be flexible and hybrid. It’s why we’ve designed our service the way we have.
The Need for Hybrid Traffic Control, Distribution and Visibility
Remember, the APIs that represent your business will physically exist in many locations; in your datacenters, in your cloud hosted environments and in the datacenters of your SaaS providers. Further, they need to be consumed by an increasing number of combinations of partners, places and device types. We obviously shouldn’t assume all that’s required is middleware like an XML Gateway or ESB installed within your datacenter. What we need are a variety of places that we can put traffic control, access and acceleration mechanisms, while still getting visibility into the whole picture through centralized reporting.
Let’s take a look at a retail example. I have an ecommerce website, mobile and tablet apps, a prototype I’m running on a connected TV, in-store devices for wedding registries, my traditional affiliate network, my nascent external developer network, and finally product reviews hosted by Bazaarvoice. In this case, I have internal developers, development partners, and a SaaS platform in the mix. So I need to represent a single experience to my developers and I need a single place to manage access rights and policies. But since the traffic physically routes to a number of places, I need to deploy traffic control and deployment mechanisms in a variety of places.
In this example, we are seeing companies really reconsider their whole approach to their digital products. They are building holistic APIs against their hosted and cloud backends. They are creating façade APIs that route to their SaaS partners. Then they are putting the API Management tier in front of it and rebuilding all of their digital experiences, including their websites, on top of the management tier. They are able to do this by putting a variety of cloud and on-premise traffic control and access technologies in each place that serves APIs, cloud or datacenter. They are considering their websites as just another app sitting on top of their platform so a single API platform powering every single digital experience.
Mashery is a great fit to deliver on this API Management platform tier for the following reasons:
- Single developer experience. We provide a developer portal for you that is the centralized place for all of your developers (internal and external) to go to in order to discover, test, and gain access to your APIs, regardless of where the backend is.
- Single community administration. The same developer portal provides your administrators the ability to manage your developer communities.
- Distributed traffic control and acceleration. In this retail case, we need traffic control within the datacenter to power internal apps like the ecommerce site. So we place Mashery Local inside the datacenter. We use our cloud traffic service to power all of the branded and partner mobile experiences. We proxy the Bazaarvoice API traffic too so there is a single front door for all this retailer’s data. Finally, we utilize the Mashery API Distribution Network’s caching services to accelerate traffic for relatively static API response data like the product catalog.
- Centralize reporting and analytics. All the variety of traffic control points report back to a centralized indexing service so without much effort, you can gain visibility into your complete API platform in one spot, without complexity.
The benefit of this architecture is really one of flexibility and control. I have a single pane of glass in order to present to my developers, my administrators, and I can get centralized visibility into all the data flows and where I’m driving economic value for my business.
We’ve been delivering a variety of the pieces to this architecture for some time, but usually different aspects for different customers. What’s really different now is that customers are finally combining this all together and deploying a single API platform tier. We fit really nicely into this natural architectural evolution. Websites really are just another presentation mechanism now for these industries. It’s all about the platform. Contact us today for more information.