The Strategist: Mitigating Cloud Computing Client Services Risk via Trusted, Blind API Brokers – Part IV

The plain truth: There will be no cloud computing industry initiative where competitors will agree to ‘blind pool’, and backstop each other’s failures and outages.There may eventually be great open standards to move VMs and apps off of your cloud, but no set of commercial continuity services will ever hearken back to the days of centralized SNA shops with real plans, proven market capitalization, and legitimate durability. Rather, I would expect the next few years to look like this:

• When a really big utility cloud (AWS / Google) goes down – you will get an apology and a paltry credit. The only consolation will be that it won’t happen often, and you will not be able to exceed their up time by running your own servers. The house usually wins.
• When a moderately well financed cloud provider starts to fumble, there will be ample warning, because folks will be watching and pinging. Have a plan, or get continuity coverage now, or when it really becomes specifically available for cloud users.  Don’t say I didn’t warn you.
• When a small, under-financed but buzzed up PAAS, SAAS, Cloud, whatever….fails overnight, taking your operations with it – comfort yourself by thinking how much you saved while it was working those 5 months in 2009. Really, now, Consider having at least a local or S3 proxy dup your data. Get insurance. Think before you trust business operations to a startup.
• If I was Andy Rooney from 60 Minutes: “Have you ever noticed that all of these hosting providers have a page on how great their hosting facilities are? Even the cut rate ones say, ‘we are a level 1000 bunker with a year of diesel backup power and armed guards, and multiple super network links?” I mean, did they all copy the same page to make us feel safe?”

There is no perfect state of reliability, and that even in the days of highly centralized data shops, continuity was planned. We are transitioning from this mercantile, Web Hosting mentality, to one of running business essential applications remotely. These services are splitting into ownership  categories of incumbent giants, and start ups that have a semi permanent ‘?’ on their forehead until they achieve operational liquidity. The former apologizes and credits your account, the later disappears int the night.

The vast majority of SAAS productivity app providers use existing utility compute services, in whole or in part. It’s a cost thing – perfect continuity in the cloud, on a per-client-per-use basis would be infinitely costly. There will, however, be no comprehensive industry clearing house offsetting failures -  not in the sense of a services for profit model.

There are some shared risk examples where pooled trusts for infrastructure failures exist (to the best of my knowledge, these were at least proposed in underwriting requirements):

1) Telecom, National data haulers , Carriers-Carriers, and submarine cable system operators sometimes negotiate emergency settlement and peering agreements as a prerequisite to satisfying underwriting requirements. Sometimes these agreements predate the insurer’s audit, and are just good business. Don’t confuse these contingency plans with standard settlements – they are negotiated for extraordinary outages and lock in fees and technical requirements. Only the very large carriers can enter into these agreements with true peers.

2) Municipal and State Gov. Emergency Radio communications networks, SMR, and certain common carriers (terrestrial radio specialty comms) sometimes have emergency coverage agreements that are mandated by statute.

3 )Interstate Nat Gas and Petroleum Pipelines. Etc.

The real message here is that underneath a pool of policies is a risk pricing model that is often further underwritten by a re insurer; risk pools come together faster if there are means to offset the preponderance of risk. Flood Zones are hard to mitigate, and pools are still formed, sometimes under the stentorian bark of a state regulator. But in the case of our beloved IT clouds, we have yet to get to a place where risk to an individual business that depends on a cloud service can be priced, mitigated against, and potential technical failures limited, in their worst instances.

You may now go read up on all the happy hoooha about, “the open cloud manifesto, cloud interoperability, etc.”, good luck with all that – I’m an optimist too.

We are talking here about commercially brokered services that are paid for by a pool of insurance companies, and that are funded by premiums. We don’t get there until the primary service providers are certified, rated, and as operationally good as they can be. At that crucial juncture, where a critical mass of SAAS and Cloud hosts agree to these ratings and certs, we can price the baseline risk of outages via standard actuarial methods. Subsequently, risk offsets that are purely technical in nature can be tested and put into production. Finally, when technical services are proven to be feasible, then we can look to the reinsurance market, and viola, we have a business.

Question #1): How many service providers and Insurers have to get on board, at least provisionally, to make a real retail or B2B market that multi-line agents and specialty carriers can sell into?

Answer #1): My research was cut short before I got that far. I felt that my client knew the answer and was testing to see if I came up with a verifying figure. My best guess is that at least 35% of the top 1000 SAAS and Cloud vendors and at least three major underwriters would be required to make a realistic market for policies and payouts that make any sense whatsoever.

