After Amazon’s Stumble Anti-Cloud Rhetoric Is Expected, But Is It Warranted?

Apr 25, 2011 by Matt Ammerman

I like Phil Wainewright of ZDNet’s take on the Amazon incident last week. I like it partially because his post-chaos “seven lessons to learn from Amazon’s outage” reads oddly similar to my recent Transparency in the Cloud series. Mostly, though, I appreciate Phil’s approach because all of his lessons are targeted at the cloud services consumer.

Without a doubt, the blame for last week’s outage falls squarely on Amazon’s shoulders, but the responsibility to understand risk and adjust appropriately is in the hands of those that choose to use cloud-based services either to consume services, or to provide services to other companies.

One thing about centralizing services in the cloud is that it makes everything extremely visible. What was traditionally hidden behind private firewalls is now out in the open for everyone to see. I have a hunch that the aggregate downtime and subsequent hours spent by private IT departments on a regular basis far exceeds even the four days it took Amazon to clean up after this incident.

Which brings me to my point:  There are two things that cost money during outages – 1) lost business, and 2) resolution efforts.

Lost business is a sunk cost, whether the outage is with your website hosting company, your cloud services provider, or inside your own private datacenter. The mere fact that you are in an outage situation means you are losing business. The difference is that in a private outage situation, you are also compounding the loss by shelling out the dollars to fix the problem. In this case, it was Amazon’s software (and/or hardware) that failed, let them foot the cleanup bill (and they happily will)!

Regarding the anti-cloud sentiment that seems to be pouring from mainstream outlets, I’ll borrow from CNN’s sensationalistic metaphor. Did we stop building ocean liners after the Titanic sank? Did everybody start crossing the Atlantic in tiny dinghies because they didn’t trust larger ships?

Smart people who specialized in the things that went wrong with the Titanic figured out how to make those things better and prevent disaster from happening again. Given that we all know there’s inherent value in cloud services, instead of throwing around anti-cloud sentiment, let’s all focus our energy on helping cloud providers like Amazon get better at it. We can do that by learning and applying our own lessons, and contributing our own technologies and talents.

read more

Transparency In The Cloud, Part III: 2 More Questions to Ask Every SaaS Provider

Apr 18, 2011 by Matt Ammerman

Continuing on the theme of Parts I and II, this article provides two more questions that all consumers of B2B SaaS should ask their providers.  While the questions in Part II were centered around providers’ ability to maintain speedy and reliable service, the remaining questions focus on their ability to be flexible in pricing and customization of their offering.

Question #1: How flexible is your pricing?

Ah yes, the custom contract.  Dangling off the salesmen’s tool belt since the dawn of selling. In the land of packaged software licensing, sales folks worked off of sales models that allowed them to play whack-a-mole until they had an offer suitable to win your business. In the subscription-based access world of online services, the process isn’t so simple. Often times, the ability of a salesperson to meet your financial requirements in both pricing and billing terms is tethered to the service’s ability to meet your business needs.  I know, it sounds silly, but allow me to use a real world example that I have been telling people about for years.

In the book Founders at Work, 37Signals partner and creator of Ruby on Rails David Heinemeier Hansson dishes on the early days of 37Signals.  Particularly of interest here is his story about how they had programmed the flagship service to bill customers on a yearly basis.  This meant that upon signup, a new customer would be invoiced for their first year of service, gain access to the application, and subsequently be billed annually for renewed access.  Just a few days before the launch of said application, their bank (read: creditor) notified them that due to lack of credit history, they were not allowed to bill on elongated terms.  They had to collect money from customers more frequently.  They delayed the launch for roughly a month while they re-engineered the application’s billing systems to allow for monthly billing cycles.  Now, the 37Signals team is a smart team, and they were able to skirt disaster and launch an incredibly successful software as a service business.

The point of re-telling this story is not to warn service providers, but to motivate end-users to ask questions about how flexible a provider can be with their pricing and billing.  Understand what your provider(s) can and cannot do with respect to charging you money. Learn about how the provider actually bills you. In a world where we’ve become accustomed to simply checking our bank accounts for charges by PayPal, make sure that your provider(s) have a way to work with you during good and bad times, and the many permutations of financial standing that happen in between.

