SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for the ‘service’ Category

Most Marketing Advice Tells Us How to Market to Marketers

Posted by Bob Warfield on August 18, 2014

free_lunchThink about it–the experts out there writing marketing advice as part of their content marketing strategies are all selling something.  They’re either selling software, consulting, or some other product.  And the audience they’re selling to are marketers.

Sure, many of them have practices or history that involved marketing to non-marketers, but right now what they’re doing is talking about how to market and the audience for that is other marketers.

I noticed a long time ago that what they were saying didn’t work for my own bootstrapped company (CNCCookbook).  It was fascinating to me when things that were repeated so often they seemed like gospel didn’t do me a bit of good, or worse, they actually lowered my conversion rates.

Here are some examples:

-  Infographics:  They’re all the rage.  Personally, I hate them because I am usually reading blogs on an iPad where they take too long to download and then you scroll and scroll and scroll.  But, the intelligentsia largely argues that whizbang infographics are some of the best content you’ll ever produce.  So I have dutifully produced a fair number of them and they’ve all yielded sub-par results.  There are likely a lot of reasons for it.  For example, when marketing to marketers, a lot of the audience are marketers marketing to more marketers.  An infographic that can be shared can have a trickle-down effect in that sort of niche.  In my world, I actually have by far the largest blog in my space and most of the other blogs are by stodgy corporations that aren’t about to share someone else’s infographic.  Disclosure:  I decided to write this article more or less in response to a Neil Patel article on how he is finding Infographics less effective over time too.

-  Controversy:  Lots of authorities have recommended controversy as a way to get read.  Some hugely popular blogs are so snarky I can hardly stand to read them sometimes.  Given my own personal distaste for this kind of thing, I haven’t done much of it, but I did feel it was being recommended so much that I had to at least test it for results.  Nada.  No interest.  Come to think of it, Neil Patel discovered some shortcomings here too.

-  Social Media: I’m down to running robots that post my blog posts at this stage.  Any more investment has never shown much result. Every time Facebook tweaks their algorithm you get less reach and it makes even less sense.  Twitter has never performed for me.  I remain convinced a huge percentage of Twitter users are bots that are incapable of being my customers, and recent Twitter disclosures seem to confirm this.  At best I regard Social Media as an alternative to RSS Readers and Email for a very tiny sliver of my audience.

- AdWords: Never seen these be productive. All the good keywords are hugely expensive due to competition. If you try to go too far out on the long tail, Google refuses to deal with those words saying there isn’t enough traffic.  I was so not surprised to read that eBay cancelled all their AdWords and it didn’t affect revenues.  Of course Google then levied a bunch of search penalties on them for having publicized this and they missed a quarter.

- Removing navigation from landing pages. I’ve tested this many times and every time it reduced the conversion rate. Hard to tell for sure from the analytics, but the bounce rates went up like crazy. My audience are highly technical, have lots of questions, and just didn’t like being stuck on the page with nowhere to go for more information.

-  Headlines on Landing Pages.  This one has been particularly frustrating.  I’m supposed to tell them what problem I am solving in clear and concise terms.  I have tested that endlessly and it gets poor results.  My audience is happiest (so far, I will keep testing this one for years) with a headline that too me seems far from benefit-speak, “Get the Latest Technology.”  I’ve paraphrased it so I don’t have to tell the back story, but that’s it in a nutshell.  People aren’t supposed to respond to that kind of thing.  Who cares what the latest technology is, what solves MY problem?  Yet it consistently beats every benefit-oriented headline I have ever tested, usually by a wide margin.

So what’s the answer?  Should we ignore all the marketing advice?  Should we maybe do the opposite of what they say?

The answer is not nearly so black and white, and if you think it is, you run the risk of throwing the baby out with the bathwater.

What every marketer has to realize (if they don’t already) is that every niche is different.  All of this Marketing Advice that’s available is great, but it isn’t gospel at all.  It’s just ideas.  The one critical deliverable you have to bring to the table to be a successful Marketer is some mechanism that takes all those ideas you want to try and effectively separates the wheat from the chaff.  That’s really the essence of Growth Hacking as I see it.  And the tools you need to do that work have to be Analytics and A/B Testing coupled with a keen analytical mind that thinks in these sorts of terms.  That keen analytical mind is particularly crucial because it is an art and a talent to devise experiments and then gain accurate actionable insights from them.  If you introduce too many variables (often unwittingly), your experiment may not be telling you what you think it is.  This is one reason why I test the Big Gospel ideas many times before I conclude they’re just not working for me.

So, by all means, collect the accumulated wisdom that’s out there, but verify that it actually works for your niche and your business.  I guess that’s what they mean by, “There ain’t no such thing as a free lunch.”

PS

I keep clippings of all the good marketing articles I find in a special blog called “Firehose Press.”  Check it out for a ton of good ideas, and remember, your mileage may vary!

Posted in business, Marketing, service | 1 Comment »

Authentication as a Service: Slow Progress, But Are We There Yet?

Posted by Bob Warfield on July 11, 2014

BankVaultSmallAuthentication as a Service solves a problem every Cloud Developer, mobile or desktop, has to solve.  As one player in the space, AuthRocket, puts it:

Do you really want to write code for users, forgotten passwords, permissions, and admin panels again?

To that I would add, “Do you really want to have to be a world class expert on that stuff to make sure you don’t leave some gaping security hole out of ignorance?”  I think the answer is a resounding, “NO!” to both questions.  Why do it in this world of Agile Development, Lean Startups, and Minimum Viable Products?  It’s one of those things everyone does (and should do) pretty much the same way from a user’s perspective, so there is no opportunity for differentiation.  You have to do it right because the downside of security problems is huge.  You have to do it right up front to protect your customer’s data and your investment (so nobody gets to use your products for free).  There’s basically very little upside to rolling your own (it’ll only slow you down) and tremendous downside.  Hence, you’d like to buy a service.

I keep going around this block for my own company’s (CNCCookbook) products, and I surely would like to get off that merry g0-round.  I wanted to buy this some time ago, and have written about it for quite a while.  For example, in an article I wrote 4 years ago on PaaS Strategy (Platform as a Service), I suggested login would be an ideal service for a pass to offer with these world:

Stuff like your login and authentication subsystem.  You’re not really going to try to build a better login and authentication system, are you?

I sound just like AuthRocket there, don’t I?  I’m sure that’s not the earliest mention I’ve made, because I’ve been looking for this stuff for a long time now.  As I say, I had to roll my own because I couldn’t find a good solution.  I would still like to replace the solution that CNCCookbook uses with a nice Third-Party service.  I only have few very generic requirements:

-  It has to offer what I need.  Basically that’s Email + Password login with all the account and forgotten password management interactions handled for me.  It would be very nice if they do Federated Login using the other popular web services like Amazon, Facebook, Twitter, Google, or whatever.  It would also be very nice if it could do 2 factor login.  The latter two are optional.

-  It has to work well.  I judge this by who has adopted it and how it is reviewed.

-  It has to be here for the long haul.  I’ll judge this by size of customer base and quality of backers.  AuthRocket, for example, is still at the invitation-only Beta stage.  That’s too early for me.  I have mature products and don’t want to have to change out this service too often.

-  It has to be easy for me to access the API’s.  I prefer a nice RESTful API, but I will take a platform-specific API for my chosen development platform: Adobe Flex.  And no, I don’t want to debate that platform, it has worked fabulously well for me, the products are mature, and I am not looking to switch.

-  It has to be easy to tie it back to securing my data in the Amazon Web Services Cloud.

-  Optional Bonus:  It helps me solve the problem of disconnected data access.  My apps are Adobe AIR apps.  You download and can run without a web connection for a period of time.  This is important to my audience, but means I’ve got to use data models that keep local copies and sync with the Cloud when they get connected.

While my apps are not yet available on iOS or Android, all of those things are almost exactly the same problems any Mobile App developer faces.  Therefore, this ought to be a hotbed of activity, and I guess it is, but so far, I still can never seem to find the right solution for me, and I don’t think I’m asking for anything all that crazy.  But, I have yet to find a solution.  Let me tell you a little bit about my 2 most recent near misses.

Amazon Cognito

I was very excited to read about Amazon’s new Cognito service.  At CNCCookbook we’re big Amazon believers, and use all sorts of their services.  Unfortunately, at least until Cognito, they didn’t really have a good service for solving CNCCookbook’s authentication problems.  They had IAM, which is a very complicated, very heavy-weight, very Big Corporate IT kind of solution.  It looked kind of like maybe you could do it if you had to, but you’d still wind up writing all the darned password management stuff and it looked like it was going to be a real ordeal.  Mostly, I think of IAM, as the tool used to define roles for how broad classes of users can access the various other Amazon offerings.  I wanted another service of some kind to be the sort of simpler, friendlier, front end to IAM.  Enter Cognito, and it sure sounded good:

