OAuth: The next Big Thing in Security »

Today at #defragcon our @sramji gave this talk making the case for OAuth as a business imperative.

(As Sam mentions on the last slide, no developers were harmed in the production of this presentation.) 

Trust, Safety, and the OAuth API »

At Apigee, we've been developing a secure, robust API management platform since 2005 and have been running it in the cloud since 2008.  We're proud that some of the most demanding enterprise customers like Netflix, Comcast, and GameSpy have made Apigee technology part of their API platform.

We believe that it should be easy to start working with APIs, so last week we launched a new service called the OAuth API, which takes the pain out of getting up and running with APIs that use OAuth.

The story of the OAuth API is the story of yet another function that we used to think of as occurring on a device but that is now moving into the cloud.

It marks the beginning of a trend of APIs being manipulated before they get to the client, since some things are better handled as a service. Authentication mediation is one of those things.

Apigee has built a business of using our API Gateway to publicly expose backend APIs in a safe way, such as by adding OAuth as the mechanism by which applications can be granted permissions by end-users of applications.

The OAuth API takes that model and reverses it, taking something that is complicated for developers to implement (especially across multiple APIs) and simplifying it.

But is it secure?

Should you trust your OAuth keys to a cloud provider, and to Apigee in particular?

In many ways, the cloud might be more secure, since providers do things you might never do on your own. Far too many applications never bother with encrypting users' secrets in their own databases. When you use the OAuth API, you get that for free, in addition to the API normalization and long-term maintenance wins. 

If you do trust the cloud, should you trust Apigee? We respectfully submit that it comes down to three things: technology, processes, and people. 

Technology

Our technology processes billions of OAuth transactions a day. Our Apigee Free tools—including the OAuth API—are built upon this same platform that powers 250 enterprise customers.  It is a core requirement that our servers be both security hardened and highly available.

Processes

We encrypt the secrets entrusted to our database. We run security audits. We involve our security team members throughout the design and architecture process.We use the same software, made by the same people, working under the same processes behind the products that power the APIs of the most demanding Fortune 500 companies. We use industry standard security practices.

And in the end, it's still an OAuth token that is being stored, not a user's password. It can be revoked by a user at any time, and developers can still invalidate their consumer key and secret at any time.

People

Here at Apigee we have lots of experience in API security and operations in the cloud, again as a result of working with demanding enterprise customers for years, many of whom entrust us to protect their API traffic, their organizations, and their customers.

Does your API need PCI compliance? »

Many APIs start out serving content.   But if you eventually want to transact with your API and take credit card orders - you need to understand the implications of PCI DSS compliance.

PCI is a set of requirements that protects your customers and your business from the release of sensitive credit card information.   You don't buy technology to that makes you PCI compliant.  Instead, PCI is a process and checklist of standards that those accepting credit card data must adhere to (more on this here).   But it's important that the technology you use support and maintain your PCI compliance process.

Earlier this week we announced our Apigee Enterprise Cloud PCI - for companies that want to transact with their API, yet take advantage of the cloud for their API management and infrastructure.

On July 16 2011, we'll host a live webinar on the topic of PCI and considerations foryour API.   We'll also be writing a bit more on this topic over the next few days.

Have a great holiday.

Cloud computing is a double play »

Joe Weinman recently wrote that any business-focused CIO must first ask:  Why do cloud from a business perspective?

Joe makes the great point that technology will only be important if the business value is clear and compelling. CIO's have a small number of projects that they can really focus on in any given year, and major initiatives must have a compelling rationale or won't get supported by senior leadership. 

What could be more compelling to senior leadership than finding new revenue streams?

While senior IT leaders may still be concerned about being viewed as a cost center, and look to the advantages of cloud computing to reduce IT cost, savvy IT execs will find a way to help create new revenue streams for their company.  A great way to do that is to create new business channels by opening APIs.

So why not get a double play?

You can do both… have a  more business-relevant discussion with senior leadership about how to spur new revenue growth, as well as start to utilize cloud computing.  Sonoa’s API management solution is helping companies like TransUnion Interactive , SilverPop, and MySpace create new revenue streams by opening their APIs, and Sonoa is available both on premise as well as a ‘cloud service’.

But can you hold the API to the SLA? »

Great article by Jonathon Feldman in Information Week recently with some steps for CIOs to take before getting into cloud computing.   One is to insist on SLAs from cloud providers, especially considering the natural tension from the provider's perspective between high-availability and low-cost operations.