Question #2): Other than the actual insurance underwriting and policy sales, is there a real business model here in operating the technical services pool of a blind trust API broker/ Data mirroring / continuity services for the insurance industry? How big ?

Answer #2) Oh yes, oh my G-d yes. I am writing this series because I got far enough in my work for the last client, that I did see the foggy future in a way that mature analysts sometimes do.

How big? I believe that operating the Trusted Services Pool will be worth about 60 – 120 million annually when it hits it stride. There may be ancillary channels and opportunities along the way that could lift revenues to 250M. So, it’s not going to be a Cisco or an HP, but a specialty business funded by the small insurance premiums paid by Small and Medium Businesses that make cloud computing or SAAS a critical part of their operations. (Much of my work product was projecting these numbers).

As a matter of fact, the industry as a whole may become hamstrung if these risk offsetting services are not brought online.

Maybe someone will read this very long and not too interesting series of articles (would you rather not  be reading some romance novel?), and put me back to work researching and creating the product road map, lassoing potential insurance industry partners, and start making this a reality (all that work!).

The services offered to offset cloud computing risk is a modest challenge to provision, and is really just another cloud service with special sauces for monitoring, security, and trust. That’s it.

You were expecting nuclear fusion? The goal of these pooled services is to cap the worst losses that imply risks to the majority of small and medium business that may encounter inoperative remote services – thus  mitigating the top tier of policy payouts. The insurers pay for and pool these services with the premiums collected from the insured businesses.
Blind Trusted Services:

The Trusted Services Pool has to have all the attributes of trust to be established. Fiduciaries and controllers, technical management, and operations staff have to be checked out. The capitalization has to be audited, and its own operational contingencies have to be assured. Do you see what is happening here? The insurer’s technical services pool has to be as good or better than the hosting providers that it is backstopping.

Technical Services:

The goal is to offset the worst risk cases for data loss and continuity losses to operations. This does not mean an up time guarantee. A certain major percentage of the insured population’s data and transactions has to be preserved for a reasonable premium. To support a menu of insurance coverage levels, the following technical services will probably have to be supported over time: ( I am avoiding an exhaustive technical discussion, who has time?).

1. Transaction Log Mirroring and ReplicationThe most basic, non data heavy service for small business is to maintain transaction logs. These logs can be shipped and ready-replayed to reestablish and reconstruct business transactions if a cloud provider goes down or out. Especially for POS and counter top retail business that are making the move from a distributed server based system, half the battle is capturing the transactions.
2. Data Storage ProxyIn addition to table-based transactions, businesses that store document images or objects may require a backup proxy to alternative cloud storage. No big hurdle here, other than the assurance and credibility.
3. VM machine image ready standbyIf and when (some say now) a set of elastic services cane be frozen and placed on near-line stand-by, this a service that was discussed in my research. In meetings with several VM vendors, including some heavy hitters from IBM’s superserver division, it became apparent that many instances of ready standby could be held in stasis, and re-synchronized to transaction logs in fairly short order, especially if we are catering to small and medium businesses, and not say, City Bank.I guess this is where the open cloud initiatives are going. It seems that many of the VM vendors are leading the way. For the purpose of the trusted pool, I felt after a period of study that this is possible and actually in practical use in limited cases.
4. API call brokerage for live services uptake.There are already existing services that broker web API’s. These services provide scaling, monitoring, billing, etc. Trusted services for the insured pool would maintain a similar brokered pool of API’s that would either pass through the 1st level of calls directly to the provider, or would be cut in as an alternate route if a timeout exceeds a predetermined limit.There are a few issues here that need massaging, as it not the business of the trusted services pool to provide transaction level assurance when your cloud or SAAS provider times out for a few minutes. Rather, a trusted API brokerage really makes the preceding items more elegant to provision. Even competitors can backstop each other’s outages if the Trusted Services are blind to the parties and payments settled by the trusted pool.

The up sells beyond trusted services might cover all of the value-added items provided in the course of selling business continuity services, such as records management, facilities, and telecommunications. These would add revenue lines, and complement the agencies commission incentives.

The technical services discussion could be covered in much more depth, and I may take that on after I clear my desk. However, I wanted to close this series and show that some folks, including my former insurance industry client, are seriously looking at the business of providing indemnification services and underwriting to cloud computing clients.

Rating and Certifying the Cloud Hosting and Web Application Providers. Part III

