Monitoring cloud performance is different from on premise application servers. For starters, you can’t put a SNMP agent up there; can’t monitor WMI classes either. Shoot, you may not even have an IP address. So how would you monitor cloud applications? Here are a few ways:

• End User Experience application monitoring. Let’s say for example that your business has elected to use a SaaS based CRM. How would you monitor it? One way is to monitor the real or even synthetic transactions through the application. You want to know if it takes longer to log in at some times than others. In the case of one company, editing a field and clicking the save button caused the application to hang. On another SaaS product, buttons simply didn’t appear on some browsers. End user experience monitors can give you a proactive handle on cloud application performance, even problems that are not caused by the provider.
• Performance via the API. If you are deploying virtual servers to cloud provider such as Amazon, you can retrieve some metrics by using their CloudWatch API. These metrics include average disk reads/writes, average CPU, and network traffic in/out. This will provide traditional IT managers some data, but not more than a couple of week’s worth. If you are running a virtual cloud on a VMware platform, you can leverage vSphere API’s along with traditional network management tools.
• API experience monitoring. If you are writing applications that rely upon web services, you are not concerned with the CPU, memory, or disk I/O. Similar to the end user experience monitoring, developers want assurance of API uptime and reasonable latency. Products like apigee are low cost solutions that are necessary infrastructure for stable runtime operations.

It’s been a long time, I shouldn’t have left you.

Those words were first uttered by Rakim on the legendary album, I Know You Got Soul. Well, that’s how I feel right now. So while I use the next paragraph to explain my absence, the remainder of this post will go in a familiar direction.

In every workplace there is a culture. I’ve seen a few  and I certainly believe it to be established at the top; leaders reinforce the behavior they expect. If you work in an organization that is based on command and control, with a culture of mistrust, you must watch what you say and who you say it to. Such was the case at my previous employer. When my blog became the subject of several conversations among the C-level, I decided to postpone for a while. Now that my employment with that company has come to an end, I’m ready with new ideas that may lead into a new direction.

Now that I’m unemployed, or rather under-employed because I’m always working on something, I’ve given some thought as to what my next role could be. After years of working in integration and SaaS, I’ve begun to think of myself as an API Strategist. What does this role mean?

I think of the API Strategist as a role that is not beholden to the rules of the web application. It requires broader thinking than a typical product manager – the API is not just a feature or a theme. This person works in tandem with business development and partner enablement. This role also has a seat at the table of the application architecture; ensuring that new features in the application are considered for release in the API (and how). But why an API strategist? Ask yourself these questions:

• What new value is our API creating?
• If I needed to see all the companies and applications that consume my API, who would I ask?
• What cost savings or revenue growth should we expect from deploying an API?
• What is the API costing us?
• Is our API (still) cool?

If you don’t know who to ask, maybe you need an API Strategist. If you don’t know why these questions are important, you probably need an API Strategist.

I had a chance to connect with Martin Tantow recently. He is a co-founder of 3scale Networks; a provider of API infrastructure. You can read more about Martin and his company here.

You’ve had a busy quarter, can you tell me about any specific highlights?

Yes, we definitely had a busy quarter. Our major highlight was certainly getting out of beta and launching our new white label solution CONNECT together with a new website design. Our new solution now enables a quick, scalable and cost-effective plug & play solution for Internet companies to manage their API. We have now 22 customers live – showing good traction in the last couple of months. We have also developed a plugin for Google AppEngine which allows developers to integrate and enable our solution very easily – we’ll demonstrate this for the first time at the Google I/O developer conference end of May in San Francisco.

What differentiates 3scalesolutions from other API infrastructure companies?

3scale provides a unique, plugin based architecture. Whereas some of our competitors focus on proxy based solutions, our architecture is much lighter weight and can be implemented more quickly. We also benefit from less bandwidth costs (which allow us a lower price point) and many customers prefer our model for security reasons. Our new product, CONNECT, also provides a full self-serve model which does not require any interaction from the 3scale team – although we are happy to help, of course if necessary.

With so much application development now being done in Eastern Europe and Asian companies, do you feel you have a strong growth position?

Eastern Europe and Asia are very interesting markets for us. However the US and Europe are our key targets for the moment due to resource limitations; however expect more on that in 2010.

Metering can be a scary topic. Nobody likes to think they have to pay for usage – we want an unending supply. Take TWC for example; plans to launch consumption based billing were thwarted to the delight of many of its subscribers (including me). 

The whole process seemed to be a little reactionary as TWC fights to maintain (arbitrary) video and data product distinction. They don’t want videos of shows to be streamed over the Internet. Even if that wasn’t accurate, that was the perception.  Metering, in and of itself was not the culprit. As Will Richmond points out in his blog, it was with lack of trust that the public reacted. What lessons can we apply to the API world? 