Absolutely agree.  But to build on this - remember that scene from Seinfeld where Jerry is at the car rental counter -  "Anybody can *take* a reservation, the important part is to *hold* the reservation."

Often, cloud and API providers will agree to SLAs, but have limited means to enforce or verify the SLA is held. Many SLAs are just 'on paper' with minimal enforcement or monitoring.  This gets especially tricky if you need to discuss financial penalties. 

Consider how you will monitor, meter, and audit API traffic and content between you and your partners - from your side - in order to pinpoint problems, protect your organization, and especially if you need to enforce penalties based on SLA misses. 

Business logic vs. Business policy in cloud services and APIs »

As our customers move from websites to cloud APIs - we're seeing them separating business logic from business policy.

When you think about business logic, you probably imagine an application server or stored procedures, or custom code that accesses stored data and exposes it in a useful and manageable way – such as “show me all of a given customer’s purchases in this timeframe”.  

These pieces of code reflect the understanding of the fundamentals of the business - like customers, orders, tickets, requests – and how they interact.  In any business you build skill over time in understanding your domain and then build on top of that understanding to take the business further.  Business logic is generally stable, consistent across requests, and subject to careful modification.  After all, you wouldn’t want to put partly tested logic about bank balance transfers into production.

When you think about business policy, what comes to mind?

Maybe a stack of papers documenting HR or accounting guidelines, or maybe the elements of Sarbanes-Oxley requirements.  Policy is not about how you compute a specific result – like the customer’s purchase history – but about other factors like who can access it, how frequently, from what locations, how it’s rendered, how long the result is considered valid, and other “meta-logic” issues.  In any business you make changes to your policies frequently, as a way to meet the changing face of the market environment.  The nature of business policy is therefore to be dynamic, varied according to the request context, and subject to frequent experimentation.  For example, product managers need to continually test the value of different offers to given segments without having to redevelop the product.

When policies like security (“who can access this and what credentials do they have to show?”) and service level (“how many requests can be made in a given time interval?”) are collapsed into code responsible for business logic, the result is loss of agility, high cost to adopt new policy implementations (e.g. for identity and access schemes or to keep pace with increased hardware capacity), and confusion of concerns (rather than separation of concerns).

In the current era of cloud APIs, where these interfaces are being built as a direct link to what started as the backend for the website, many developers are realizing that what was really policy was built into their business logic layer.  They’re also seeing that adding new clients – going from enabling partners to enabling rich clients to enabling mobile device (such as iPhone or Android) applications – require many adjustments to how the request and response of an API are rendered, but should require no changes to the stable core of business logic.  

Supporting an API with a set of policies that activate based on the user (such as preventing or enabling access to different parts of the API – for example, only the development & testing methods but not production methods, or query methods only, or limiting requests to a certain transaction volume or financial value) and type of client (such as providing pagination and format translation for a mobile device) means that the risk of delivering the API is reduced, and the risk of negative impact to existing users of the API (typically the original website) are reduced.   Also,  the computational load for the policy processing can be moved to a low-cost, scale-out tier and away from the high-value application servers that host the business logic.

So what this seems to indicate is a movement towards a separation of concerns between logic and policy.  Responsibility for business logic processing lies in a stable and slowly changing layer, and policy is processed in a tier that allows for agile modification and enables the total computational result to meet the shifting needs of the business.

More specific examples will follow in the next blog.

Mobile patterns are different from Web patterns »

Mobile application patterns are different from web application patterns.  There are a consistent, discrete set of differences in how they access cloud services.  There are consistent reasons why they’re favored over websites as well, primarily based on implicit intent and purposive computing experience, but that’s a subject for a future blog entry. 

For now, let’s assume that like web applications, mobile applications use HTTP to access their services, but unlike old-school web applications, they use REST and SOAP as the basis of their service protocols.

Difference 1: Bandwidth is expensive

Bandwidth always costs two unique things in mobile applications – time and battery.  Jeffrey Sharkey has a great talk about battery usage and good citizenship.  In some areas and for some users, bandwidth also hits their data plan, which makes bandwidth cost real money as well 

Difference 2: Bandwidth is inconsistent

Disconnections are part of everyday life when using the mobile internet to access websites or cloud services. When your local cell area becomes overloaded with requests or your service loses track of where you are between towers, when you are in even a momentary cell shadow, your connection is gone.  If this is in the middle of a data connection, that connection is reset and has to start over.