I have been slowly morphing my consulting practice. I usually offer myself as a product sector strategy asset. Product Managers and VP’s in the on-line applications business hire me to shoulder some of their burden when targeting specialist sectors – you know, industrial, technical, services, professional. These established clients usually have an idea of where their development efforts are heading. I came in to refine and prove the potential numbers. I developed approaches to paid subscriptions, industry specialty requirements, and I found innovative ways to exploit trade specific marketing. I was the product manager’s helper, and It was a good gig until about 2007, when the economy got soft. Analysts are the first to have their contracts cut.

Now I am delivering what I learned as an analyst, and applying this to evangelizing small and medium businesses. These folks are the end users I had quantified, targeted, and interviewed in my work for web applications providers. Small and medium bizfolks perceive the benefits of hosted services and cloud computing. They clearly perceive the benefits of fault tolerance, licensing advantages, and a simplified communications topology. These smaller accounts are certainly numerous. Can they abide having recurring computing fees forever? They certainly know that their internal server and workstation / mobile infrastructure (as traditionally delivered), costs them big time when things go bad.

So, before I close this series, which might include one more post on the brokering of technical services between partners and competitors to backstop business continuity failures, I will talk briefly about ratings and certifications for any remote provider of compute and storage – out there in the cloud.

Established utility computing providers, like AWS, are probably uninsureable as far as client’s needs are concerned; they are too big, and any coverage they do have insures only their own facilities and operations, which does accrue somewhat to the client’s benefit in the very long run, but does nothing when the downtime occurs. In the case of the big dogs, your insurance is their size and need to maintain a reputation. Eventually we will get our way, and instances of client computing services will get risk based pricing, preceded by business viability ratings, and of course, certifications for good facilities, operating procedures, and back office accounting standards. I’m willing to bet the ISO is working up something in their wild and crazy working groups as we speak.

One more thing: Why is PAAS different?

Briefly: clients using unitary applications or suites have invested a certain amount of time moving from  thick client project management to a hosted solution (one example). They have probably identified ways of moving the data off the platform (I hope), and so on. They are using an application, and we have all changed applications. PAAS is like marrying your company to .Net or some other standard. There is an investment, a rather large one for the SME, actually. For the lone developer making web apps, it’s ok.

The PAAS landscape is made of some very innovative and funny systems. I think you know what I mean. Some remind me of 4GL, some will let you host a language and framework, but not the integral database, some have language environments that are made from whole cloth. As a group they are fascinating and right on the cutting edge, and they are, as a group, under capitalized and illiquid. There are exceptions, but I will bet you the best dinner in Boston that one would be hard pressed to find a PAAS provider that would allow an industry ratings organization to inspect their capital and operations profile.

If a SAAS application company is illiquid in its essence, then we find another, move the data. If a PAAS company is under capitalized, we have a larger set of problems. The way migration has been handled for PAAS failures has been shameful.

Someone once asked me if the 25M round for an on-line storage provider places them in a well capitalized position; my answer was, “it depends, but generally, no, it is not considered well capitalized for the intended target and use case – 25M in a VC round ain’t shit when rating a crucial service provider that has not attained sustained profitability and near perfect uptime.”

Now, on to ratings and certifications for the cloud.

What is the difference between a rating and a certification? For the purpose of underwriting the risks of business continuity failures due to computing failures, there is an assumed, informal distinction.

Ratings are gathered from the outside in; companies are surveyed, their clients are surveyed, and they provide voluntary information. Also, performance data is collected in the wild – you know, up-time, availability, responsiveness to support tickets, and the like. Ratings take time to compile.  Sometimes, ratings can derived from historical data and a large set of participating clients. Risk based underwriting may make use of industry ratings, but the primary use of ratings, particularly those blessed by trade groups and associations, are to make clients comfortable.

Finally, only when ratings do not jibe with reality, does the following become apparent: Ratings imply no promise of performance. This may seem like a small thing, a semantic difference, but for those who price IT risk for third party payouts, it’s the whole ball game. One can not rate a business’ operational viability, nor its ability to survive and thrive without invasive audits by trusted, confidential examiners from industry standards organizations.

So, this where Certifications, capital C, come in. Certifications are invasive, involving on site auditing and live tests that determine specific functionality. ISO, SAS 70, and SystTrust, are some of the current examples of certs that are currently in vogue for typical data center assurances. Unfortunately, none of these standards, as good as they are, really addresses all of the issues underwriters need to individually insure a client of a cloud host, SAAS or PAAS provider. In the case of PAAS start ups, it’s a messy process to accurately quantify risks when so much muscle and blood has been invested in cutting over incumbent processes – and the fact that for some reason, the PAAS providers, taken as a group, are some of the shakiest kids on the block.

