The Disastrous Consequences of PaaS Provider Lock-in: Why Open PaaS Makes Sense

Dec 21, 2011 by

Lock-in is a problem that is as old as the software industry. In fact, there is arguably no way to avoid it entirely. If I choose a programming language, application server, or RDBMS, I would end up writing apps that basically couldn’t run atop of anything but that vendor’s (or community’s, in the case of open source) platform technology. Practically speaking, one would make a conscious choice to use that platform, and know that lock-in is part of the game. I could spend time evaluating the tech, and assuming I did a decent amount of diligence, I would get enough comfort to move forward with it because the perceived benefits outweigh the lock-in risks. The reason I could make this judgment call is that outside of relatively infrequent releases, the evaluation I did today is likely to be valid tomorrow because the underlying assumptions do not change that much over time. In fact, I would have little reason to believe that on a new release, the vendor would drastically changing the platform in a way that was severely out of whack with historical context, and I could even expect pricing to stay in a somewhat reasonable margin of what I’ve paid in the past. This “traditional” form of lock-in was very static in nature because of how fixed the underlying assumptions remained over time, and the ongoing contextual validity one would have with respect to the original decision to be locked in vs. the current state of the platform.

Unfortunately, the negative potential of lock-in has increased in severity due to cloud, and more specifically, due to PaaS. Lock-in risk in PaaS is defined as the sum of two components: a static lock-in risk that is the same in nature (as described earlier) as the platforms of prior computing paradigms and dynamic lock-in risk that is dependent on a set of constantly changing assumptions. When one decides to build apps on a PaaS, they should be evaluating two things:

  1. How good is the ‘P’ part of PaaS – the platform itself? This is an evaluation of the actual runtime, APIs, frameworks, management capabilities, and engineering value I can extract when I write code targeting the platform. Additionally, how proprietary is all of this to the PaaS provider (i.e. how severe is the lock-in requirement to get access to this value? Is it just APIs, runtime behavior, etc. or a new, proprietary and non-standard language?)
  2. How good is the ‘S’ part of PaaS – that is, the service. This is an evaluation of the stability, cost, performance, and quality of the hosting capabilities of the PaaS.

Evaluating P is relatively easy because you can experiment with it and get a feel for the value and whether you are willing to trade that value for some lock-in. Additionally, P lock-in is much more static in nature which means that you likely don’t need to worry about significant changes in expectations. The S is scary. Hosting quality, service levels, performance, and price could be one thing today, and something very different tomorrow. You might deploy to a PaaS and say “Wow, things are running so smooth and fast, and the price is just right,” only to have the rug pulled out from under you without notice, or worse. If the P is high/non-standard lock-in and the S is limited or no choice, you’re screwed.

Why does this happen? The short of it is that if a PaaS provider is the exclusive vendor of both P and S, any lock-in to P translates directly into lock-in at S. That is my code can only run where my PaaS vendor tells me it can run. For most PaaS vendors, this means that you can run it on the service provided by – wait for it – the PaaS vendor alone! This is some really dangerous stuff and a tremendous amount of business risk. Having mission critical apps coupled to a hosting layer that needs to prove itself each minute of each day and has a very dynamic nature both in terms of quality and price is not good. How do you protect against this? Some of us (Apprenda, CloudFoundry, Cumulogic, among others) have decided that the P part of PaaS is the high value layer, and that S should be commodity and flexible, and frankly, irrelevant so long as it delivers on basic promises. This ‘Open PaaS’ model is one where rather than having P coupled to a single S, you might have dozens or even hundreds of services that offer the platform, essentially giving the developer choice of where to deploy apps while getting the full value of the platform; a “no lock-in” hosting model. This portable PaaS form factor is here to stay. Not only can one deploy to any service provider that is offering a (hopefully) differentiated instance of that particular PaaS, but the PaaS software is likely downloadable so that you can even download the PaaS software and run it on your laptop. This decoupling of the P from the S is what can bring lock-in down from the clouds (cheesy pun intended), and back to some sense of normalcy. Sure, you still need to commit to the PaaS and adopt its APIs and will grow dependent on its runtime capabilities, but as a customer of ours put it: “I’m OK committing to a platform, I’m not OK being locked into a service provider.”