Difference 3: Local processing matters

First, non-trivial requests for data from cloud services often results in large datasets being returned to the device.  These chunks can not only be hard to process, but may be more information than the user will bother to access.  A request that returns hundreds of row-equivalents worth of responses may be mostly wasted processing if the user is only going to glance at the first few displayed screens’ worth.

Second, local applications have differentiated access to devices – awareness of onboard camera, location, or other services.  They also have differentiated preferences about data.  For example, the iPhone operating system is fluent in XML processing, and many iPhone applications transmit XML dialects to their cloud services.  However, XML is more expensive to the iPhone than PLISTs (a JSON-like simple data format) – roughly 4-5 times more expensive in compute cycles.  Other mobile devices have their own variations based on operating system version and device services.

Difference 4: Welcome to the hit-driven app economy

Media has been a hit-driven economy for decades, with winners and losers being made and broken overnight based on the wisdom or madness of crowds.  With the fantastic potential of mobile applications and the inconsistent actual experiences, collaborative filtering and editorial selection are producing a hit-driven “Top 25” economy for mobile applications – the equivalent of being “above the fold” in a website.  It’s a steady climb to get in this elite area, but once your application gets to this point you might as well have been written up by Walt Mossberg or Slashdot – traffic, downloads, and usage of the cloud services backing your app will all surge dramatically.

Difference 5: Concurrent usage by millions of nomadic users

Just combining Difference 2 (inconsistent bandwidth) with the fact that most mobile connections use HTTP 1.0 means that many more connections are being made, dropped and suffer an expensive reset not just of application state but of the HTTP connection itself.  Adding Difference 4 (the hit-driven app economy) to this means that concurrency – including “shadow concurrency”, the load of the dropped and restarted connections – has an even bigger role in mobile applications than traditional web computing.

Solving for mobile application patterns in cloud computing

There are probably ways to solve each of these problems individually.  What we’ve seen with some of our key customers is that all of these can be solved by applying a cloud service controller to manage the connections between mobile applications and their cloud services.

With a cloud service controller in the middle of the application and cloud service interactions, they’ve done the following things:

• Compressed service request and response data by 6-10x
• Accelerated service response time 5-7x through intelligent caching
• Carved large service responses into chunks likely to be used by the mobile user
• Translated service responses into formats easily  processed by the mobile device
• Reduced total network airtime usage by 15-20x
• Reduced battery drain on the mobile device
• Reduced dropped connection experiences for the mobile application
• Scaled caching and response capacity dynamically to match growth and spikes in usage

In one example, a customer took the network request/response time from 17 seconds to 1 second, and took local processing on the mobile device from 17 seconds to one second.  This reduced total application response time from 34 seconds to 2 seconds – an acceptable, even exciting level of responsiveness for that application’s users.  This was all achieved in a few weeks without rewriting either the mobile application or the cloud service upon which the application depended.

They did this by taking our core product (Apigee Enterprise), writing policies that let it route, cache, accelerate, paginate, and format their cloud services.  Since Apigee Enterprise is available as an .ami (Amazon EC2’s virtual machine format)  we've deployed it as a cloud service that expands and contracts its use of computing resources to match the load.  This way they haven’t been caught unprepared when their app made the top 25 list on the iPhone App Store and their legions of new users had the same responsive application experience as the users who popularized it in the first place.  Finally, future devices and application platforms will be easier to support from a single cloud service through construction of new formatting or pagination policies that match the needs of those device platforms.

Mobile acceleration may seem like a standalone thing for Apigee, but really it’s an example of using policy to solve an application pattern challenge.  More on that – and policy-oriented programming – in a future blog entry.  There are many more domains of use for this approach in cloud computing.

Here's a video we posted today describing our Mobile App Acceleration service.

Mobile is the future of cloud, cloud is the future of mobile »

Mary Meeker’s Web 2.0 presentation made a strong case for the imminent boom on the mobile internet.  Some statistics that caught my attention:
·         Mobile internet users will exceed 500M human beings in early 2010
·         The mobile consumer device market will exceed 10B in the next 5 years
·         The current iPhone + iTouch user base is larger than Netscape’s base in 1999
·         More than 20% of the world will be on 3G networks by the close of 2010