Amazon Cognito lets you securely store, manage, and sync user identities and app data in the AWS Cloud, and manage and sync this data across multiple devices and OS platforms. You can do this with just a few lines of code, and your app can work the same, regardless of whether a user’s devices are online or offline.

You can use Amazon Cognito directly from your mobile app without building or maintaining any backend infrastructure. Amazon Cognito handles secure app data storage and sync, enabling you to focus on your app experiences, instead of the heavy lifting of creating and managing a user data sync solution.

A guy like me loves the part about, “You can do this with just a few lines of code” followed by “without building or maintaining any backend infrastructure.”  Now that’s what I’m talking about, I gotta get me some of this!

It’s nearly all there:

-  Amazon is an outfit that can be trusted for the long haul.

-  REST API’s are no problem, that’s how Amazon prefers to operate.

-  Tie back to other Amazon Web Services?  Puh-lease, who do you think you’re talking to, of course one Amazon Service talks to the others!

-  Sync?  Yeah, baby, that’s what Cognito is all about.  More potential time savings for yours truly.

Oops, just one little shortcoming:  it only does Federated Login via Amazon, Facebook, or Google.  That’s cool and all, but wheres my Email + Password login so I can seamlessly move customers over to it?  Maybe I missed it, maybe it’s coming, or maybe Amazon just doesn’t think it’s important.  Can I live with forcing my users to make sure they have either an Amazon, Facebook, or Google account?  Yeah, I guess maybe, but we sell a B2B app and it sure seems kind of unprofessional somehow.

Amazon, can you please fill this hole ASAP?

Firebase

I hear fabulous things about Firebase, I really do.  People seem to love it.  It’s chock full of great functionality, and on the surface of it, Firebase should fit my needs.  Yet, when I dig in deep, I find that the login piece is kind of a red-headed stepchild.  Yeah, they advertise Email + Password Login, and they even tell you how to do it.  But there’s no RESTful API available for it.  They list all the right operations:

-  Login, and returns a token
-  Create a new user account
-  Changing passwords
-  Password reset emails
-  Deleting accounts
etc.
However, it appears that those things are handled by a client library which is in a very dev platform specific format.  If you use one of their chosen platforms, it’s ok.  If not, you can only use their rest API’s for the Cloud Database–no login functionality.  That’s going nowhere for me.  It would’ve been so much nicer had they packaged what’s in the client library in their Cloud and provided RESTful API’s for the functions I’ve listed.  As I told them when I made the suggestion, that makes their offering accessible to virtually every language and platform with the least effort for them instead of just the few they support.
Conclusion:  Crowd Sourcing?
Hey, I’m open to suggestions and the Wisdom of the Crowd.  Maybe someone out there knows of a service that meets my requirements.  They seem pretty generic and I’m frankly surprised I still can’t find such a thing after all these years of building almost anything you can imagine as a service.  We’re not very far away from it.  Either Amazon or Firebase could add the functionality pretty easily.  I’m hoping maybe I’ll get lucky in the next 6 months or so.  If anyone knows the right people in those organizations (or their competition), pass this post along to them.

 

 

Posted in bootstrapping, business, cloud, mobile, platforms, saas, service, software development | Leave a Comment »

Good Customer Experience Trumps Good Customer Service. Bad CUX Trumps All. A Tale of Chukka Boots and Photoshop.

Posted by Bob Warfield on January 22, 2014

ChukkaBootsGood Customer Experience trumps Good Customer Service, even if you are Zappo’s.  My wife quit buying shoes from Zappo’s after they sent her the wrong pair of shoes for the third time and she had to return them.  They didn’t do it all on the same transaction, it happened over a fairly long period of time.  And yes, the Zappo’s Customer Service people were wonderful as always.  But it didn’t matter–the underlying Customer Experience was giving her the wrong shoes and she only allowed that to happen so many times before she gave up on them.

I had a similar experience with Zappo’s, but I didn’t even get as far as Customer Service.  I have bought shoes from them once–a nice pair of Clark’s Chukka Boots.   Great!

Some time later, I went looking for some tennis shoes.  I have a penchant for bright red shoes of the most exotic design possible that I wear when I go to hear live music.  I went straight to Zappo’s, found a pair of shoes I wanted, and tried to purchase.  I expected to be able to use my Amazon account, given they’re owned by Amazon and all, and it looked like I could do that, but I actually couldn’t quite make it work.  I don’t have an account on Zappo’s, because in a time of data breaches like Target’s, I open as few accounts as I can.  So I moved on.  It came time for me to buy another pair of shoes and I went  back to Zappo’s again, thinking that companies as savvy as Amazon and Zappo’s would surely have fixed the problem.  I found the shoes I wanted and tried once more to buy them.  No joy.  I could find no way to buy on my Amazon account and did not want to spend the time opening a Zappo’s account.

Not only did Zappo’s lose the sale of 2 pairs of shoes, but I just won’t go back there again.  It isn’t clear to me Amazon cares much, because in the end, I did buy those 2 pair from Amazon.  But if there was a good alternative I was familiar with, I would’ve skipped Amazon too, just for annoying me.

Now, how hard would it be for Zappo’s not to send my wife the wrong pair of shoes 3 times?  She doesn’t buy shoes all that often, so it was surprising it happened to her so many times.  And how hard would it be for Amazon to make it easy for me to buy shoes from Zappo’s with my existing Amazon account?  Come on, this can’t be rocket science for a company like Amazon.  If Google can figure out to put a birthday logo on their search page on my birthday because it picked up my birthdate somewhere in their far flung empire, Amazon can let me buy Zappo’s shoes with an Amazon account, right?

Fast forward to this morning.  I was doing something and fired up Adobe Photoshop CS3 (yes, I have had it for a long time!).  It immediately announced I had 2 days left to activate or it would die.  Great, I did remember it asking a few days ago.  I had tried and it kept telling me it had an Internet connection problem.  I knew it wasn’t at my end, nothing else was complaining, so I figured I try again–they surely had fixed their problem by now.

No joy.

I was forced to use their phone activation.  With some trepidation I dialed the toll-free number and waited.  I really hate phone support.  It just isn’t ever a happy thing.  Ever.

Eventually, it had me key in a 24 digit serial number followed by a 32 digit activation code using my phone’s keypad.  Wow, that was a joy–not!  But, Photoshop at least did pop up a box that had the phone number to call plus these two lengthy codes to make it easier.  Unfortunately, the phone robot announced my activation code did not have enough digits.

WTF?!??  This was exactly the same code that Photoshop was telling me was the one to use.  How could it be wrong?

I tried twice, to no avail, at which point it told me to hold for a support representative.  Good, I was ready to let some human being know what I thought about all this after having used the software for several years.  Unfortunately, after a 5 minute wait, the Adobe side announced that they were no longer handling activation problems by telephone and gave me a URL I would have to visit with my browser to fix it.  Of course my blood pressure went up to the next DefCon level.

I went to the page suggested and couldn’t find even a hint of clue about what to do.  It was kind of a haphazard FAQ that only listed a few things, none of which could possibly be at issue.  When I got to the bottom, there was a Chat button with a message that cheerfully informed me I could get on right away with an agent if I would simply click.  So I did.

Of course as soon as the chat window opened, it informed me there were other customers ahead of me in line.  WTF?

Okay, deep cleansing breaths.  After no less than 10 messages informing me I was still waiting (no duh, I know I am waiting), Kumar finally popped up.

Kumar is mostly robot.  He is no doubt based on the old ELIZA simulated psychiatrist program which would always turn your question back around without really ever answering much.  It’s a primitive AI technique that’s been around forever.  Try it if you like, it’s kind of creepy in the same way that Kumar was.  I had to provide a description of my problem up front, and Kumar would ask me questions that were phrased along the lines of what I’d already told it, but that didn’t really add much color to the situation:

“Hi Bob.  You’re here because you can’t activate your Photoshop?”

“Yeah Kumar, that’s what I said in the original description.”

This is where Kumar gets clever.  Every time I respond, I get back a message saying, “Okay Bob, I’ll be back in 2-3 minutes after I check into that and take the necessary actions.”  Literally every single response I made, it would do that.  This is because Kumar, or whatever the real human being is named, is sitting in a giant call center somewhere dealing with probably 100 customers simultaneously.  He doesn’t want to get back to any one of us too quickly lest we monopolize too much of his time and annoy the other customers.  So, he uses all this clever software mostly to stall us customers so he can handle more of us.  Sweet!

He asks me to type in my 24-digit serial number (DOH!), but fortunately, I can just copy and paste it (Hah, outsmarted you bozos!).  Then he goes away for extra long–longer than the 2-3 minutes promised.  When he gets back, he wants to know my email for my Adobe customer account.  Oh boy.  Each piece of information will be asked for at 5 to 10 minute intervals–this is going to be painful and I have an appointment in 10 minutes.  I call the appointment to say I am coming, but I will be late.  It’s taken me 45 minutes with Kumar to get this far.