Question #2: What if I don’t need everything you have to offer?

If you’re thinking that this sort of the same question as #1, you caught me. Almost. Feature granularity is certainly a conversation about flexibility, but from our end-user perspective it’s not the same topic as pricing and/or billing. What I’m talking about here is flexibility in application functionality. It used to be that the license you purchased dictated the features you saw; the license literally contained the knobs and switches that controlled application features. Subscription-based software as a service might mean that a provider has to give up cutting custom license terms (ok, ok, see #1). In that event, you want to be sure that the provider hasn’t tossed those knobs and switches along with their licensing mechanism.  Can the service be tuned to suit your needs? Can it be tuned to suit others’ needs without affecting your experience? Can pieces of functionality be turned on in a pinch? Can functionality be hidden from some users and not others? How quickly can new functionality be enabled?

This line of questioning serves only to avoid the dreaded “it’s not you, it’s me” conversation with a service provider who just can’t meet your needs.  At least if you ask the questions ahead of time, you enter into the union knowing precisely what the service has to offer, and whether or not it can change.

So here we are, the software as a service end-users, ready to go forth and subscribe.  I hope you feel a bit more empowered as you venture into the world of service-based software. Armed with the right questions, we have the power to shape how this all happens and get what we want out of the software companies-turned-service providers.  After all, it’s in our best interest to help make every provider we encounter a superior deliverer of software.  And don’t worry, they’re more scared of it than we are.

read more

Transparency In The Cloud, Part II: 3 Questions to Ask Every SaaS Provider

Apr 11, 2011 by Matt Ammerman

In Part I, we recognized that end-users of B2B software are in a unique position to drive the way internet-based services are delivered.  This is important, because the data shows that most of us are going to at least start to transform the way we consume software in our businesses within the next couple of years.

We all know that answers lead to knowledge, and knowledge leads to power (Your first Jedi allusion of the week!). So how do we, as end-users, get the upper hand when it comes to software-as-a-service? We do this by asking the proper questions. To get you started, here are the first three questions you should ask every SaaS provider you encounter:

Question #1: How does your service scale?

Historically, software companies needed only worry about how well their software could handle the load within the walls of the largest customer they had.  For most deals, they could get away with telling us that the software is used by a token Fortune 500 company that is 4 gazillion times bigger than us. We’d extrapolate from numbers well above our heads and inevitably say “Well, if it works for them, it must work for smaller companies like mine.”  On the contrary, in the software as a service world, the logic often works in reverse. Remember that our software vendors are now responsible for mustering the ping, power, and pipe to provide service to all of their customers as one large entity.  In the aforementioned scenario, that makes most of us small fish in a big pond.  If a service provider doesn’t have a viable approach to scalability, which means more than just “throwing servers at it,” then they are going to experience something called “buckling.” When a service provider experiences buckling, and their service slows to a crawl, or stops completely, it makes the fact that they just landed another 10,000 seat Fortune 500 deal not so impressive to the rest of us.

Ask them how they scale.  Do they provision a new server for every customer? (if they do, say “welcome to 1999,” and then run.) Do they provision a new VM for every customer? If so, how many VMs of their particular software footprint can fit on a single physical server in their datacenter?  Have they built scaling mechanics into their application or are they relying purely on infrastructure growth?  All of these things play into that “buckling” thing I mentioned, and often times you can gauge if and when a provider will buckle simply by knowing the answers to these scalability questions. For more on this, see economies of scale.

Question #2: How do you release new versions of your service?