This is a serious change in how people are using the Internet.  I don’t think of the Internet as synonymous with the Web; the Web is one pattern of applications, based on HTML and HTTP, that uses a common infrastructure – the Internet.  Both the iPhone and Android phones have a much higher share of Web and Internet usage than previous generations of mobile devices.  But are they really using the internet?  Or are they using the Cloud?
 
From my point of view, the Cloud is another pattern of applications – like the Web – that use a common infrastructure – the internet.  But just as Web application patterns are different from other Internet applications (like email, for example), Cloud application patterns have their own rich array of styles and requirements.  And what we’re seeing with mobile consumer devices is an explosion of applications that reside on the device and use the Cloud for access to remote logic and data.
 
(I promise not to capitalize web, internet, or cloud from here on out.)
 
So the future of the mobile internet is not the mobile web – resized, limited web pages rendered by a WAP server and discovered via Google and Bing – but the cloud.  What we’re seeing are the first generation of sites rebuilding their backends to be accessible via cloud APIs in order to give access to mobile applications that will drive business.  Some sites are on their second and third generation, having rebuilt their web presence to rely on the same cloud APIs that their mobile applications do.

Is enterprise cloud adoption going through a lull ? »

I recently broke my collarbone and couldn't type.   So spent a lot of time catching up with some smart folks like Christopher Hoff.  Interesting that many of us thought it seems like we are going through a lull in enterprise buying of cloud technologies.

I do see what they are saying -  it seems like many of the CIO's who were gung ho to do summer pilot projects are slowing down...why?

I do not think this is a lull - instead the splashing water (survivcal mentality) is starting to go away..    The economy is getting better (or this is anticipated - almost the same thing).  Now the pressure's on to act quickly on trying out new things either to increase revenue or save $$'s.

Executives are getting back into a regular budget cycle, and this is planning time for most companies as they get back to thinking how to show good results and pitch budget needs for next year.

We at Sonoa are convinced that promise of cloud is strong as ever and our customers pilots are going into production w/ awesome results. The wave will continue to build into next year as more success stories are discussed - get ready!

In the cloud, scale means concurrency »

In enterprise computing, scale has traditionally meant “lots of transactions per second."  On Wall Street for many years, “20,000 TPS” was the magic number as it was the rate of a typical market data feed.  Infrastructure like TIBCO’s UDP-based information bus and then IBM’s MQSeries became the base platforms for much of this scale of computing, and are still heavily used alongside modern JMS and MSMQ implementations.
 
Relatively little attention was paid to concurrent connections.  Enterprise environments tend to be well-regulated, and most applications will have under 1000 simultaneous users (whether human or machine driven).  As a result, application servers and related technologies evolved to support high transaction throughput at limited concurrency.
 
The web on the other hand brought in much higher concurrency requirements, and platforms like WebLogic became default components of web computing environments for sites serving 1,000s people at the same time.  This was a breakthrough and led to significant market success in a short time period.
 
With the rise of cloud computing, two things change.  First, mobile applications and the API economy are driving an order of magnitude increase in the number of simultaneous users.  Second, these users are often machines rather than people, and therefore aren’t limited to the demand patterns of humans users clicking links or refreshing their pages.
 
This produces a new set of demand patterns which increase both total throughput and peak concurrency.  As an example, travel sites like Kayak.com and Bing.com/travel issue hundreds of API requests to airline reservation system backends as a result of a single human-driven query.  Furthermore, these requests are being made not just by desktop or web applications but by mobile applications – especially iPhone applications.  As most people are aware, the next 10 billion devices that come online will be mobile devices (phones, MIDs, GPS, game units, media players).  Each of these is prized for its native application experiences.  Each of these devices will be making user-driven and automated calls to cloud services in order to deliver those experiences.
 
Where backend systems are not protected from this demand, they are being penalized in performance and load management.  This causes either outright outages, “web brownouts” where the core website that uses the same backend slows down, or erratic performance across both the web and cloud properties.  Again, mobile access exacerbates the issue due to the intermittent nature of mobile internet connectivity, which multiplies the number of connections that need to be set up and torn down as the device comes on and off the network.
 
So the explosion of concurrent usage is already beginning, as the traffic and backend impact is expanding.  To manage this and maintain stability of existing infrastructure, a new layer of infrastructure is emerging, much as HTTP load balancers have evolved to serve the needs of web computing.  What we’re seeing is the rise of cloud service controllers, a category of infrastructure that works well with existing systems and builds on top of the strengths of application servers, enterprise messaging systems, and application delivery controllers.