And then, a bit of magic happens.  Kumar comes back and says it’s all fixed, please try again.  I do, and low and behold, the Internet activation works.  A modicum of happiness ensues and I recall the nuclear bombers my DefCon blood pressure rise had summoned.  Then I started thinking about what had happened. Basically, the only reason online activation, had failed, the only reason I had worried whether I would fail to activate and thereby lose a valuable tool, the only reason I had to spend 45 minutes trying to tell Kumar the two pieces of information needed to fix the problem, the only reason I was getting really ticked off at Adobe, was because they wanted to associate my serial number (Kumar didn’t even ask me for the activation code) with my email.

Remember when I said I didn’t create an account with Zappo’s?  Well I also didn’t bother registering Photoshop.  It used to pop up a box about every 2 weeks asking me to fill out an elaborate form, and I would just tell it to go away.  Eventually it offered me the chance to tell it to never ask again, and I did so, thinking what a relief.  Nowhere did they tell me that eventually some power that be would decide they were going to force me to reactivate software that had already been activated and then put me through a painful experience of apparently having that activation fail, just because they wanted me to register.  A registration they no doubt needed so they can send me better marketing spam.

Can we see by now how to apply the maxim that Good Customer Experience trumps Good Customer Service?  Adobe didn’t really give good customer service, BTW, it was terrible.  I don’t blame Kumar for it.  I blame a Draconian wall and a moat filled with alligators designed to keep costs down on a cost center (Customer Service) that was built by a left and a right hand not knowing each other in a large bureaucratic organization and a marketing organization that only cares about filling its lead hungry maw.  It’s about par for the course with large organizations but it also happens to small organizations that pride themselves on treating customers well.  Tragically, it is so unnecessary and counter-productive too.

Let’s take Adobe’s case.  One could argue they never should’ve resorted to all this to connect my email to a serial number.  Let the man not register.  Or, they could’ve just told me I had to register to activate.  Hell, they could’ve just asked for my email as part of the re-activation and I’d have been happy.  Or they could’ve asked me to login to my Adobe account, also acceptable.  There are endless up front Customer Experience things they could have done to eliminate the need for me to deal with Customer Service at all.  Ironically, it would’ve been cheaper to do that.  45 minutes of Kumar and all those automated voice response systems had to cost something.

I run a one-man SaaS company (actually there are a couple part timers, but I’m making a point).  I do all the Customer Service myself.  Whenever and wherever I can, I try to change the User Experience to eliminate classes of Customer Service I see over and over again.  I have to just to survive.  Best of all, it makes the Customers happier and less frustrated.  The next time you’re gearing up a new release of your software, e-commerce front end, or whatever, ask what you can do to reduce the need for Customer Service.  Find out what the common sources of it are.  Get rid of a few of them every time you ship another release.  It’ll be a Good Thing for all concerned, I promise.

Posted in amazon, customer service, Marketing, service, strategy, user interface | Leave a Comment »

Don’t Bury the Map With the Treasure: Thin Clients Trump Apps in Walled Gardens

Posted by Bob Warfield on July 10, 2013

FeedlyBugOne of the questions every SaaS company will have to be able to answer for their customers is, “What happens if you go under?”  It’s actually a fascinating question, and one you have a chance as a vendor to think about and turn to your advantage.  For example, one of my SaaS ventures was Helpstream.  We had the unpleasant experience of being shut down by our VC’s shortly after the 2008 crash, but we tried to do well by our customers.  As it turned out, our architecture made it very straightforward for us to offer those folks the chance to host their own Helpstream instance and keep going rather than have to stop cold turkey.  There are still customers live on the software as a result.  I won’t go into all the details of how this was accomplished, but suffice it to say our architecture made us very nimble about being able to create multi-tenant apartment complexes that could house anywhere from 1 to a couple of thousand tenants on standard Amazon EC2 + S3 infrastructure.  Thus it was trivial for us to set up a customer as their own tenant in their own apartment house and hand them the keys.  This is not something you could say about something like, say, Salesforce.com, or many other SaaS offerings.  Building on a commodity cloud like Amazon can have its virtues.

In the perpetual on-premises license days, we had source code escrows.  In the SaaS/Cloud era, it makes sense to codify what happens in the event of a dissolution of some sort.  As the Helpstream example shows, it’s possible to do something that makes enormous sense for customers and thereby give them a greater sense of security, something that the Cloud is not often known for.

Unfortunately, things also go on in the Cloud that have nothing to do with a particular vendor, but that actually make things much worse for customers.  I present the example of Feedly and the Apple App Store.

As most of you will know, Google discontinued Google Reader, forcing those of us who need such a thing to seek alternatives.  I looked at a good half dozen during the warning period and eventually settled on Feedly.  Let me be clear that this is still not a decision I regret, but I am forced to endure a not so pleasant aspect of the way Feedly works on my iPad.  There is a problem in that Feedly is set up to seamlessly transfer you from Google Reader to Feedly.  That part is good.  What is less good is that Google changed some aspects of the API and created a little problem for the Feedly app.  Feedly works great for me on my desktop, because I can access it via web browser as a thin client.  It is dead to me on my iPad because of this problem.  Feedly mistakenly thinks it is overloaded with users, a surprisingly plausible story in the wake of Google Reader shutting down.  In fact, this is not the case.  There is simply a bug that causes the iOS Feedly app to mistakenly report this problem.

Now here is the problem:

Since iOS is a walled garden, and Feedly has to wait until Apple approves a fixed version of the app, they are stuck.  It’s been 7 days and the app still doesn’t work and a fix has not been approved.  As my headline says, the map is buried with the treasure because Apple is presenting them from fixing a very obvious problem.  Feedly has no real answer for this, and Apple isn’t telling them an ETA on approval either.  It’s hard to be impressed with either Apple or Feedly based on how all of this is rolling out.  You’d think whatever process Apple uses would be aware of how many people use Feedly (it’s millions) and could find a way to expedite an obvious fix.  Apparently the Monarchy of Cupertino cannot be bothered with such mundane details as customer happiness.

Meanwhile, I have to ask myself, “Why can’t I run the Feedly thin client in the Safari browser on iOS?”  That would be so handy right about now.  Yet, they seem to have been at pains to ensure that if you are on an iPad, you surely must use their app and are to be prevented from accessing the thin client that works so well on my desktop and that would have prevented this nuisance.

Folks, the next time you’re using your tablet and you go to some website and it offers to download an app, skip it.  That app is not going to improve your user experience enough to be worth the trouble.  You are only going to encourage them not to keep their thin client working well on your platform.  And someday, you may wish the map hadn’t been buried with the treasure the way the Feedly guys did it.  Don’t frequent the Walled Garden.  Don’t encourage it at all unless you absolutely must.

This was all tragically avoidable, and I hope Feedly will take note and pave the way for their thin client to work on iOS so the next time they don’t have to wait on Apple.  Those of you at other companies, don’t let this happen to your customers!

Posted in apple, cloud, saas, service, strategy | 3 Comments »

Big Data is a Small Market Compared to Suburban Data

Posted by Bob Warfield on February 2, 2013

BurbsBig Data is all the rage, and seem to be one of the prime targets for new entrepreneurial ventures since VC-dom started to move from Consumer Internet to Enterprise recently.  Yet, I remain skeptical about Big Data for a variety of reasons.  As I’ve noted before, it seems to be a premature optimization for most companies.  That post angered the Digerati who are quite taken with their NoSQL shiny objects, but there have been others since who reach much the same conclusion.  The truth is, Moore’s Law scales faster than most organizations can scale their creation of data.  Yes, there are some few out of millions of companies that are large enough to really need Big Data and yes, it is so fashionable right now that many who don’t need it will be talking about it and using it just so they can be part of the new new thing.  But they’re risking the problems many have had when they adopt the new new thing for fashion rather than because it solves real problems they have.

This post is not really about Big Data, other than to point out that I think it is a relatively small market in the end.  It’ll go the way of Object Oriented Databases by launching some helpful new ideas, the best of which will be adopted by the entrenched vendors before the OODB companies can reach interesting scales.  So it will be with Hadoop, NoSQL, and the rest of the Big Data Mafia.  For those who want to get a head start on the next wave, and on a wave that is destined to be much more horizontal, much larger, and of much greater appeal, I offer the notion of Suburban Data.