read more

Related Posts

Tags

Share This

The Cure for the Common Cloud

Apr 20, 2011 by

Let’s face it.  There’s a lot of hype around “the cloud.” Lots of promises, lots of claims, lots of vendors, and lots of lackluster results.  All the while, software engineers and architects are getting sick of it.

If you’re a software engineer or architect, what does the cloud do for you? It’s elastic and infinitely scalable, so you just put your app up there and everything magically works, right? The cloud solves all of your scalability challenges, all of your app delivery challenges, and it just plain works, right?

Wrong. You’re the one responsible for building the software that the cloud exists to host and deliver, and you know full well that there’s a lot more to it than that.

What about onboarding new customers or business units to your app?  The individual end-users – how do they get access, and to what are they entitled?  What about charging for different features, or different transactions?  What about managing the application lifecycle, and rolling out updates?  What about the underlying architecture to make use of the cloud in an intelligent way?  To actually take advantage of the raw compute power at your disposal, and not just use the cloud like it’s the late 90′s again and people are throwing their apps online like it’s going out of style.

These are the types of things that software engineers and architects are thinking about.

Haven’t we been through this before?


There are many significant engineering challenges associated with building and delivering applications today.  This is very similar to when we first started developing applications for the desktop PC.  Back then, everyone wrote code to manage memory, to interface with specific hardware, etc.  Then the desktop OS came along, and made all of that complex and time consuming (but CRITICAL) work a thing of the past.

While the challenges themselves were different, they were still challenges that were specific to the delivery method, rather than challenges associated with building the actual software functionality.  Those challenges will always be there, because the passion to innovate and develop applications that help facilitate better business performance, and meet the needs of end users is what drives great engineers/organizations.  HOWEVER, the challenges associated with the delivery method/paradigm go away in time, as layers of abstraction come about to solve those problems for us.

The “Cure for the Common Cloud” is Here


Now let’s get back to today.  Shouldn’t we expect that all of these challenges associated with building and delivering next generation software applications in this new cloud era will become a thing of the past?  Won’t we be able to focus on building great software again, and not worry about all of the complexities of the delivery method?  Someday?  Maybe?

Yes.  We can today!

A large and increasing number of organizations and developers have discovered the “Cure for the Common Cloud“.  They’ve found the abstraction layer that handles all of the complex engineering challenges associated with building and delivery applications today, and truly leveraging private or public cloud infrastructure in an intelligent way.  They’ve found the one technology that decouples apps from infrastructure, developers from IT/Operations, and business execution from IT implementation.

The Cure for the Common Cloud is here.  Do you have it?


read more

Related Posts

Tags

Share This

Webinar: Accelerating The Road To SaaS

Mar 22, 2011 by

Webinar announcement: Accelerating The Road To SaaS – 5 Ways To Get To Market Before Your Competitors

For SaaSBlogs readers who are interested, we are holding a joint webinar tomorrow (Wednesday 3/23 at 11:00 EDT) that will cover 5 key lessons critical to the speed of transitioning to a SaaS delivery model.  The webinar is co-hosted by our partner Tenzing, a leading IaaS provider for ISVs.

If you are interested, you can register here:  https://www3.gotomeeting.com/register/897150934

Event Details:
Date: Wednesday 3/23
Time: 11:00 EDT
Location: online
Registration: https://www3.gotomeeting.com/register/89715093

Overview:
Whether your company is a SaaS start up or employs a more traditional on-premise software model, you need to find ways to accelerate and streamline your SaaS application development. The fact is software as a service is exploding; IDC estimating that by 2014, 85 percent of new software companies will be offering their product through a SaaS delivery mechanism.