Big data centers can be certified, telecommunications can be certified, processes that handle customer data can be certified, etc. For these types of certs, AICPA is the best we have in SAS 70 and SysTrust. In order to indemnify clients using remote IT services (SAAS, Clouds, Grids, PAAS), we may need more.

You want more that SAS 70, or other certifications can deliver? The insurance underwriting industry in its forward looking moments knows that technology and operations are the least fragile variable in the total equation. In order to offer business continuity assurances to the Cloud’s clients, the carriers want audited viability in the following areas:

1) Management Background ( The principals backgrounds and disclosures being free from deception).

2) Operations audits (GAAP, Records retention policies, maintenance procedures)

3) Operations Liquidity (Does the company pass the viability test for a “foreseeable period of operations that encompass an adequate time horizon, considering the industry’s typical cycle of periodic upgrades and major technical watersheds)?

4) Security and Exposure to 3rd party liabilities. (Does the company operate in manner that would mitigate against common IT liabilities for data security, loss, and mishandling of customer information?).

Once these broad systemic root certifications can be determined, either through existing industry organizations or via a new body, then the underwriters can start processing the risks involved. After the risk is priced, then measures to operationally offset the risk can be applied. And…..

Once the risks are sufficiently offset and the risks are recalculated for those cloud offerings that voluntarily avail themselves of these aforementioned technically mitigated risks….then we can look forward to a developing insurance segment that can offer professional lines of coverage for cloud computing services.

Finally, finally, we come to the technical, operational offsets of client risks, where I am more familiar and on home ground. We will discuss using brokered services and API’s via blind third parties that will cover outages in the cloud. This is where the real work gets done. Without offsetting risks, there may never be adequate coverage options for clients of the cloud.

Next post!

Related articles by Zemanta

• Iasta Achieves SAS 70 Type II Certification (seomashup.blogspot.com)
• How to Turn Cloud Computing Into Big Business – A Peek Inside Amazon Web Services (xconomy.com)
• 5 more fresh articles…

The Strategist: Certification Services for the Cloud – Reliability, Continuity, and Indemnification Against Outages

Image via Wikipedia

I am going to write about a project that got stranded on my research pile when a well funded client decided that they did not wish to complete the contractual research allocation. The research directives encompassed finding a preliminary business model for underwriting business continuity risk within the rubric of cloud applications and hosting services. A concomitant directive was to research new and existing technological models that would offset the risk of such underwriting programs.

So there was an insurance underwriting and actuarial side, and a real systems side. I was to uncover the insurance industry’s perspective on underwriting SAAS /PAAS / Cloud, etc. I was to bring to the partner underwriters technical proposals that would offset the risk. The project was on a roll and then still birthed. I think it still has merit. I think that the failure of several VC funded net storage start ups points to this, and that even recent hours-long outages in the ‘clouds of the mighty’, should indicate that this analysis was not a complete waste of time. I certainly uncovered gaping holes in the standard insurance industry lines when underwriting business interruptions and continuity for advanced hosting and SAAS.

I am under NDA as to the identity and specific plans of the client, but what I learned, and the contacts I made, cannot encumber my portfolio of analysis and career endeavors. I have that in writing, and the former client, admitting to the invocation of an early termination clause,  is cool with that – bigger crises on the home front and all.

We analysts wouldn’t be worth much if we couldn’t (at least sometimes) feel things coming ’round the bend. Before the words “economic crisis” became a meme for all subsequent business failures, many esteemed colleagues felt there was excess capital flowing into redundant business models (YASN and YAVSS, for the initiated). This was an evil wind with bad portents. Too much VC cake was handed over to the ‘Valley Undertakers”, i.e., entrepreneurs who had fostered serial failures, break-evens, and maybe one or two small M&A’s, but who in the big picture had no business getting that much access to capital. So that’s the tableaux we have set at around 3/07.

I was working for an R&D lab in South San Francisco when my self-billed services (product strategy under contract) started softening. I was counting on an implied renewal to extend a six month term to 18-24 months. Well, they said they loved me.I was not alone in the exodus from Gateway Blvd.

I also had several quotes out around the Valley, and performed several live pitches for real make-money product strategies based on bedrock research. But something was in the air, a whiff of fear in the faces of those I was pitching, even at the most august institutions. I’ve always been a realist, and this was well prior to the words ‘economic meltdown’ becoming CNBC’s daily mantra. Many of my analyst-contractor colleagues in the Northern CA high technology sector also started to feel the chill.