While I shudder at the thought of any new buzzwords, Suburban Data is what I’ve come up with when thinking about the problem of massively parallel architectures that are so loosely coupled (or perhaps not coupled at all) that they don’t need to deal with many of the hard consistency problems of Big Data.  They don’t care because what they are is architectures optimized to create a Suburb of very loosely coordinated and relatively small collections of data.  Think of Big Data’s problems as being those of the inner city where there is tremendous congestion, real estate is extremely expensive, and it makes sense to build up, not out.  Think Manhattan.  It’s very sexy and a wonderful place to visit, but a lot of us wouldn’t want to live there.  Suburban Data, on the other hand, is all about the suburbs.  Instead of building giant apartment buildings where everyone is in very close proximity, Suburban Data is about maximizing the potential of detached single family dwellings.  It’s decentralized and there is no need for excruciatingly difficult parallel algorithms to ration scarce services and enforce consistency across terabytes.

Let’s consider a few Real World application examples.

WordPress.com is a great place to start.  It consists of many instances of WordPress blogs.  Anyone who likes can get one for free.  I have several, including this Smoothspan Blog.  Most of the functionality offered by wp.com does not have to coordinate between individual blogs.  Rather, it’s all about administering a very large number of blogs that individually have very modest requirements on the power of the underlying architecture.  Yes, there are some features that are coordinated, but the vast majority of functionality, and the functionality I tend to use, is not.  If you can see the WordPress.com example, web site hosting services are another obvious example.  They just want to give out instances as cheaply as possible.  Every blog or website is its own single family home.

There are a lot of examples along these lines in the Internet world.  Any offering where the need to communicate and coordinate between different tenants is minimized is a good candidate.  Another huge area of opportunity for Suburban Data are SaaS companies of all kinds.  Unless a SaaS company is exclusively focused on extremely large customers, the requirements of an average SaaS instance in the multi-tenant architecture are modest.  What customers want is precisely the detached single family dwelling, at least that’s what they want from a User Experience perspective.  Given that SaaS is the new way of the world, and even a solo bootstrapper can create a successful SaaS offering, this is truly a huge market.  The potential here is staggering, because this is the commodity market.

Look at the major paradigm shifts that have come before and most have amounted to a very similar (metaphorically) transition.  We went from huge centralized mainframes to mini-computers.  We went from mini-computers to PC’s.  Many argue we’re in the midst of going from PC’s to Mobile.  Suburban Data is all about how to create architectures that are optimal for creating Suburbs of users.

What might such architectures look like?

First, I think it is safe to say that while existing technologies such as virtualization and the increasing number of server hardware architectures being optimized for data center use (Facebook and Google have proprietary hardware architectures for their servers) are a start, there is a lot more that’s possible and the job has hardly begun.  To be the next Oracle in the space needs a completely clean sheet design from top to bottom.  I’m not going to map the architecture out in great detail because its early days and frankly I don’t know all the details.  But, let’s Blue Sky a bit.

Imagine an architecture that puts at least 128 x86 compatible (we need a commodity instruction set for our Suburbs) cores along with all the RAM and Flash Disc storage they need onto the equivalent of a memory stick for today’s desktop PC’s.  Because power and cooling are two of the biggest challenges in modern data centers, the Core Stick will use the most miserly architectures possible–we want a lot of cores with reasonable but no extravagant clock speeds.  Think per-core power consumption suitable for Mobile Devices more than desktops.  For software, let’s imagine these cores run an OS Kernel that’s built around virtualization and the needs of Suburban Data from the ground up.  Further, there is a service layer running on top of the OS that’s also optimized for the Suburban Data world but has the basics all ready to go:  Apache Web Server and MySQL.  In short, you have 128 Amazon EC2 instances potent enough to run 90% of the web sites on the Internet.  Now let’s create backplanes that fit a typical 19″ rack set up with all the right UPS and DC power capabilities the big data centers already know how to do well.  The name of the game will be Core Density.  We get 128 on a memory stick, and let’s say 128 sticks in a 1U rack mount, so we can support 16K web instances in one of those rack mounts.

There will many valuable problems to solve with such architectures, and hence many opportunities for new players to make money.  Consider what has to be done to reinvent hierarchical storage manage for such architectures.  We’ve got a Flash local disc with each core, but it is probably relatively small.  Hence we need access to storage on a hierarchical basis so we can consume as much as we want and it seamlessly works.  Or, consider communicating with and managing the cores.  The only connections to the Core Stick should be very high speed Ethernet and power.  Perhaps we’ll want some out of band control signals for security’s sake as well.  Want to talk to one of these little gems, just fire up the browser and connect to its IP address.  BTW, we probably want full software net fabric capabilities on the stick.

It’ll take quite a while to design, build, and mature such architectures.  That’s fine, it’ll give us several more Moore cycles in which to cement the inevitability of these architectures.

You see what I mean when I say this is a whole new ballgame and a much bigger market than Big Data?  It goes much deeper and will wind up being the fabric of the Internet and Cloud of tomorrow.

Posted in business, cloud, data center, enterprise software, multicore, platforms, saas, service | 2 Comments »

Amazon: The Hidden Empire

Posted by Bob Warfield on May 13, 2011

An amazing read about Amazon and the strategy of creating a huge success on the web:

Amazon: The Hidden Empire by faberNovel

Why can’t the other Big Seattle Tech Company be remotely this smart?

Posted in amazon, business, cloud, service, strategy | Leave a Comment »

Gartner: The Cloud is Not a Contract

Posted by Bob Warfield on January 12, 2011

There is a bit of a joust on between Gartner, GigaOm, and likely others over the recent Gartner Magic Quadrant for Cloud Infrastructure.  The Internet loves a good fight!

Gartner launched their magic quadrant with some fanfare on December 22.  Immediately after the holidays, on January 4, GigaOm’s Derrick Harris threw down the gauntlet by bluntly saying, “Gartner just flat got it wrong.”  Can’t get much more black and white than that.  His reasoning is as follows:

Initially, it seems inconceivable that anybody could rank IaaS providers and not list Amazon Web Services among the leaders. Until, that is, one looks at Gartner’s ranking criteria, which is skewed against ever placing a pure cloud provider in that quadrant. Large web hosts and telcos certainly have a wider range of offerings and more enterprise-friendly service levels, but those aren’t necessarily what cloud computing is all about. Cloud IaaS is about letting users get what they need, when they need it — ideally, with a credit card. It doesn’t require requisitioning servers from the IT department, signing a contract for any predefined time period or paying for services beyond the computing resources.

I have to say, he is right.  It is obvious and absurd not to rank Amazon Web Services at least among the leaders.  If you’re going to take that step, it’s a bold one, and needs to be expressed up front with no ambiguity and leading with a willingness to have a big discussion about it.  Gartner didn’t do that either.  They just presented their typical blah, blah, blah report.  For weaknesses, which presumably got Amazon moved out of the ranks of leaders, they offer the following:

  • No managed services.
  • No collocation, dedicated nonvirtualized servers (often used for databases), or private non-Internet connectivity.
  • The weakest cloud compute SLA of any of the evaluated competing public cloud compute services.  They offer 99.95% uptimes instead of the 99.99% of many others and the penalties are capped.
  • Support and other items are unbundled.
  • Amazon’s offering is developer-centric, rather than enterprise-oriented, although it has significant traction in large enterprises. Its services are normally purchased online with a credit card; traditional corporate invoicing must be negotiated as a special request. Prospective customers who want to speak with a sales representative can fill out an online form to request contact; Amazon does have field sales and solutions engineering. Amazon will negotiate and sign contracts known as Enterprise Agreements, but customers often report that the negotiation process is frustrating.

My first reaction to reading those negatives is they make a pretty good list of criteria for differentiating an old-fashioned managed hosting data center from a real Cloud service.  Does Gartner understand what the Cloud really is, what it is about, and how to engage with it successfully? 

For her part, the lead analyst, Lydia Leong, responded the day after the GigaOm post.  Here response, predictably, is to disagree with Derrick’s quoted paragraph above, saying:

I dispute Derrick’s assertion of what cloud IaaS is about. I think the things he cites above are cool, and represent a critical shake-up in thinking about IT access, but it’s not ultimately what the whole cloud IaaS market is about.

Lemme get this straight, the Cloud IaaS market is about (since I will negate Derrick’s remarks that Lydia disagrees with):

  • Eliminating Pure Cloud vendors from serious consideration.  You must have non-Cloud offerings to play.
  • Eliminating the self-service aspect of letting users get what they need, when they need it–ideally, with a credit card.
  • Eliminating the possibility for self-service without a contract negotiation.

Newsflash for you folks at Gartner: the Cloud is Not a Contract.  It is a Service, but it is a not a legion of Warm Bodies.  It’s not about sucking up with field sales and solutions engineering (“You’re a handsom and powerful man!”).

I can understand that Lydia’s clients mention the need for elaborate contracts with detailed provisions unique to their circumstances.  When that happens, and when it is so at odds with the landscape of a fundamentally new development that respecting it will prevent you from naming legitimate leaders like Amazon as leaders, there are two ways you can proceed.  The easy thing is to cave to your clients since they’re paying the bills and concoct a scenario where the clients get what they think they want.  The hard thing is to show some leadership, earn your fees, and explain to the client, or at least to the vendors slighted, why your recommendation is right. 

