Apigee vs. Sonoa ServiceNet for API management »

In a few years, most of your internet traffic might come in not through your website, but instead through mobile devices, tablets and affiliate partners accessing your services through APis.  For two years, we've been helping enterprise customers accelerate their API strategy and deployments with Sonoa ServiceNet.    

Last year we released Apigee as a tool for developers building apps with APIs.   Apigee provides free, self-service website for API analytics and protection. Hundreds of developers are using Apigee to monitor APIs they are consuming (such as the Twitter, Flickr, and Facebook APIs) or APIs that they are providing.   Here are some example apps. 

How do Apigee and Sonoa ServiceNet compare?

It's much like the difference between Google Analytics and Omniture. Apigee (like G analytics) is a free, self-service API analytics and management tool that provides coarse grained analytics and basic throttling policies.  Sonoa ServiceNet is an enterprise-scale API management platform that provides a rich policy framework for customized, complex policies and enterprise-levels of scalability.  While Apigee is available as a free service,  Sonoa ServiceNet is available as both an on-demand an on-premise (both hardeware and software) offerings.  Also, Apigee is itself an app built on the Sonoa ServiceNet platform.

So if you are a developer building an app that uses APIs and want basic API analytics and rate limiting in 5 minutes - give Apigee a spin.  If you are a product or engineering executive thinking about an enterprise API strategy or roadmap, consider these potential requirements and take a look at Sonoa ServiceNet for industrial-strength enterprise API management.

Protect your API: Twitter’s Denial of Service Attack and API Security »

Lots of news on the Twitter attack last week. There’s general consensus that it was a distributed denial-of-service attack (DDOS) that it targeted a particular account.

DDOS attacks are tricky things. There’s no one technique, product, or protocol that will stop them. That’s what makes them so nasty. To defend against one, a company needs to be able to quickly take countermeasures at all the different levels of the protocol stack, including firewalls, routers, load balancers, and even in the application itself. And even more importantly, you need to have experienced, well-trained operations people who know how to quickly identify an attack and come up with a way to minimize its effects.

When a DDOS attack affects a web service – and there’s an good chance that the Twitter attack made use of the Twitter API – then proper traffic management at the API level is an important part of this stack of protection.

For instance, if a DDOS attack targets a particular user account, or API key, it may be possible to block those particular requests before they get to the back-end application servers, so that the effect of the attack is limited. Or, if the attack always sends some of the same parameters in an HTTP query string, or in the body of an HTTP POST, it may be possible to detect those patterns and reject the requests, again before they reach the back-end application servers. In the worst case, it may even be necessary to shut off access to a particular web service or web service operation, allowing other services to function as best they can while the attack is neutralized by other means.

In other words, just as it may be possible to stop a DDOS attack by blocking a range of IP addresses, or redirecting certain URLs, or configuring traffic shaping in a router or an ADC, it may sometimes be necessary to stop a DDOS attack closer to the application level. The ability to inspect requests at the web services level and take action based on the request content gives an operations team one more weapon to use against an attack.

The Twitter API already has a usage quota on each user account, a rate limit on each IP address, and extensive caching. Imagine how much easier a DDOS attack might have been if they didn’t even have those things.

-Greg

(Greg Brail is the CTO of Sonoa and writes on API Security topics such as API Keys, OAuth, and API Security Recommendations.)