So it happened to me a little before it happened to many of you. Despite accolades for the stellar work I performed, my contract was not renewed, and all my pitches and proposals in and near the city of San Francisco were not closing at the usual pace I was accustomed to. Until 2006ish,  I could close in a  month or two. Now in ‘07 I was being braced by the clients to be ready to sit on contracts for up to 90+ days. One of them closed and was aborted after 120 days. That project, hosted solutions business continuity underwriting and preemptive outage prevention, was a real money machine, with potential users, a realistic existing market model, and had reality baked-in. You get the idea. Sound business models are sometimes not enough when fear is in the air.

I researched market strategies for services offerings to rate, certify, and offer business continuity solution services for…..”The Cloud”. I want you all now to recall that in late ‘06 mid ‘07 “cloud” meant many things and had not yet gained that buzz cachet that it has now.

Cloud, ASP, SAAS, Hosted solution – all it means to the small and medium business owner is, “no in-house infrastructure or software’, or put more simply, “no stuff here”. Oh, throw in the poorly defined term, “Grid”. The subtle and not so subtle distinctions of transparent scalability, fault tolerance, and configure-ability are lost on most bread and butter businesses. I try where possible to avoid these distinctions with my clients, except to point out that a dedicated or multi-tenant web host or erstwhile server used for whatever purpose is not cloud like – in that we expect a certain amount of inherent scalability or flexible options for configuration with Cloud or Hosted grid offerings.

In other words: If you can point to the machine and its downtime or a request for upgrades in capacity generates a ticket, that’s not “Cloud-like”. If you can expect a certain level of independence from single point failures and have the ability to remotely configure additional capacity, well then, there you go.

SAAS and PAAS solutions; well, since we usually don’t get to choose the hardware for these applications, we usually almost never know if the provider of say, project management or accounting web services is Cloud like or not. These services may be running on infrastructure that is decidedly vulnerable to single point failures and scalability deficits. I’m fairly certian that many of the early entrants to the SAAS space were quite pedestrian in their hardware systems. But we never will know these things about a 37 Signals, or a Salesforce – what they run is what they run. But, their services are, “out there”, as opposed to “here”, and we pay by the month…so there you go again.

Shoot, that was a long preamble to an article on third party certification and business continuity services for hosted applications, cloud services, and customers of SAAS / PAAS, etc.

My work uncovered much ugliness in the arena of newly minted SAAS start ups offering webs apps covering accounting, project management, document management, etc. These sincere folks, many of them, did not have the legs to weather any storm. Being cockeyed optimists, they never conveyed their worst case scenarios to clients that considered the service mission critical. Who’s fault is that? – the customers for lack of due diligence, or the SAAS vendor? My early investigations pointed to a real thorny issue: Are any of these New Age SAAS providers, save for the select few, worthy of being underwritten against disruptions to client continuity?

In order to mitigate against a panoply of risk factors (such as under capitalization, under provisioning, etc.) I had to come up with some benchmark program requirements. I did this in concert with some other analysts who work in the more narrow field of recovery and fault tolerance. I had to find a way to get insurers involved in the actuarial portion of the solution so we could price the risk, and I had to get offsetting technological solutions to solve 90% or so of the most common technical / strategic disruptions to operations. There was, as well, a component of financial analysis that addressed transient issues of reinsurance that would stave off the kind of unnecessary business failures that in turn morph into technical failures. All of these issues are thorny and interconnected.

One of the most interesting areas of provisioning services for ensuring continuity of Cloud Hosting services was the use of competitive services for backstopping outages. This entailed proposals for mutual anonymity, competitive protections, etc., all while making sure that services would continue and that data would be protected without endangering a provider’s relationship with a client. Fascinating stuff.

The study of mutually reinforcing the interlocking forces of business viability on the part of the services providers, and the needs of the clients who are buying into this pool of insurance products, was a wild research docket that should have lasted well into 2009, but got stalled at day 120; it was just enough to whet my appetite. Ratings, certifications, standards, reinsurance, double blind technical services coverage by and for competitors (cost effectively and confidentially provisioned!) – This was a juicy assignment and an analyst’s dream.

I wonder if the concept still has legs? In my next post, I will list some of the actual programs and concerns that the research entailed. Or, maybe I will extend the current post.

Related articles by Zemanta

• CloudNews for February 6th, 2009 (cloudave.com)
• 5 more fresh articles…