Let’s put on our analyst hats, leave Gartner’s misguided analysis, and look at the issue squarely of, “How should we be looking at the issue of Contracts and the Cloud?”

As I have already said, “The Cloud is not about contacts.”  What it is about is commoditization through scale and through sharing of resources which leads to what we call elasticity.  That’s the first tier.  The second tier is that it is about the automation of operations through API’s, not feet in the datacenter cages.  All the rest is hype.  It is this unique combination of: scale, sharing of resources, elasticity, and the automation of ops through API’s that makes the Cloud a new paradigm.  That’s how the Cloud delivers savings.  It’s not that hard to understand once you look at it in those terms.

Now what is the impact of contracts on all that?  First, a contract cannot make an ordinary datacenter into a Cloud no matter who owns it unless it addresses those issues.  Clouds are Clouds because they have those qualities and not because some contract or marketer has labeled them as such.  Second, arbitrary contracts have the power to turn Clouds into ordinary hosted data centers: 

A contract can destroy a Cloud’s essential “Cloudness”!

I wanted to put that in bold and set apart because it is important.  When you, Mr handsom and powerful IT leader, are negotiating hard with your Cloud vendor, you have the power to destroy what it was you thought you were buying.  Your biggest risk is not that they will say, “No”, it is that they might say, “Yes” if you wave a big enough check.  Those who have made the mistake of getting exactly what they want on a big Enterprise Software implementation that wound up going very far wrong because what you wanted was not what the software really did will know what I am talking about.

How do we avoid having a contract destroy “Cloudness?”  This is simple:

Never sign a contract with your Cloud provider that interferes with their ability to commoditize through scale, sharing, and automation of operations.

If they are smart, the Cloud provider will never let it get to that stage.  This is one reason Amazon won’t negotiate much in a contract.  Negotiating fees for services offered is fine.  That does not interfere with the critical “Cloudness” qualities (I am steadfastly refusing the term Cloudiness so as not to deprecate my central thesis!).  BTW, there are very close corollaries for SaaS, which is why they are also much more limited relative to On-prem vendors in what they can negotiate and why they try to hew to the side that Amazon has.  This stuff didn’t get invented for Cloud or out of disdain for customers, there are real economic impacts.

Let’s try a simple example.  Your firm wants to secure Cloud resources from a provider who has some sort of maintenance outage provision for the infrastructure.  It’s a made up example for Cloud (mostly), but is on point for SaaS and easy to understand, so let me continue.  Your firm finds that maintenance window to be unacceptable because you have aligned your own maintenance windows with those of another vendor.  If you accept the Cloud vendor’s window, you will now have two windows to present your constituents and that is unacceptable.  So you want to negotiate a change in the contracts.  Sounds very innocent, doesn’t it?  I’ve been through this exact scenario at SaaS companies where customers wanted this to be done for the same legitimate and logical reasons. 

But consider it from the Cloud provider’s point of view.  If they have a special maintenance window for you, they have to take a portion of their infrastructure and change how it works.  Unless they have other customers that want exactly the same terms, they will have to dedicate that infrastructure to your use.  Can you see the problem?  We have now eliminated the ability to scale that infrastructure through sharing and scale.  In addition, depending on how their automated operations function, it may or may not be applicable to your specialized resources.  It isn’t just a matter of changing a schedule for some ops people–the automated ops is either set up to deal with this kind of flexibility or it isn’t.

That was an example for a maintenance window, but any deviation you negotiate in a contract that impacts scale, sharing, or automated ops can have the same impact.  Here are more examples:

-  You want to change the disk quotas or cpus on your instances.

-  Your SLA requirements damage some baked-in aspect of the providers automated ops infrastructure.  This is easy to have happen.  You insist on network bandwidth that requires a different switching fabric or whatever.

-  You want to limit how and when machines can be patched by the provider.

-  You want to put your machines on private subnets as Gartner suggests should be possible and has many who think the idea of a Private Cloud is Marketing BS decry.

That list can be a mile long.  When you get done ruling out all the things you really can’t negotiate without un-Clouding your Cloud, you’re going to see that relatively simple contracts such as you can already negotiate with Amazon are all that’s left.  Congratulations!  Unlike Gartner, you now understand what a Cloud is and how to take advantage of it. 

And remember, the next time you’re negotiating a Cloud contract, be careful what you wish for–you just might get it.

Postscript

Lydia Leong, one of the Gartner analysts who did the Magic Quadrant discussed here, has responded.  I read her response as boiling down to agreement with a lot of what I’ve said, excusing the disagreements on the fact that the Magic Quadrant concerned both Cloud and Web Hosting and calling attention to Gartner’s plan to do a mid-year pure-Cloud Magic Quadrant.   The latter is a good idea, and one would think had to be at least partially motivated by more negative feedback than just my own about this current Magic Quadrant.  Try to compare Cloud vendors against Web Hosting vendors on the same quadrant is an apples-to-oranges exercise at best and misleading at worst.

In any event, I thank Lydia for her gracious response and look forward to seeing the Cloud Pure Play Magic Quadrant.  That’s where the meat will be!

Posted in business, cloud, data center, saas, service, strategy | 3 Comments »

Software Has Marginal Cost

Posted by Bob Warfield on January 9, 2011

marginal costEvery now and again I see the old chestnut trotted out that Software has no marginal cost.  It’s used for all sorts of reasons.  The gut feeling that it is true is probably at the heart of most people’s justification for why piracy is okay, for example, not that I’m saying most people think it’s okay.  This time around, I was surprised to see it brought up by fellow Enterprise Irregular Basab Pradhan.  Basab has a long history in the world of software, and so should know better.  Nevertheless, in talking about whether app stores are worth the 30% or more they take of the revenue, he remarks:

Is the 30% cut of revenues too much? It depends on how much you expect your revenues to go up by. After all, software has no marginal costs. Every dollar of incremental revenue is a dollar of incremental profit (before taxes).

There is, of course, software that behaves as Basab says, but it has certain distinctive qualities:

-  It is never updated, so there is no marginal cost to keep an engineering team running.  This of course is the problem with any big professional services investment–you’d better hope you don’t need to update whatever they built.  But it’s really a problem for all software that is not absolutely the most casual stuff you rarely use and then throw away.  Someone has to keep it secure, fix bugs, and hopefully continue to innovate.  One of Basab’s examples in his post is Evernote.  As an Evernote user, it isn’t the kind of software I would want to see go without an engineering team.  In general, if people didn’t care about this, they wouldn’t pay the ridiculous maintenance fees most big software vendors charge.

-  It is not SaaS.  Clearly SaaS as a service has some marginal costs.  While it is true that an app downloaded from an app store may not be SaaS, it is not true that it must not be SaaS.  My view is that all software benefits from having some SaaS component or other.  Even if all that component does is keep your software up to date, there will be marginal costs to keep that SaaS infrastructure running.  Of course if the software is never updated, this may not be an issue.

-  It is unsupported.  Support is one of the dirty little marginal costs of all software.  There is a reason it appears where it does on the financial statements of many companies, coming out as an immediate hit on the gross margin.  Ditto the remarks on ridiculous maintenance fees.

There are bound to be other marginal costs I can drudge up, but the point is made.  The question to ask yourself if you come across some software with no marginal cost is whether you want any part of it.  No support, no updates, no connection to any online service.  Some software is so far off my critical path, I figure, why not?  Most of it isn’t.  Have you been involved with much software that has been “sunset”, “coasted”, or any of a number of other euphemisms for abandoned?  It’s no fun unless said software is extremely simple and does what you need of it immediately.  If it doesn’t, don’t keep fiddling, go find yourself some real software.  If we had more people thinking of how to manage software’s marginal costs at a profit, we might have longer lived software companies and fewer examples of customer abuse like Dim Dim’s.

A more interesting thought on whether the app stores are worth it is to look at how much revenue these days is coming via in-app purchases, which are starting to overtake app store purchases.  Of course you’ll probably need some marginal software costs to be able to deliver anything of value via in-app purchase, but now you’ve got a better financial justification for it.

Basab Pradhan has responded

As you can see from the linkback above, Basab has responded.  He brings some new chestnuts to consider:

Engineering costs are fixed costs. They have no relationship to the units of software sold. Sure, if you sell more units you have more money to spend on engineering, but that is conflating cause with effect.

