De-inventing the Wheel »

As a web developer, I can't tell you how many hours and brain cells I've burned trying to make something that somebody else has already done. As a fan and proud member of the Apigee team, I can't tell you how happy I am that I'll never go down that road again. And neither should you.

If it's not your core competency, somebody's doing it better somewhere else. One of the promises of the web is that our ability to link will allow us to find that improved implementation, the wittier comment, a more pure experience. To a great extent, this promise has been realized in the blogging world; it's not uncommon to see a blog post written in response to someone else's article, quoting still another, with a sidebar full of links to related sources all over the internet. With that in mind, it's intriguing that there's far less evidence of this kind of collaborative notion in the world of web development.

To be sure, whenever we developers implement a JavaScript library or search the web for a way to get around what Internet Explorer is doing to our CSS, we're standing on the shoulders of giants. Using tools provided by others in this way is a step in the right direction, and can provide momentum for a more interesting web, but more needs to be done to disassemble the notion of website-as-silo. We've all seen that attempt to do things that WordPress, Flickr, or Wufoo have already implemented.

I've been just as guilty as any other silo builder out there. It took me a long time to realize, for example, that I could either build a custom movie player, and wrestle with controls and accessibility, not to mention server-side issues like bandwidth and storage, or I could put the videos on YouTube, embed them in the client's site, and deliver a better experience all the way around. That's the point: A federated web application is economical in every sense of the word, but especially because it frees me up to focus on what is truly unique and interesting about my project.

I'm certainly not the first person to make this observation. Not only does the very nature of the web suggest a collaborative approach, but the work done by Peter Nixey in 2006 serves as an excellent proof-of-concept. Nixey's eventsites application allows users to create mini-sites centered around events such as parties or conferences, but does so without storage or server logic of any kind. Instead, eventsites is a single-page JavaScript application that acts as a client to eventful, Google Maps, and Flickr. The genius here is not in the ability to schedule an event, find it on the map, or see photographs related to it. The brilliance is in the aggregation and presentation.

 This is just the tip of the iceberg. Since 2006 we've seen the rise of the API as a valid tool, opening the door to better, easier, and more creative implementations. What we need now is a way to monitor our usage of federated services, and, perhaps most importantly, a way to make them more reliable. That's where Apigee comes in.

Creative and responsible use of the work done by others helps us to fulfill the promise of the web, and empowers us to do work that is interesting, progressive, and inspirational. I'm happy to be a part of that effort, and I can't wait to see what you'll do with the tools we provide.

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.