Cloud Security tech talk series: Security and Scalability »

Next in our series of tech talks on cloud security issues, Greg and Ryan Bagnulo, Security Architect for ASPECT-i discuss how scalability can change security requirements and how cloud computing offers new opportunities to fend off attacks on services including. 

• security at high scale - how to preserve the resilency of the busines
• cloud powered security - using elastic cloud resources at the edge to protect core services
• protecting against bot attacks and spikes through security policy enforcement and caching

Check out this talk below, last week's video on PII and Audit compliance ,  and the full series here.

Cloud Security series - issues around PII, privacy, and audit compliance »

Greg recently sat down with Ryan Bagnulo, Security Architect for ASPECT-i, to discuss a number of cloud security concerns and issues.   

We captured these discussions in six short videos, each focusing on a  topic.  Here are the first two on PII, data filtering, and audit and regulatory concerns,  (see the full series here.)

In this first video, Greg and Ryan set things up with discussions on:

• Challenges in deploying cloud, starting with: should you trust your cloud administrator?
• Good data for early cloud adoption (such as public data like news, stocks)

This 2nd short focuses on:

• issues around PII (personally identifiable information)
• counter-measures, such as de-identifying data with filtering, screening or access control
• privacy and regulatory risks around stored in the cloud.
• best practices for protecting data
• implications for violating security breaches privacy regulations

We'd love your thoughts and comments.

Sonoa welcomes Sam Ramji »

We're delighted to welcome Sam Ramji to the Sonoa team as VP of Strategy.    

Sam joins us from Microsoft, where he drove many of Microsoft's contributions to open source and the company's shift to embrace open source technologies like PHP.  

In honor of Sam's first day - Sam and Chet Kapoor, CEO of Sonoa, spent some time discussing the API economy, remixing services, and why the time is now to transform your business with Cloud APIs.

Fast Company Podcast: Helping Companies Take on “the Cloud” »

A while back we had a fun conversation with Lena West of Fast Company's FC Expert Blog, and were excited to see the podcast published last week.

Some great discussion on emerging trends in cloud computing, including:

• cloud standards - driving them yourself vs. the interests of vendors
• adoption drivers for cloud computing - a comparison with SaaS
• how IT is using cloud computing to make IT more strategic

You can get the podcast here and below is a transcript.

Case Study: Sonoa on-demand and RightScale »

  RightScale just published a case study on Sonoa's ServiceNet's on-demand API Management service. 

Sonoa's API management solutions ship not only as on-premise (hardware and software) but also as an on-demand service as well.  Many of our customers appreciate the time-to-market benefits of getting started with an on-demand or fully managed service, with the added assurance that they can bring the solution on-premise as their needs change.

For our on-demand service,  RightScale has helped us accelerate the time in which we can to provision a new Sonoa on-demand customer down to less than a day.    It also provides an additional monitoring and management framework that is critical to customer satisfaction.  

Another great business benefit - RightScale helps us provide flexibility for a customer to deploy on multiple clouds, such as Amazon EC2.

RightScale has a great product and a super team.  Again here is the case study!

Deja vu:  As went networking, now goes cloud.. »

Some people thought it was unusual for a bunch of networking guys to start a company that wants to simplify the cloud services governance world.    But we see parallels all the time between the evolution of networking technologies and web services (SOA, APIs, Cloud services, or whatever you want to call them).

One parallel -  constantly shrinking 'islands of complexity' .    When IP started happening in the network world, there were many complex technologies like SNA, IPX, CLNS, etc.   First IP was used as a much simpler way to connect these 'islands of complexity' because there were such high barriers to making the complex technologies work together.   Over time, the islands got smaller and smaller until it was just IP.

And now here we are in the services world -  SOA, WS-*, ESB/middleware - all this enterprise complexity being connected together aross domains -  by simpler and simpler standards such as REST and technologies from the consumer world.   LIght weight service infrastructure (or call it Cloud or API infrastructure) will be used to connect these islands of complexity until the islands shrink away - and simpler APIs for app2app communication become the de facto standard.

-Ravi is a co-founder and VP Engineering of Sonoa.  Ravi developed the BGP protocol and Cisco Express Forwarding in Cisco and while in Redback architected and led the development of the SmartEdge Service Gateway, a Subscriber Management and Edge Routing platform.