Basab, if your growing customer base makes new demands on the software, whether from a desire to see bugs fixed, or progress, and you accept those challenges to keep things growing, there is no conflation, it is a cause and there is an effect that has costs.  Simple example is deciding to do translations for new markets.  Oh, but wait, we have to have localizable software first.  Better hire some more engineers.  Or better take the same engineers and make them work on that instead of a new product.  Wait, you want interaction between users?  You want in-app sales?  Wow, how are we going to make that scale?  Oh no, users are reporting a bug on that new release of iOS.  Sales have stopped entirely until we get it fixed.  That list goes on and on.  I’ve run enough engineering organizations at companies large and small to tell you that is a fact.  Whether the bean counters choose to classify it as a marginal cost is irrelevant at best and distracting from the main business at hand at worst.  Organizations that think they can ignore it and reassign the engineers to the next project are called professional services organizations, not software companies.

…after a certain user base has been achieved, incremental (support, bw) costs are not material, in my opinion.

Basab’s argument is that by throwing all the support into forums and relying on superusers to take care of all but a few that are then handled by remaining support, we needn’t view support as a material.  If only it were so, Basab, if only it were so.  You probably are not aware, but my last gig was running a company that built support solutions exactly as you describe.  Our product derived real metrics on the ROI and effectiveness of Social CRM for customer service, and these results were covered by Forrester, Gardner, and others.  There is Good News and Bad News.  Under ideal conditions (and most do not achieve these for a variety of reasons), customer service costs can be reduced to about 1/3 of a pure ticketing and knowledge base system.  There are complex dynamics and the idea that superusers will do all the work is one of the flawed assumptions many make that leads to disappointing results.  In any event, even if you get to 1/3, you’re still going to have support costs that are quite material.  BTW, many do not restrict themselves to forums either.  Electronic Arts, for example, still does Trouble Tickets direct to support.  Others will decide they can get away with forums since they’re cheap, and that’s the name of the game for app stores, so fair game.  But lest someone reading all this think they can just toss their users into a forum, forget about Customer Service, and expect good results, beware.  That’s not a winning formula for customer satisfaction.

Is this particular cost (SaaS costs relating to a server-side component, bw) material compared to the revenue from the next user? I doubt that Angry Bird or Omnigraffle worry about it. Evernote perhaps does, but how many apps do you know that users regularly use to scan and upload documents to? 

How many apps result in uploads?  How many apps result in interaction of one kind or another between users?  How many stories have you read lately about scaling problems of one kind or another at small companies giving away their software for free?  Enough said.

I was pretty clear in my original article.  There is software that fits Pradhan’s criteria of low to no (certainly not-material) marginal cost per user.  There is a lot of it on app stores.  His arguments hew to the definition I gave of that kind of software which is software that you don’t bother updating much, that has poor (throw ‘em into a forum and let them answer each other’s questions) customer service, and it has little or no SaaS component (no uploading data, no interaction with other users, and I already mentioned having to deal with in app purchases as a valuable SaaS component).  I don’t see much in the rebuttal that changes those conclusions, though it was a decent attempt at response.  The point of the post is that its silly to say Software (capital “S” by intention) has no marginal cost.  Of course a whole lot of software has marginal cost!  Since we’re now just arguing about degree, my work here is done.

Posted in business, cloud, service, venture | 7 Comments »

Dim Dim: The Risk of Being a Salesforce Customer

Posted by Bob Warfield on January 7, 2011

unhappy customersMy title is a bit of a play on ReadWriteWeb’s title about the Risk of a Free Service, but I raise the issue in all seriousness because I think we should be looking not at the seller (hey, at this price, this was not exactly a sale from strength) but at the buyer.  Dennis Howlett, in writing about the transaction, is doing a little bit of looking at the buyer, but I want to go further.

The way a company handles the customers of an acquisition is an indication of how they may someday feel about their own customers.  When you buy the company, you bought the customers too.  Sure, it’s all fine and well to argue that you bought the technology and not the customers and it’s not your fault that the customers don’t fit in with your plans and so won’t be treated well.  But when you hear that rationale, ask yourself,  “What happens if I’m a customer of such an organization and suddenly I don’t fit in with their plans either?”  There’s not really a difference, particularly not if you are a just one customer among many of a large company.  If Salesforce was going to do what I’d want it to do if I were a Dim Dim customer, they’d be grandfathering me in and extending me full benefits of being a Salesforce customer.  They’d be welcoming me to the family instead of disinheriting me.  I’d be 10x more likely to want to buy something from them if they did, and I’d be 10x more likely to sing their praises and those of Dim Dim going forward regardless.   Unless I miss my guess, Salesforce is going to be doing a lot more acquisitions, so take note of the tone they’re setting.

There are really two kinds of successful businesses out there:  There is the business that would do anything for its customers, and then there is the business run by the numbers that is without soul or pity for their customers.  I won’t be disingenuous by claiming the soulless kind doesn’t work, neither will I argue that one is better.  We have big and successful examples of companies that do as they please with their customers–Oracle and Microsoft have both been accused of such more than once so it should be no secret.  We also have examples of companies who have put their customers above all else–I like companies like Zappo’s and Nordstrom or maybe Amazon and Apple (in a curious way, they do care, they just think they know best).  Some of Hurd’s problem at HP may have been putting a numbers guy in charge of a culture driven more by ideals.  We will see whether Apotheker is a better fit.

When the pure numbers companies make an acquisition, it’s pretty clear how things will work.  Fellow Enterprise Irregular Naomi Bloom has a wonderful post out about fairy tales in the land of HR software that describes some of the goings on you should expect:

- We (the acquirer) will continue to support all product lines fully:  Of course we really won’t, we can’t afford to, but we don’t want to tell you that too soon.

We (the acquirer) are delighted with our new colleagues and expect to retain all of them:  Even if we do retain them, and we won’t, they will be disempowered and will be bent to our culture and management.  Expect many to leave as soon as the handcuffs are off.

- Our customers can expect to see only improvements in their support, product roadmaps, and overall happiness as a result of this event:  Well, maybe, if it’s a technology acquisition.  If it is a market share acquisition, we are reducing the competitiveness of the market so that we may extract more profit while delivering less.

To those Fairy Tales, meaning if you hear them you should see them as red flags, I will add that if you see one of your vendors acquire a company and fail to welcome its customers with open arms to the family the way you would have liked to have been treated, that’s a red flag too.

There’s another thread I want to pick up on before I leave this one.  When we look at the two types of companies, ironically, making the customer King often leads to excellent profitability and shareholder value, but focusing on short-term numbers tweaking does not.  One of the disappointing things for me is how often products that were once great and companies can fade into obscurity.  I asked one of my favorite mentors one time what he was proudest of about the company where we had worked together.  His answer was very telling–his biggest accomplishment, he felt, was in creating a great culture.  This was a company that cared foremost for customers, and that culture resulted in an employee base that was very resilient to adverse conditions and very talented.  Later, the company got numbers focused and it has since lost that culture and most of those people.  Culture is the currency for a company that cares about its customers, but what is the currency that makes a big company out of one that cares for numbers?  Looking around for that answer I can only conclude that it is monopoly, customer lock-in, and the inertia that comes to all things big.  These are the only reasons for customers to put up with a company that cares more about its profits than about the customer.

Last point:  I read with interest Chris Sellend’s (lots of us Enterprise Irregulars with something to say!) prediction of a coming Social-Media-in-Marketing backlash.  Riffing on @pgillin, he calls for a Social Marketing Hangover.  I think folks calling for this backlash are right, but perhaps not in the way some of them are thinking.  Think about the two kinds of companies then think about what Social is.  The answer is obvious (to me at least):  companies that have a culture that cares about customers can be wildly successful with Social while customers with cultures that only care about the numbers are doomed to fail.  There is some question in my mind about whether they should even try, though there is a sentiment that feels opening themselves up to customers will let the customers rehabilitate them. 

The real tragedy is it will never occur to the number crunchers what is wrong and the pundits will watch the train wrecks and simply conclude Social was more hype than reality.  The customer-centric crowd won’t notice anything big either except that they can suddenly do what they do best a whole lot easier.

Posted in business, customer service, enterprise software, saas, service, venture | 2 Comments »

Single Tenant, Multitenant, Private and Public Clouds: Oh My!

Posted by Bob Warfield on August 27, 2010

My head is starting to hurt with all the back and forth among my Enterprise Irregulars buddies about the relationships between the complex concepts of Multitenancy, Private, and Public Clouds.  A set of disjoint conversations and posts came together like the whirlpool in the bottom of a tub when it drains.  I was busy with other things and didn’t get a chance to really respond until I was well and truly sucked into the vortex.  Apologies for the long post, but so many wonderful cans of worms finally got opened that I just have to try to deal with a few of them.  That’s why I love these Irregulars!

To start, let me rehash some of the many memes that had me preparing to respond:

Josh Greenbaum’s assertion that Multitenancy is a Vendor, not a Customer Issue.  This post includes some choice observations like:

While the benefits that multi-tenancy can provide are manifold for the vendor, these rationales don’t hold water on the user side.