Releasing software on CDs is safe.  It’s safe because there’s an entire protocol around the release and there’s time between when the software is ready and when the bulk of customers will install it.  That means there’s ample time to test the software and collect feedback, and there’s even time to fix mistakes after the software has been released.  In the world of online services, there are no “take backs.”  When a service provider updates their services, chances are we will see these updates the very next time we click a button in our browser or refresh the page.  That gives them very little room for error.  To circumvent this situation, and make life a little more familiar, some service providers declare scheduled upgrades.  They carve out little windows of time to make the service unavailable to anyone but themselves, and figure the fact that their customers are aware of this impending outage makes it ok.  Calling timeout gives them the opportunity to deploy the update and test it in the privacy of their own datacenters, just like they used to before releasing a new CD. The problem here is that their timing will never be your timing, and although it may not happen often, eventually there will be a scheduled update that conflicts with your need to access the service. The good service providers will find a way to upgrade you without downtime.  Find one of them.

Question #3: How do you plan for disaster recovery?

Even the mighty Google is not impervious to the whims of server ghosts. Just ask the 40,000 or so Gmail users whose inboxes recently went *poof* in the night.  But that’s Gmail, a free consumer-focused email service.  Google rightfully offers little to no guarantee that this won’t happen to you or me tomorrow.  This might be acceptable for our personal email accounts (what do you expect for free?), but would this type of “c’est la vie” approach to your business’s data fly with your CEO?  Not mine. Therefore, it’s imperative that you know of your service provider’s disaster recovery and business continuity plans.  Disaster recovery means a broad spectrum of things, so there are a lot of questions to ask.  Start with a couple: If data is lost, how quickly can it be restored? Can another customer potentially do something that would result in an outage or data loss for me?  If half of your datacenter falls into a spontaneous sink hole, how many customers would go with it?  Hint on that last one, if the answer is more than zero, chances are their plan is not worth your dime.

There’s a lot more to the disaster recovery discussion, but I will leave it here for now, lest I spark a conversation that will have us exercising the disaster recovery plan for this very blog.

In Part III of Transparency In The Cloud, we’ll continue our list of important questions to ask all SaaS providers.

Stay Tuned!

read more

Transparency In The Cloud, Part I: The End-User Transformation

Apr 6, 2011 by Matt Ammerman

In case you didn’t know, the days of business-to-business (B2B) software-as-a-service are upon us.  If you’re a software developer and you haven’t begun planning a SaaS offering, stop reading this article right now, go gather your team and get started.  Seriously, you’re already late.

Ok, now that they’re gone, this article is for the rest of us: the B2B software end-users.

I have it on good authority, that in the next couple of years most of us are going to throw away our piles of compact discs and DVDs and replace them with bandwidth.  We’re going to say goodbye to license fees and free-up some square footage by dismantling our servers.  We’re then going to embrace the technologies that give us access to always-on, internet-based services which we will access from our new server-rooms-turned-corner-offices.  The benefits are manifold:  accessing software typically costs less than owning it, online services are accessible from any location and on a plethora of devices, and we don’t have to worry about things like hard drive failures when our documents aren’t actually stored on our hard drives.

The unfortunate side-effect of our herd-like flocking to internet-based services is that, by forfeiting our ownership of the servers and software that fuel our businesses, we put our destinies in the hands of software companies that, put simply, are software companies.  They’ve spent many years honing algorithms and interfaces that made us want their software in the first place but unfortunately, those years were not spent learning how to offer that software, as a service.  After all, we bought the servers, we provided the power, often times we even installed the software ourselves. Believe it or not, sometimes we’re better at running software than the vendors who sold it to us.

Fortunately, some software companies are comprised of incredibly smart people who do amazing and innovative things. They also have amazing tools available to them to supplement what they lack in experience. I have every bit of faith (*cough* SaaSGrid) that with some hard work (*sniffle* SaaSGrid), and a bit of help (*yelling* SaaSGrid), our trusted software vendors will seamlessly make the transition from shrink-wrappers to world-class service providers, without us noticing as much as a blip on our B2B, software-consuming, radars.

As end-users, we have an obligation to ensure this whole thing goes smoothly. We need to hold our service providers accountable.  One way to do that is by relentlessly asking questions. Interestingly, no one is more qualified than us to ask the appropriate questions, because we’re the ones who’ve been running software on-premises for 20-years. We know the scenarios and situations to avoid, and most of these scenarios translate into very good questions that each and every service provider should be able to answer in a way that not only gives you the warm and fuzzies but also makes technical sense.  Remember, we’re banking our businesses on these companies’ ability to learn how to provide software-as-a-service. I’d at least like to know that they have a plan.

In part two of the Transparency In The Cloud series, we’ll start a list of questions that you should ask each and every SaaS vendor you approach.  The questions are designed to help us guide the B2B SaaS transformation by making us all knowledgeable and empowered SaaS end-users.

Stay tuned!

read more

More On Cloud Middleware

Jan 31, 2011 by Matt Ammerman

Sinclair’s recent post Cloud Middleware: The Language Shared by Network Engineers and Developers posits that the cloud space has seemingly maintained a bias towards infrastructure offerings (IaaS) and is now at an “inflection point” where a common layer – the cloud middleware layer – will be required by developers and network managers alike to, as Jeff Kaplan puts it: Bridge the Great Divide in Cloud Computing.  I’d like to expand on this theme.

I help ISVs with their plans to move to the cloud every day.  I work with dedicated SaaS teams made up of developers writing code simultaneously with IT staff planning for app rollouts and operations.  I’m fortunate in that they’ve chosen SaaSGrid as cloud middleware, and as such, have already chosen to bridge the “great divide” for their project.  However, what I find very interesting in particular, is how keen ISVs are to avoid making permanent decisions when it comes to infrastructure and hosting – especially early on in the project.  ISVs habitually tackle “easier“ problems first, and familiarity on the development side means that their developers take on the role of the hare, while IT staff takes a slow and more calculated tortoise-like approach.  ISVs I’ve worked with spend a disproportionately large amount of time laboring over the specifics of the infrastructure on which their app(s) will run, even while their development teams move forward swiftly.  Developers are eager to get rolling, while network managers maintain furled brows.  It makes sense when you think about it – they’ve all been a part of software companies that know their specific problem domain well.  Developers are already comfortable innovating in their space, the cloud is just a new arena.  Where experience fails these ISVs, and where they become overly thoughtful and even guarded, is in deciding how to become a service provider – how to host an application as a service.

The tendency for ISVs to think of development and deployment serially (“Keep writing code, we’ll know how to deploy it by the time it’s ready”), exposes them to costly deploy-time unknowns.  Allowing this disconnect starts a technical debt timer that runs the course of their project’s development phase.  I’m not saying that ISVs should accelerate their decisions on infrastructure to match the speed at which they develop – I’m saying that they need a buffer in the form of linkage between development and deployment that is present from day one of their project.

Unfortunately, across the industry this is also currently where they experience the largest gap. The trouble with many current cloud offerings and managed hosting services is that they require host apps to speak their language. Or, worse yet, they require the host apps to maintain knowledge of the cloud infrastructure itself – “Which hypervisor am I running on?” is not a question an application should have to ask at any point in it’s development or production lifespan; and 99% of the time it’s an unanswerable question on day one.  These requirements just add to the pile of work already on ISVs’ plates and essentially require that they make awkwardly timed deployment decisions (which they are hesitant about) at the onset of their project’s development.  And while some ISVs can manage (and maybe afford) the added workload, there is still a lingering trepidation – a hesitance to commit.  Most likely the fear is that baking infrastructure knowledge into application code hinders portability and removes any agility.  In response, I find many teams asking these cloud providers and even their own IT personnel “Why can’t the infrastructure speak my language?”  As Sinclair points out, the answer lies in a common layer, a way for application architecture (developers) and infrastructure (network ops) to speak a common language; a way for the two largest pieces of a SaaS project to move forward in unison – this is cloud middleware.

Becoming a successful service provider mandates a symbiosis between application architecture and hosting infrastructure – but that doesn’t mean developers need to learn infrastructure or IT staff must learn architecture.  Instead, we have technologies such as SaaSGrid to “bridge the great divide”.

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3600+ members and is growing every day; make sure you’ re not missing out and join today!

read more