What are the tradeoffs of using Mashery vs. building and maintaining your own API?

I’m a developer and consumer of Web APIs.  However, I also have experience in rolling my own APIs for internal and private partner use.  I am answering this question from my own professional development experience consuming a number of Web APIs, some of which are managed by Mashery.  I am not answering this question as a provider of APIs, although I have had some very recent discussions with individuals that do work directly with the Mashery API management and reporting tools.
  
The benefits of using a managed API provider like Mashery include: 

  • Domain      expertise
  • Rapid      deployment
  • Scalability      and availability
  • Reporting
  • Community      support portal and developer exposure

  
The most obvious trade-off for the above benefits is cost.  The most obvious trade-offs for building your own API are the development, maintenance and opportunity costs.  I will examine each of the benefits above and compare it to the “roll your own” scenario. 
  
Domain expertise 
Strategic business planning is essential to building a successful platform.  By working with Mashery, you will benefit from their years of experience in working with many different companies and collectively thousands of developers.  Mashery can help you clearly define your strategy and goals before you get started.  Their experience can also assist you in avoiding both common and obscure problems when designing your API. 
  
As of this post, Mashery manages APIs for at least 100 companies [1] (45 showcased at URL cited) in the following categories: retail, online marketplaces, news media, social media, mobile, real estate, etc.  There are some large ones in there, such as NetFlix, Etsy, GoGrid, Trulia, HotWire, Best Buy, and CafePress, etc.

  
Rapid deployment 
Rolling and deploying your own API can be quite timely.  If you were to deploy your own API services, you would first have to properly design the platform architecture and infrastructure.  You would also have to perform a number of quality assurance, regression, security and penetration tests to insure reliability and security. 
  
Mashery already has the platform infrastructure designed and ready to be customized to your needs.  Mashery and its contemporaries have probably addressed all of these concerns with good measure.

  
Scalability and availability 
Twitter handles 70,000 API calls per second [2].  eBay services 8 billion API calls per month [3].  Even if you do not anticipate that level of usage for your API, you must build your platform to be extremely scalable and reliable.  Mashery has been designed to scale dynamically on the Amazon EC2 platform, and additional capacity can be added on demand [4].  Mashery supports automatic fail-over from AWS to the Limelight Network [5]. 
  
Rolling your own API means that you must architect your API back-end to scale horizontally which requires expertise in: resource monitoring, application/server load balancing, caching, automatic server resource management (spinning up/down instances), automatic node management (making new instance an active member of the API service cluster), etc. 
  
Developers and their businesses will be relying upon your API to be up and running 24/7/365.  If you fail to scale you will stand to lose credibility, developer support and revenue. 
  
Reporting 
Analyzing how your API is being used (or misused) is essential.  With proper and accurate reports regarding your API usage, you’re able to ascertain what the developers are consuming the most, what they’re having problems with (error reporting), and how you might better serve them.  Mashery provides a real-time dashboard as well as downloadable raw data of API usage [6]. 
  
Rolling your own API will require you to build a custom reporting back-end.  You can easily assemble your own charts using tools such as Crystal Reports, Google Charts and GD Library.  However, the bigger challenges include: understanding which metrics are important, storing/retrieving data quickly, optimizing API performance based on the empirical data, etc. 
  
Community support portal and developer exposure 
“If you build it, they will come” is naive.  If you build it, market it, support it, provide killer documentation and deliver value on all sides of the platform, then they will come.  Mashery provides a customizable support portal with a wiki docs engine, content management system with versioning, user forums, etc.  Your platform is only as successful as your developers make it, which is why it is important to promote and support a vibrant developer community. 
  
To expose your API to more developers, Mashery has created the Mashery API Network [7], a Web site that features participating Mashery customers.  It utilizes a clever single sign-on system.  So, if you launch your API on the Mashery platform, it can be made visible and available to all other developers on the Mashery API Network increasing visibility for your platform.  Additionally, Mashery reaches out directly to developers with physical presence at small and large tech events.  I’ve seen them sponsor small meet-ups as well as large tech conferences including TechCrunch Disrupt, talking to developers about their customers’ APIs. 
  
Rolling your own API will require you to build out your own documentation content engine.  You'll need to offer support, documentation and examples to engage and assist your developers.  You’ll also be responsible for marketing the API to try and attract more developers to your platform.

  
Conclusion 
If your company wants to build a true API platform that will successfully attract, support, and maintain a developer community, then you may want to consider using Mashery as your API management solution.  The trade-off for their expertise and infrastructure is the cost. 
  
If you are rolling your own, the trade-off is that you may lose sight of why you’re building an API while you’re trying to build and manage it.  Other trade-offs include development, maintenance and opportunity costs.  Remember that an API is more than just a Rails app sitting on an Nginx server that handles identity tokens, RESTful requests and JSON responses.  An API is part of your core product and service strategy and is incredibly dynamic.  An API is continuously leveraging developers who are building value for themselves while simultaneously contributing back to your platform. 
  
Done right.. an API is a beautiful thing.  Good luck!
  

  1. http://www.mashery.com/customers/
  2. http://techcrunch.com/2010/09/17…
  3. http://www.readwriteweb.com/clou…
  4. http://www.mashery.com/product/f…
  5. http://www.mashery.com/support/
  6. http://www.mashery.com/product/
  7. http://developer.mashery.com/api…

One Reply to “What are the tradeoffs of using Mashery vs. building and maintaining your own API?”

  1. Good question – although I think it would be better put as what are the tradeoffs between using an API management service like 3scale, Apigee or Mashery v's in house build rather than just focusing on Mashery. Since those other providers are significantly different from Mashery in meaningful ways (Caveat – given my position obviously I have a declared bias!).

    Regarding the question Neil gives a lot of the major points – and it is indeed it's a build v's buy tradeoff in the main, but it's also how it fits into your overall strategy in investment for your API (3scale tools come for free to use for reasonable volumes, so you can actually get started and make your decisions further on down the line).

    In general I think it's important to think about what's needed when you roll out your API:

    • The code itself which is delivering / receiving content and actions which may be on one or more servers.
    • Security and policy management around the API to ensure the right people have access to it and you can limit the amount of traffic allowed for each partner and which methods can be accessed
    • Analytics to let you figure out what's happening on the API – which partners/applications are using it the most, which are close to their quotas and may need upgrades
    • Billing and payments – if you plan to charge for your API
    • Developer community tools – to allow people to sign up for the API, get documentation and status information.
    • Promotion of the API to the audiences you want to reach which may vary – could be in your organisation, existing customers, developers working for partners or third party developers.

    Obviously vendors such as 3scale, Apigee and Mashery provide solutions across the board for these items but I won't turn this into a product comparison since it shouldn't be! – but I'd encourage you to check them all out.

    The main question here is when to you use them and when not. Whichever approach is taken it's still about your API and the functionality it delivers rather than the "wrapping" around the outside. Often it makes sense to use a vendor to add the elements you need while you focus on the core of delivering a great API. They'll also give you advice on how to promote the API, how to best document it and get traction.

    I'd also say that using a vendor makes increasing amounts of sense when you want to measure the business impact of the API, since the level of reporting and information you get, partner/developer management + integration with systems such as Salesforce is normally significantly more than you'd want to build yourself.

    Since these services are also available free in some cases, it makes sense to use them early, get inputs and the decide for yourself.

    In any case – if someone would like to get inputs on an API project feel free to email me at: steve [at] 3scale.net –
    Steven Willmott @) for inputs. We're (honestly!) very impartial and you'll get good inputs whichever way you end up going with your API!

Leave a Reply

Your email address will not be published. Required fields are marked *