That is not to say that customers can’t benefit from multi-tenancy. They can, but the effects of multi-tenancy for users are side-benefits, subordinate to the vendors’ benefits. This means, IMO, that a customer that looks at multi-tenancy as a key criteria for acquiring a new piece of functionality is basing their decision on factors that are not directly relevant to their TCO, all other factors being equal.

and:

Multi-tenancy promises to age gracelessly as this market matures.

Not to mention:

Most of the main benefits of multi-tenancy – every customer is on the same version and is updated simultaneously, in particular – are vendor benefits that don’t intrinsically benefit customers directly.

The implication being that someone somewhere will provide an alternate technology very soon that works just as good or better than multitenancy.  Wow.  Lots to disagree with there.  My ears are still ringing from the sound of the steel gauntlet that was thrown down.

-  Phil Wainewright took a little of the edge of my ire with his response post to Josh, “Single Tenancy, the DEC Rainbow of SaaS.”  Basically, Phil says that any would-be SaaS vendor trying to create an offering without multitenancy is doomed as the DEC Rainbow was.  They have some that sort of walks and quacks like a SaaS offering but that can’t really deliver the goods.

-  Well of course Josh had to respond with a post that ends with:

I think the pricing and services pressure of the multi-tenant vendors will force single-tenant vendors to make their offerings as compatible as possible. But as long as they are compatible with the promises of multi-tenancy, they don’t need to actually be multi-tenant to compete in the market.

That’s kind of like saying, “I’m right so long as nothing happens to make me wrong.”  Where are the facts that show this counter case is anything beyond imagination?  Who has built a SaaS application that does not include multitenancy but that delivers all the benefits?

Meanwhile back at the ranch (we EI’s need a colorful name for our private community where the feathers really start to fly as we chew the bones of some good debates), still more fascinating points and counterpoints were being made as the topic of public vs private clouds came up (paraphrasing):

-  Is there any value in private clouds?

-  Do public clouds result in less lock-in than private clouds?

-  Are private clouds and single tenant (sic) SaaS apps just Old School vendors attempts to hang on while the New Era dawns?  Attempts that will ultimately prove terribly flawed?

-  Can the economics of private clouds ever compete with public?

-  BTW, eBay now uses Amazon for “burst” loads and purchases servers for a few hours at a time on their peak periods.  Cool!

-  Companies like Eucalyptus and Nimbula are trying to make Private Clouds that are completely fungible with Public Clouds.  If you  in private cloud frameworks like these means you have
to believe companies are going to be running / owning their own servers for a long time to come even if the public cloud guys take over a number of compute workloads.  The Nimbula guys built EC2 and they’re no dummies, so if they believe in this, there must be something to it.

-  There are two kinds of clouds – real and virtual.  Real clouds are multi-tenant. Virtual clouds are not. Virtualization is an amazing technology but it can’t compete with bottoms up multi-tenant platforms and apps.

Stop!  Let me off this merry go-round and let’s talk.

What It Is and Why Multitenancy Matters

Sorry Josh, but Multitenancy isn’t marketing like Intel Inside (BTW, do you notice Intel wound up everywhere anyway?  That wasn’t marketing either), and it matters to more than just vendors.  Why?

Push aside all of the partisan definitions of multitenancy (all your customers go in the same table or not).   Let’s look at the fundamental difference between virtualization and multitenancy, since these two seem to be fighting it out.

Virtualization takes multiple copies of your entire software stack and lets them coexist on the same machine.  Whereas before you had one OS, one DB, and one copy of your app, now you may have 10 of each.  Each of the 10 may be a different version entirely.  Each may be a different customer entirely, as they share a machine.  For each of them, life is just like they had their own dedicated server.  Cool.  No wonder VMWare is so successful.  That’s a handy thing to do.

Multitenancy is a little different.  Instead of 10 copies of the OS, 10 copies of the DB, and 10 copies of the app, it has 1 OS, 1 DB, and 1 app on the server.  But, through judicious modifications to the app, it allows those 10 customers to all peacefully coexist within the app just as though they had it entirely to themselves.

Can you see the pros and cons of each?  Let’s start with cost.  Every SaaS vendor that has multitenancy crows about this, because its true.  Don’t believe me?  Plug in your VM software, go install Oracle 10 times across 10 different virtual machines.  Now add up how much disk space that uses, how much RAM it uses when all 10 are running, and so on.  This is before you’ve put a single byte of information into Oracle or even started up an app.  Compare that to having installed 1 copy of Oracle on a machine, but not putting any data into it.  Dang!  That VM has used up a heck of a lot of resources before I even get started!

If you don’t think that the overhead of 10 copies of the stack has an impact on TCO, you either have in mind a very interesting application + customer combination (some do exist, and I have written about them), or you just don’t understand.  10x the hardware to handle the “before you put in data” requirements are not cheap.  Whatever overhead is involved in making that more cumbersome to automate is not cheap.  Heck, 10x more Oracle licenses is very not cheap.  I know SaaS companies who complain their single biggest ops cost is their Oracle licenses. 

However, if all works well, that’s a fixed cost to have all those copies, and you can start adding data by customers to each virtual Oracle, and things will be okay from that point on.  But, take my word for it, there is no free lunch.  The VM world will be slower and less nimble to share resources between the different Virtual Machines than a Multitenant App can be.  The reason is that by the time it knows it even needs to share, it is too late.  Shifting things around to take resource from one VM and give it to another takes time.  By contrast, the Multitenant App knows what is going on inside the App because it is the App.  It can even anticipate needs (e.g. that customer is in UK and they’re going to wake up x hours before my customers in the US, so I will put them on the same machine because they mostly use the machine at different times).

So, no, there is not some magic technology that will make multitenant obsolete.  There may be some new marketing label on some technology that makes multitenancy automatic and implicit, but if it does what I describe, it is multitenant.  It will age gracefully for a long time to come despite the indignities that petty competition and marketing labels will bring to bear on it.

What’s the Relationship of Clouds and Multitenancy?

Must Real Clouds be Multitenant?

Sorry, but Real Clouds are not Multitenant because they’re based on Virtualization not Multitenancy in any sense such as I just defined.  In fact, EC2 doesn’t share a core with multiple virtual machines because it can’t.  If one of the VM’s started sucking up all the cycles, the other would suffer terrible performance and the hypervisors don’t really have a way to deal with that.  Imagine having to shut down one of the virtual machines and move it onto other hardware to load balance.  That’s not a simple or fast operation.  Multi-tasking operating systems expect a context switch to be as fast as possible, and that’s what we’re talking about.  That’s part of what I mean by the VM solution being less nimble.  So instead, cores get allocated to a particular VM.  That doesn’t mean a server can’t have multiple tenants, just that at the granularity of a core, things have to be kept clean and not dynamically moved around. 

Note to rocket scientists and entrepreneurs out there–if you could create a new hardware architecture that was really fast at the Virtual Machine load balancing, you would have a winner.  So far, there is no good hardware architecture to facilitate a tenant swap inside a core at a seamless enough granularity to allow the sharing.  In the Multicore Era, this would be the Killer Architecture for Cloud Computing.  If you get all the right patents, you’ll be rich and Intel will be sad.  OTOH, if Intel and VMWare got their heads together and figured it out, it would be like ole Jack Burton said, “You can go off and rule the universe from beyond the grave.”

But, it isn’t quite so black and white.  While EC2 is not multitenant at the core level, it sort of is at the server level as we discussed.  And, services like S3 are multitenant through and through.  Should we cut them some slack?  In a word, “No.”  Even though an awful lot of the overall stack cost (network, cpu, and storage) is pretty well multitenant, I still wind up installing those 10 copies of Oracle and I still have the same economic disadvantage as the VM scenario.  Multitenancy is an Application characteristic, or at the very least, a deep platform characteristic.  If I build my app on Force.com, it is automatically multitenant.  If I build it on Amazon Web Services, it is not automatic.

But isn’t there Any Multitenant-like Advantage to the Cloud?  And how do Public and Private Compare?

Yes, there are tons of benefits to the Cloud, and through an understanding and definition of them, we will tease out the relationship of Public and Private Clouds.  Let me explain…

There are two primary advantages to the Cloud:  it is a Software Service and it is Elastic.  If you don’t have those advantages, you don’t have a Cloud.  Let’s drill down.

The Cloud is a Software Service, first and foremost.  I can spin up and control a server entirely through a set of API’s.  I never have to go into a Data Center cage.  I never have to ask someone at the Data Center to go into the Cage (though that would be a Service, just not a Software Service, an important distinction).  This is powerful for basically the same reasons that SaaS is powerful versus doing it yourself with On-prem software.  Think Cloud = SaaS and Data Center = On Prem and extrapolate and you’ll have it. 

Since Cloud is a standardized service, we expect all the same benefits as SaaS:

- They know their service better than I do since it is their whole business.  So I should expect they will run it better and more efficiently.

- Upgrades to that service are transparent and painless (try that on your own data center, buddy!).

- When one customer has a problem, the Service knows and often fixes it before the others even know it exists.  Yes Josh, there is value in SaaS running everyone on the same release.  I surveyed Tech Support managers one time and asked them one simple question:  How many open problems in your trouble ticketing system are fixed in the current release?  The answers were astounding–40 to 80%.  Imagine a world where your customers see 40 to 80% fewer problems.  It’s a good thing!

- That service has economic buying power that you don’t have because it is aggregated across many customers.  They can get better deals on their hardware and order so much of it that the world will build it precisely to their specs.  They can get stuff you can’t, and they can invest in R&D you can’t.  Again, because it is aggregated across many customers.  A Startup running in the Amazon Cloud can have multipe redundant data centers on multiple continents.  Most SaaS companies don’t get to building multiple data centers until they are way past having gone public. 

-  Because it is a Software Service, you can invest your Ops time in automation, rather than in crawling around Data Center cages.  You don’t need to hire anyone who knows how to hot swap a disk or take a backup.  You need peeps who know how to write automation scripts.  Those scripts are a leveragable asset that will permanently lower your costs in a dramatic way.  You have reallocated your costs from basic Data Center grubbing around (where does this patch cable go, Bruce?), an expense, to actually building an asset.

The list goes on.

The second benefit is Elasticity.  It’s another form of aggregation benefit.  They have spare capacity because everyone doesn’t use all the hardware all the time.  Whatever % isn’t utilized, it is a large amount of hardware, because it is aggregated.  It’s more than you can afford to have sitting around idle in your own data center.  Because of that, they don’t have to sell it to you in perpetuity.  You can rent it as you need it, just like eBay does for bursting.  There are tons of new operational strategies that are suddenly available to you by taking advantage of Elasticity.

Let me give you just one.  For SaaS companies, it is really easy to do Beta Tests.  You don’t have to buy 2x the hardware in perpetuity.  You just need to rent it for the duration of the Beta Test and every single customer can access their instance with their data to their heart’s content.  Trust me, they will like that.

What about Public Versus Private Clouds?

Hang on, we’re almost there, and it seems like it has been a worthwhile journey.

Start with, “What’s a Private Cloud?”  Let’s take all the technology of a Public Cloud (heck, the Nimbulla guys built EC2, so they know how to do this), and create a Private Cloud.  The Private Cloud is one restricted to a single customer.  It’d be kind of like taking a copy of Salesforce.com’s software, and installing it at Citibank for their private use.  Multitenant with only one tenant.  Do you hear the sound of one hand clapping yet?  Yep, it hurts my head too, just thinking about it.  But we must.

Pawing through the various advantages we’ve discussed for the Cloud, there are still some that accrue to a Cloud of One Customer:

-  It is still a Software Service that we can control via API’s, so we can invest in Ops Automation.  In a sense, you can spin up a new Virtual Data Center (I like that word better than Private Cloud, because it’s closer to the truth) on 10 minutes notice.  No waiting for servers to be shipped.  No uncrating and testing.  No shoving into racks and connecting cables.  Push a button, get a Data Center.

-  You get the buying power advantages of the Cloud Vendor if they supply your Private Cloud, though not if you buy software and build  your Private Cloud.  Hmmm, wonder what terminology is needed to make that distinction?  Forrester says it’s either a Private Cloud (company owns their own Cloud) or a Hosted Virtual Private Cloud.  Cumbersome.

But, and this is a huge one, the granularity is huge, and there is way less Elasticity.  Sure, you can spin up a Data Center, but depending on its size, it’s a much bigger on/off switch.  You likely will have to commit to buy more capacity for a longer time at a bigger price in order for the Cloud Provider to recoup giving you so much more control.  They have to clear other customers away from a larger security zone before you can occupy it, instead of letting your VM’s commingle with other VM’s on the same box.  You may lose the more multitenant-like advantages of the storage cluster and the network infrastructure (remember, only EC2 was stuck being pure virtual). 

What Does it All Mean, and What Should My Company Do?

Did you see Forrester’s conclusion that most companies are not yet ready to embrace the Cloud and won’t be for a long time?

I love the way Big Organizations think about things (not!).  Since their goal is preservation of wealth and status, it’s all about risk mitigation whether that is risk to the org or to the individual career.  A common strategy is to take some revolutionary thing (like SaaS, Multitenancy, or the Cloud), and break it down into costs and benefits.  Further, there needs to be a phased modular approach that over time, captures all the benefits with as little cost as possible.  And each phase has to have a defined completion so we can stop, evaluate whether we succeeded, celebrate the success, punish those who didn’t play the politics well enough, check in with stakeholders, and sing that Big Company Round of Kumbaya.  Yay!

In this case, we have a 5 year plan for CIO’s.  Do you remember anything else, maybe from the Cold War, that used to work on 5 year plans?  Never mind.

It asserts that before you are ready for the Cloud, you have to cross some of those modular hurdles:

A company will need a standardized operating procedure, fully-automated deployment and management (to avoid human error) and self-service access for developers. It will also need each of its business divisions – finance, HR, engineering, etc – to be sharing the same infrastructure.  In fact, there are four evolutionary stages that it takes to get there, starting with an acclimation stage where users are getting used to and comfortable with online apps, working to convince leaders of the various business divisions to be guinea pigs. Beyond that, there’s the rollout itself and then the optimization to fine-tune it.

Holy CYA, Batman!  Do you think eBay spent 5 years figuring out whether it could benefit from bursting to the Cloud before it just did it?

There’s a part of me that says if your IT org is so behind the times it needs 5 years just to understand it all, then you should quit doing anything on-premise and get it all into the hands of SaaS vendors.  They’re already so far beyond you that they must have a huge advantage.  There is a another part that says, “Gee guys, you don’t have to be able to build an automobile factory as good as Toyota to be able to drive a car.”

But then sanity and Political Correctness prevail, I come back down to Earth, and I realize we are ready to summarize.  There are 4 levels of Cloud Maturity (Hey, I know the Big Co IT Guys are feeling more comfortable already, they can deal with a Capability and Maturity Model, right?):

Level 1:  Dabbling.  You are using some Virtualization or Cloud technology a little bit at your org in order to learn.  You now know what a Machine Image is, and you have at least seen a server that can run them and swapped a few in and out so that you experience the pleasures of doing amazing things without crawling around the Data Center Cage.

Level 2:  Private Cloud.  You were impressed enough by Level 1 that you want the benefits of Cloud Technology for as much of your operation as you can as fast as you can get it.  But, you are not yet ready to relinquish much of any control.  For Early Level 2, you may very well insist on a Private Cloud you own entirely.  Later stage Level 2 and you will seek a Hosted Virtual Private Cloud.

Level 3:  Public Cloud.  This has been cool, but you are ready to embrace Elasticity.  You tripped into it with a little bit of Bursting like eBay, but you are gradually realizing that the latency between your Data Center and the Cloud is really painful.  To fix that, you went to a Hosted Virtual Private Cloud.  Now that your data is in that Cloud and Bursting works well, you are realizing that the data is already stepping outside your Private Cloud pretty often anyway.  And you’ve had to come to terms with it.  So why not go the rest of the way and pick up some Elasticity?

Level 4:  SaaS Multitenant.  Eventually, you conclude that you’re still micromanaging your software too much and it isn’t adding any value unique to your organization.  Plus, most of the software you can buy and run in your Public Cloud world is pretty darned antiquated anyway.  It hasn’t been rearchitected since the late 80’s and early 90’s.  Not really.  What would an app look like if it was built from the ground up to live in the Cloud, to connect Customers the way the Internet has been going, to be Social, to do all the rest?  Welcome to SaaS Multitenant.  Now you can finally get completely out of Software Operations and start delivering value.

BTW, you don’t have to take the levels one at a time.  It will cost you a lot more and be a lot more painful if you do.  That’s my problem with the Forrester analysis.  Pick the level that is as far along as you can possibly stomach, add one to that, and go.  Ironically, not only is it cheaper to go directly to the end game, but each level is cheaper for you on a wide scale usage basis all by itself.  In other words, it’s cheaper for you to do Public Cloud than Private Cloud.  And it’s WAY cheaper to go Public Cloud than to try Private Cloud for a time and then go Public Cloud.  Switching to a SaaS Multitenant app is cheaper still.

Welcome to crazy world of learning how to work and play well together when efficiently sharing your computing resources with friends and strangers!

Posted in amazon, cloud, data center, ec2, enterprise software, grid, multicore, platforms, saas, service | 14 Comments »

 
Follow

Get every new post delivered to your Inbox.

Join 323 other followers

%d bloggers like this: