Posted by: asmitty | April 22, 2013

API’s making it RAIN

Today Layer7 Technologies was acquired by CA for an undisclosed sum. This follows the very recent acquisition of Mashery by Intel for $180 million. Effectively half of the pure play API management vendors have been acquired in less than 6 days; so why is this happening?

API is the abbreviation of Application Programming Interface, or more specifically, Web services API (WAPI). This is the code that allows mobile application developers to interact with servers in a data center so that you can do stuff. More often than not, the apps that you download do not reside entirely on your smartphone. You have a lightweight client with most of the compute being done in one of the cloud providers like Amazon Web Services for example.

Recently the market for API’s has seen mammoth growth. In 2005, there were less than 100 open APIs published by organizations that were seeking firms and developers to integrate with their data and applications. As we go into 2013, that number has inflated into the tens of thousands (source 451 Research, C. Lehmann). A move like this means that Intel is (a) moving deeper into the data center while simultaneously (b) moving away from chips that power servers in those data centers. Why? As usual, all you have to do is follow the money.

CA on the other hand is seeking to lessen its dependence on mainframe associated revenue and remake itself as an Internet company. By acquiring Layer7 talent and customer base, they may just be onto something.

Posted by: asmitty | February 10, 2013

How Does Integration Fit Into APM?

Application Performance Monitoring (APM) as described by Gartner consists of five dimensions. For simplicities sake, the primary method is tops down monitoring using end user experience monitoring. This is supported by what IT tells us via deep-dive component monitoring. I’m simplifying things here, work with me.

If you have ever called your bank and been fortunate enough to reach an agent these next words will be too familiar, “hold please while the system locates your record”. What does that even mean? Is the agent using some archaic PC? No, the application is the speedbump. In particularly, it is YOUR transaction that is exposing the performance degradation of the app. Over time, more apps are deployed that require integration to support business processes. Because many of these integrations were custom coded, the performance is negatively impacted. People learn to just deal with it.

During a recent interview a hypothetical question came up as to where iPaaS fits (or even if it belongs) in APM? I didn’t have a clear answer but my gut told me that it does. If your business process relies on data transacting more than one application then you should monitor the ETL process. If your ETL is inclusive of data cleansing, even more reason to be sure things are working as expected.

Recent data tells us that more often, the applications the business relies on are SaaS delivered enterprise applications like CRM and ERP. iPaaS targets those types of deployment scenarios, and is being deployed more commonly. So how should we monitor the integration processing?

Integration middleware like Boomi provides a management console for monitoring the execution of integration processes and troubleshooting process errors. API’s are available to forward events for correlation. More traditional EAI platforms like Tibco provide management consoles. How does integration monitoring fit in your APM strategy?

Posted by: asmitty | October 29, 2009

Cloud Watching

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.
Posted by: asmitty | July 25, 2009

The API Strategist

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.

Posted by: asmitty | May 8, 2009

Q & A: Martin Tantow, co-founder, 3scale Networks

martin_tantowI 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.

Posted by: asmitty | April 22, 2009

How TWC nearly ruined it for everyone

minding-the-meters-b-talMetering 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.

Posted by: asmitty | April 7, 2009

Web Services API management and Integrations

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.

Posted by: asmitty | April 2, 2009

Dog Food

dog-food-by-chrissie-un2

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?

API management and Integration Architecture

 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.

Older Posts »

Categories