This webinar explores how Apprenda’s SaaSGrid Application Delivery Fabric combined with Tenzing’s Cloud infrastructure delivers a true end-to-end SaaS delivery platform to enable ISVs to bring their SaaS offerings to market faster with the lowest ongoing cost of service delivery. Why reinvent the wheel when making the move to SaaS? If you are to survive and thrive you need to leverage best of breed technology that will get you into market faster and with the right capabilities to unlock the efficiencies of scale needed for long term success.

Join Will Childs, SaaS Practice Director at Tenzing, and Devon Watson, Director of Business Development at Apprenda, as they discuss their partnership and resulting platform that enables software vendors to dramatically accelerate SaaS delivery while reducing development cost and complexity.

read more

Related Posts

Tags

Share This

SaaS – There’s No Such Thing as a Free Trial

Mar 2, 2011 by

As the popular adage goes: “There’s no such thing as a free lunch.” In SaaS – there’s no such thing as a free trial – there just isn’t.

As a SaaS provider, you pay for it one way or another, it’s a known, sunk cost of doing business and a part of your Customer Acquisition Cost (CAC). However, how large a part of your CAC it is depends on a variety of architectural and operational factors, as well as your maturity level in both areas.

Operationally

At a high level, a free trial process will typically look something like the following:

Now, let’s briefly break-down typical approaches in each of the three high-level operational phases:

Processing Trial Request

Manual – A prospect places a request with a sales rep or submits a request form via a SaaS provider’s website, which is then emailed to someone to process and pass along for provisioning.

Automated – A prospect submits a request form via a website, which is then automatically validated and the prospect receives some form of confirmation of their access (either the actual access, or a follow up email shortly thereafter).

Provisioning Trial Account

Manual – After the request is processed, someone (or worse yet, multiple people) are responsible for provisioning the trial account access. This can range from as manual as people coordinating with one another to setup a new machine or image, to someone clicking a few buttons to provision the account, and everything in between.

Automated – After the request is processed, the account is provisioned automatically, without any intervention. This could mean automatically spinning up a new VM image, creating their username, password, new DB and account, or simply granting them a subscription with proper entitlements to the application (same single DB as production customers … same everything).

Now, I know there will be people that say, “My application is far too complex to provide automated provisioning.” For a great breakdown of why automated provisioning will work in almost all scenarios, check out this post from Sinclair.

Transitioning Free Trial to Paid Account (with data if necessary)

Manual – The trial period is up and the customer wants to move to a paid account. They somehow communicate that to their SaaS provider, and in the worst-case-scenario they need to provision a brand new account, via one of the manual provisioning approaches listed above. Then, if the customer would like to keep their existing account data, customizations they’ve made, etc., their provider will need to migrate those to the newly provisioned account, as well.

Automated – The trial period is up, and best-case, the customer has been reminded a few times in advance of the trial period coming to a close (either via email, or somewhere in the product itself). They’ve decided they want to move to a paid account, so they simply choose the paid plan of their choice from a screen, input and submit their payment information, and they’re back in and using the product – same account, same data, same everything.

Of course, the entire process is much more costly if the end result is a negative outcome – where the user wants to shut their trial down, and isn’t interested in purchasing!

Architecturally

Depending on what level of resource allocation you have for each free trial account, this will, of course, factor into the cost of providing free trials to your users as well.

Physical Machine and Stack Per-Trial Customer – This extreme option entails setting up a physical box with a full application stack, associated licenses, etc., per trial account. This is the courses grained resource allocation.

Virtual Machine and Stack Per-Trial Customer – This entails spinning up a virtual machine image with a full application stack, associated licenses, etc., per trial account. In this option, there is hardware resource sharing, but each trial account requires its own virtual machine, and licensing costs.

Separate Database Per-Trial Customer – Here, there is hardware resource sharing, sharing of the application instance itself, but each trial account requires its own separate database.

Subscription to Single Instance, Co-mingled Data Application – Here, there is fine grained resource sharing, with each individual trial account having little to no incremental resource cost.