1. Bake your business model into your API. There should be no free rides from the outset. This is the position that Dave McClure has educated many API’s channel managers on. If you give something away, it is very difficult to levy a fee to it later.
2. Think about API tiers as you do product tiers. Perhaps for one market, it makes sense to give some functionality for free and charge for additional depth of information. Take a look at Hoovers API (HAPI) description, they offer the full breadth of records, but “throttle” the depth.
3. Think about your partners clients needs. In a recent meeting with a CEO of a social media company, I learned the entire product was run on Amazon’s EC2. I asked, “what if you have a spike – how does that affect your OPEX?” He said that they plan on spikes from time to time but the overall cost is so low, it is okay. Your API should be flexible enough for cloud computing – adding more capacity on demand can be a feature that you market.

Be clear and transparent in your API. Metering can be acceptable if you provide a clear framework that aligns to your business model. Reporting of the usage (to the client) is the next step. 

Image courtesy of B Tal used under Creative Commons

I found this fascinating quote today:

Sonoa Systems capabilities can be delivered via its own networking cloud as well as via a client’s own networking. In other words, the policies for accessing content can be built right into a highly efficient cloud networking infrastructure, making administration highly cost-efficient and execution of service-level agreements with content licensees very efficient. I think of these capabilities as a “content policy cloud” – in other words, Sonoa technologies help to build into network infrastructure the implementation of agreeements between a publisher and an enterprise partner or client and makes it easy to enforce and monitor those access and service agreements. Unlike typical networking infrastructure, Sonoa’s technology does this for individual content services and objects. This aligns perfectly with where many enterprise and media publishers are taking their business models – towards agreements in which their content gets integrated any number of ways into their clients’ platforms. Instead of turning that embeddable content loose in the client’s cloud and losing track of it, Sonoa enables complex deployments in client platforms to be monitored clearly at most any scale.ContentBlogger: Silicon Valley Journal: Sonoa Builds the Enterprise-Class Content Policy Cloud – Shore Communications Inc. – Commentary – Weblogs, Apr 2009

You should read the whole article.

Since my last post I’ve been fortunate to have a few minutes of time with the CEO of Sonoa Systems, Chet Kapoor. In the interest of full disclosure, my employer is a client of Sonoa for web services monitoring and reporting. Chet recalled that  I have recently made comments suggesting that web services infrastructure and integration companies come together to provide a solution for SaaS companies.

Chet’s background is in the integration business, a fact he reminded me of as we walked through the technical details for application integration. We agreed that integrations are not an easy thing to do; having an API does not make it easy. One reason is that some companies make it very difficult to develop on (compare the API for Google with SAP BAPI). Integration companies focus on building a catalog of adapters to make it seem easy to integrate, but do not provide monitoring of web service usage or throttling of integration. None provide the detail of reporting the web service infrastructure companies do.

We agreed that it would be a very good step to remove the barrier; the need to create adapters. This will not happen today, but it is a good idea. I recently contacted an integration company and the rate quoted to build an adapter was $30k, while the actual transformation and logic was closer to $1,000.  

All of the integrations that I provide in the coming year will be web API based – the partner that can address the monitoring/reporting as well as the transformation and logic will be my strategic partner.

Today I received an interesting tweet about API-First design. Kas makes the case that API’s should not be created after the fact, but should be written before the software is. I like this. Why?

If you are responsible for API’s, it is pretty painful to request features (like throttling) that should have been included, after the fact. Even more problematic is describing the API when that work is done and the developer moves on to the next project. If it isn’t used regularly, the nuances can be forgotten.

It seems the folks over at Huddle.net agree, in a recent blog they commit to “build functionality into our API and consume it from our website.”  Clearly they expect a high portion of traffic will come from API consumers (partners). It’s great to see companies eating their own dog food again.

 

(photo courtesy of Chrissie Un)

 If you were building a web application, you wouldn’t think twice about including monitoring and web analytics tools. Product and marketing teams live by site metrics to understand how the application is being used and where site visitors are spending their time. Today you may even be thinking about how to include social into your presence by adding communities, blogs, and wikis. API’s are different; when you consider opening an API, the management requirements differ in ways many tools were not designed for. The result is a blind spot.

When considering opening an API, you should be clear of your objectives. For some companies, the goal may be to create a partner channel which builds applications that enhance your product. These partner apps add new features & innovate faster than your company could. Examples are Twitter and products like TweetDeck and Twhirl that make sending tweets so much fun for tweeple.

For others, providing integrated solutions may be the goal. If your product or service is a B2B, like a project management tool or a CRM, not having an API may limit your ability to integrate applications. So, what are the features that you need to consider?

If you already know that your primary goal is to open a developer channel, proceed to next paragraph. If your reason for providing the API is a means towards integration, your problem is doubled. Why? Because while the integration companies can tie two end points together, most do not provide any sort of monitoring of consumption.  If you’ve ever seen the hidden camera commercial of the hot dog vendor that doesn’t sell buns, you have a sense of how I feel about this. Why does it matter? Imagine your application is the water company. Your first goal is to make sure you can make it easy for people to use your service, so you provide plumbing to the homes and businesses in the community. Now everyone is using your water, but how much water is being used by the house on Wysteria Lane? How much is being used by ACME Company?

 If you are going to open an API, make the investment into monitoring tools. Web logs are basic and generally not usable for business purposes. Consider your future needs to:

• Know the methods that are being accessed most often.
• Report and alert on API uptime and performance. If your application is in the cloud, expect that your clients will want Quality of Service metrics. Even non-critical apps may feed into other more critical systems.
• Maintain version control of WSDL’s. Once those integrations are built into the client workflow, they become more brittle. You may have to provide a migration strategy.
• Provide a community for collaboration and education. While this can be part of a vendor solution, you can likely leverage your corporate social strategy.
• Control costs. As a business manager, be sure that you are getting the value for every penny invested in the infrastructure.

As you steer your course for the cloud, you’ll sleep a lot better with a little advanced planning. You’ll be to scale your web services – offering product tiers based on usage (throttling) and access (security) - providing priority access to your best clients.

Once you’ve established which side of the equation you are on, it’s time to evaluate partners. You may think that you have the capabilities to do everything in house, but the truth is that you have enough to do managing your backlog of enhancements. If you have a large organization, perhaps you could build everything in house, but why? That’s so, web 1.0.

If you are a content provider, you have probably already documented your technical requirements like API Key issuance, usage limits & throttling, and reporting. From a business perspective, you would like to have a community with forums, on-line documentation, etc. Those things are good baseline requirements, but remember, what is your business goal? Are you providing an API for clients to develop on? Are you prepared to manage a developer program? If your goal is to integrate your SaaS to existing (legacy) applications or other SaaS applications in the cloud, you still have more work to do.

If you are a systems integrator or API management vendor, what solutions are you providing your client? What are the gaps?

If a content provider wants to integrate with the top 3 CRM providers in the mid-market: Salesforce.com, MS Dynamics CRM, and RightNow. Can you provide connectors for those endpoints as well as build a connector for my application? Can we put it in the cloud and monitor the amount of  data throughput of the integration? Maybe I want to provide tiered pricing to my clients based on anticipated volume, or SLO’s. And I want to bill the integration as a subscription, consistent with my business model.

Can you do that for me?

 

If you provide, or have plans for exposing, a web service API, your primary focus is on providing integrations with your application or service and other applications. The problem is, the API in and of itself does not go far enough. There are business logic, endpoint mappings, and roll-ups that require the help of a programmer and application expert. Should you expect that your clients have access to these resources and can consume your API?

SaaS consumers are, generally speaking, small to midsize companies. Yes, I acknowledge that big players like Salesforce.com are competing with Oracle in large accounts, but historically speaking, SaaS applications can find opportunities amongst smaller workgroups. One of the reasons for this is the TCO, but that is the subject for another post.

Those smaller companies usually do not have the time or resources to complete the task of integrating two systems via the API. Here is what Bob Warfield says on the matter:

“When you have a large IT group, you can afford to, and indeed, may even want to dedicate some of them to building the integrations.  When you have a small group, if the vendor can’t do it for you, it probably won’t ever get done.  So it isn’t that the little guys care more, they’re just helpless to get any kind of solution if they care at all.

What does this mean for SaaS vendors?  In this case, having out-of-the-box tight integration with other SaaS vendors (or On-premises packages) was a big differentiator.  It lowered the deal friction (less to worry about on the custom install side) and increased customer satisfaction (hey, we could never get these two systems to talk before!).”

This raises a question for you; what is your ultimate goal that you are trying to achieve with your API? Do you plan to supply content (water) or build integrations (faucets) to all the various endpoints that your clients will want integrations with? I use the analogy of water and water faucets to illustrate in very simple terms. As the supplier of content, you should be concerned that your water is clean, metered, and with some assurances of availability. That is enough to worry about. It is the system integrator, or faucet manufacturer that designs the correct interface for specific use cases.

Trying to be both can be frustrating, time consuming and expensive. If you know your market well enough, it could make business sense to “own” some integrations – QuickBooks is the GL application for over 80% of the small businesses out there so it would be prudent for some business managers to make this investment.

Examine your business model
Are you a supplier of content or are you in the integration business? How does this impact your API strategy? Do you have reporting of who your clients are and how much “water” they consume?