Once again, if the outcome of your free trial is not a customer win, having to manually reclaim physical hardware resources (in the most extreme case), each time a free trial ends is that much more costly.

Free trials are a great way to get the product you so lovingly promote in the hands of your potential customers and, if done right, gives them an experience that they can’t live without when the trial is about to end. Making this process as frictionless for you and your prospective customers, and cost effective as possible is a must. It won’t be “free,” but it CAN be pretty close.

I’d love to hear what others have done, and how they’ve managed to implement free trials successfully.

Jesse is responsible for the creation and execution of Apprenda’s strategic marketing initiatives, generating demand and awareness, and evolving the company’s brand. Jesse draws from a strong background in Software as a Service, having served as Community Evangelist and Product Manager at SaaS ISV Autotask before joining Apprenda. Prior to Autotask, Jesse served as Director of Marketing at Eden Communications (acquired by Unicom Systems). Jesse holds a Bachelor’s Degree in Information Technology, with a focus in Neuroscience from Rensselaer Polytechnic Institute.
read more

Related Posts

Tags

Share This

Cloud Middleware: The Language Shared by Network Engineers and Developers

Jan 28, 2011 by

Jeff Kaplan posted an article on Internet Evolution this morning entitled “Bridging the Great Divide in Cloud Computing“. It’s a nice little piece that focuses on a burning problem: the Cloud has been very infrastructure focused, to the point that if you attend industry events you’ll find that, as Kaplan identified, “Those events that promise the latest information and insight about the nuts and bolts of the leading IaaS offerings will likely be overrun by network engineers or storage and security specialists. ”

My experiences have been the same: for the most part, cloud has provided tremendous value in creating a highly flexible datacenter abstraction, democratizing access to high end infrastructure offerings, and trivializing a number of deployment and management issues (think PaaS). Most of this is something that network engineers love (I don’t believe it’s a pari passu displacement of IT staff – Cloud has created a set of more interesting, higher value challenges that modern IT operators need to tackle) Additionally, the Cloud has provide some basic value to software engineers through some highly available and scalable nuts and bolts services (like blob storage solutions, etc.), but the problem domain of building Cloud/SaaS offerings has not been directly addressed by most Cloud providers since the focus has been entrenched at this network and virtualization tier. Cloud at the infrastructure tier is absolutely necessary, but the development community needs more Cloud value that solves modern software architecture problems. The Cloud, with its vast elasticity and democratization of software access to end users, has created challenging software delivery problems like cost efficiency delivery, scalability, and the need for codification of critical operating workflows. These are things that Cloud tech to date has predominantly shied away from.

Historically, middleware/infrastructure software has provided a common layer that acts as a single point of interest shared by IT network level operators and software developers. Think IIS, WebSphere, database servers, etc. These infrastructure software products typically provide a wealth of tooling to network folks in support of applications written by developers that use the pattern and practice productization value captured by these “application servers” to ease use case specific software engineering burdens. When the developers finish building something, the network ops teams can communicate in a familiar way with the same product, but through a different lens.

Looking at the state of the Cloud, it seems pretty obvious to me that we are at an inflection point. The “great divide in cloud computing” is something that can, should, and will be filled by modern middleware purpose-built for the Cloud. This middleware is what can act as the intermediary between the new architecture pressures that software developers must face and the Cloud management requirements of the IT staff. Without middleware handling this, we fundamentally have a better way to host software, which is hardly a catalyst for continued innovation.

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

Related Posts

Tags

Share This

Real World Cloud Architecture: Build or Buy a SaaS Platform?

Jan 26, 2011 by

Yesterday, an article by Brendan Read over at TMCnet really caught my attention because it captured the spirit of what I think about every single day. The article announces the introduction of an IT service management SaaS offering by FrontRange Solutions, a relatively well known mid-market applications company with 2007 revenues at $135 million (as per their company Wikipedia entry) and apps like HEAT and GoldMine in its application portfolio. Brendan Read starts off by accurately stating that “…successfully hosting…complex applications such as IT support tools is much more than installing software onto a server and connecting it to a network that is linked to clients and their users. It requires carefully architecting the solutions for the hosted environment.” Read’s introduction set the stage for how FrontRange did SaaS the right way.

Read hit the nail on the head. Throwing an app onto some servers, whether on-premises or in the Cloud on something like Amazon’s EC2, is not SaaS. I’ve written many times about what it means to truly offer a business offering in the Cloud, but this article captures a real world example of the effort required to move to SaaS.

Read goes on to highlight data volunteered by Michael McCloskey, FrontRange’s CEO that provides an interesting data point: FrontRange “…spent two years re-architecting from scratch a new platform for the SaaS environment” Two years! (Notice the emphasis – I clearly care about this number) I don’t know the hard dollar investments made by FrontRange, but one must imagine that their SaaS platform project had a good number of developers working on it, and that the investment was, with a high probability, in the seven figure category (probably a few developers and architects, as these projects go, with a fully loaded average cost of somewhere in the $90K to $150K range per year working for two years). So a proper product to SaaS transition is a combination of 24 months of SaaS specific effort, seven figures in hard dollar costs (probably), resulting opportunity costs, and ongoing R&D maintenance costs (someone needs to fix the SaaS specific bugs and evolve the platform) – Holy smokes!

I seem surprised, but I’m really not. I’ve been in the thick of this very scenario, and responded by channeling all my effort into Apprenda. Apprenda was built on the premise that a high end SaaS architecture and operating tool-set could be productized into an application server. We built SaaSGrid to do just that – productize a world class SaaS platform so that applications running on it could inherit and give a company a sustainable short and long term solution with tremendous ROI. SaaSGrid was kicked-off as a product knowing full well the costs of a real SaaS architecture with things like multi-tenancy, provisioning, billing etc.

The scenario highlighted in this FrontRange scenario is in fact very much like the ROI analysis we go through with prospects and customers. Someone like McCloskey, faced with a SaaS decision (regardless of whether its a new application or a migration) needs to compare those build figures to investing in technology that they can buy that solves these problems out of the box. Fundamentally, you start to ask yourself:

  1. Does a 12 or 24 month time to market loss result in significant competitive disadvantage? (i.e. Am I liable to lose significant market share or position by letting competitors beat me to the punch?)
  2. What opportunity costs is associated with a competency distraction of this magnitude on the R&D side?
  3. We haven’t built this sort of architecture before, what risk level am I willing to absorb?
  4. Could an additional 12-24 month investment in the product functionality and not the SaaS platform give me access to new markets and revenue streams?
  5. If a home-grown SaaS platform is going to cost $1-$3 million to materialize, what investments am I giving up to make this happen?
  6. Are we going to be able to lend resources to the SaaS platform over time and evolve it despite it being orthogonal to the product, and if not, what untapped value are we leaving on the table?

If you add up the hard dollar costs of the above questions, you start to realize that millions of dollars are required, and the soft dollar costs add many more millions. SaaS is a strategic advantage, but the cost of that advantage is whats in question. Clearly, I do not think that building is a sustainable or strategic overall approach – it’s expensive and distracting. Thats not to say a company can’t be successful (just ask Salesforce.com), but the probability of success goes down while risk goes up when you build. We’ve seen this before – most companies don’t go out and build relational database servers because its not their core competency. Instead they download or license an RDBMS. A SaaS stack is of the same complexity level and same level of orthogonality, so why build? Our goal with SaaSGrid was to let people focus all of their energy on their offering – the stuff that your customers care about – and not on SaaS. My bet is that Cloud build vs buy cases like this will one day define a Harvard Business Review case study or two;-)

How do you feel about this  - does building make sense, or is the ROI not there?  Do circumstances exist where building is warranted, and if so, what are they? What other costs can you think of that should be factored in the SaaS platform build vs. buy?

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

Related Posts

Tags

Share This