A Language a Day Keeps Value Away: Getting PaaS Right

Dec 5, 2011 by

One-man bands are impressive; typically able to play harmonica, guitar, drums, and a bunch of other instruments all at the same time with some meaningful composure but, unfortunately, with very little harmony. Despite this seemingly impressive feat, you never see a one-man band on the Billboard Top 100 – never (and John Popper doesn’t count). The reason for this is simple: one-man bands are good at getting attention on the side of the street, but they simply don’t make good music, let alone music that can be compared to that of a band of specially trained musicians. Being an expert at say, the guitar, requires that you dedicate every ounce of training energy into being a master of that one instrument.  It also means that either as part of a band or solo, you can probably make the Billboard Top 100. This level of depth and dedication means that you won’t be relegated to a sideshow alongside the likes of that guy that pours molten lead into his mouth and spits out a cooled, solid lead slug; you have the opportunity to become a music legend. Certainly, Eric Clapton put in much more effort in learning to play guitar than every one-man band guitarist out there, and probably more than a few of them combined.

Building a PaaS is no different than making music. You can one-man band the hell out of programming languages and stack runtimes, but you’re just going to be making noise that sounds OK and gets eyeballs on the street. What you’ve done doesn’t have durable, legendary potential. It seems that lately, every PaaS provider wants to add as many languages as possible as quickly as possible. A week doesn’t go by where there isn’t a press release that is written in the stock format “<Insert Favorite PaaS Here> introduces game-changing, atom-smashing, world class support for <Insert Whatever Language the Other PaaS Said They Support Here>” This is a recipe for disaster both for the market in general, as well as for customers. There is an easy framework for understanding why this is bad business, and it all starts with being a real PaaS rather some heavily diluted manifestation of PaaS.

Building a PaaS the right way means that you’ve either:

  • Invented a brand new language and execution runtime, or
  • extended an existing runtime (JVM, CLR, etc.) into a new higher order runtime and systems architecture

In either case, the PaaS is doing some intimate, lower level heavy lifting and likely building a host of “base services” that are highly dependent on the language and/or underlying runtime. Those base services are exposed as APIs and are part of provided frameworks, or are capabilities that are instrumented into guest applications of the PaaS. Building all of this is non-trivial and takes a long time to build, but provides extremely rich next generation value to customers.  This is the true meaning of “supporting” a language.

Much like the one-man band, when a PaaS starts laying claim to supporting its 37th language, they’re juggling too many things to properly be an expert at any one, and their version of “I’m good at the guitar” is not Eric Clapton’s version of the same statement. This statement redefinition and implied level of expertise is a good parlor trick, but can’t stand the test of time. The way PaaS providers achieve this is that they define “support” as deploying and loosely managing apps of that newfangled language or runtime type, but don’t provide any uniquely differentiated, high quality value. When a PaaS provider says they support a new language, they likely mean that they can move some pile of indistinguishable bits to a new underlying target application server and issue a “Website Start” command to whatever that target is (e.g. Tomcat, IIS, etc.) If that’s “next generation value”, then I’m in the wrong industry.

The huge downside to this multi-language craziness is that it creates a tremendous amount of market noise and distraction, and robs customers of time and value. Up front, a customer gets excited when they see “support” for so many languages. Some customers might not yet understand what the real potential and long term value of PaaS is. They’ll be satisfied with that PaaS, at least for a while. Once they starting building more complex cloud apps and realize that the PaaS does nothing to help them with this because it isn’t a runtime, then they walk away disenfranchised. For customers with more up-front sophistication, they see “support” as woefully inadequate out of the gate and began to get frustrated with PaaS as a concept in general.

A PaaS releasing support for language after language is a bad smell. It typically (I can’t claim always) means that they don’t have a sufficiently valuable piece of machinery under the hood, and they are likely not offering a runtime model.  If they did, supporting the N+1th language would be hard work, and I would hypothesize that each N+1th language would take more time to support than the Nth language (rationale is fodder for another post). Now, to temper my sentiment, I do believe it is possible to support multiple languages/runtimes, but it has to be done correctly. The result is likely being able to support a small number of languages, rather than all of them.

If you’re an observer, practitioner, or customer in the PaaS space, don’t get distracted by the one-man band on the side of the street while walking to the rock concert – that would be a terrible reason to reach the ticket counter and hear the words “Sorry, we’re sold out.” If you’re a PaaS vendor, please, do it the right way and stop being distracted by shiny objects: support very few languages very well, rather than all languages very poorly. And remember, you might hire a one-man band to work your 8 year olds birthday party, but people pay lots of money and wear their finest clothes and jewelry for one night out at the symphony.

read more

Related Posts

Tags

Share This

The Death of an ISV: How NOT to Succeed in your Move to SaaS

Jul 27, 2011 by

It wasn’t curiosity. It was thinking that the “good old” ASP model would cut it. It was thinking that little by little, they’d get away from labor intensive provisioning, manual billing, and some day refactor the Rube Goldberg contraption that made their “hosted” model work. Sound familiar?

Software as a Service has quickly become the preferred method of application delivery and consumption. Why is it that while many ISVs claim to provide some flavor of SaaS today, few are doing it with the same cost of delivery profile and operational agility as SaaS leaders like Salesforce.com, or Taleo?

Join Apprenda and Savvis on August 9th at 1:30PM EST for a webinar covering the most dangerous pitfalls that ISVs fall into time and time again. You’ll learn:

- The unprofitable truth about the ASP model
- Why multi-tenant infrastructure isn’t enough
- The real-world economics of SaaS leaders and laggards
- How to avoid building dozens of custom SaaS operations systems
- Key business and technical pitfalls when making an infrastructure choice

You’ll come away with everything you need to either “save the ship”, or leap frog your competitors with a SaaS strategy that rivals the best of the best.

Date: Tuesday, August 9, 2011
Time: 1:30 PM – 2:30 PM EDT

Register Here>

We hope you’ll join us!

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

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

Apr 6, 2011 by

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

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

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

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

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

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

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

Stay tuned!

read more

Related Posts

Tags

Share This

Private SaaS: Understanding How Cloud will Evolve for Enterprise IT

Mar 3, 2011 by

I recently spoke with Phil Wainewright of ZDNet and had a great conversation regarding private cloud/private SaaS. The focus of the conversation was to help Phil understand some work we’ve been doing at Apprenda with enterprise IT . For anyone that doesn’t know Apprenda and our platform SaaSGrid, I co-founded the company with the intent of solving a major market problem: create a server technology to help  independent software vendors (ISVs) build amazing multi-tenant, fully web scalable and commercializable SaaS offerings. Basically, SaaSGrid is a layer that sits underneath an application as an “operating system” middleware that provides a modern distributed runtime solving all major SaaS architecture and operating requirements.

As Apprenda evolved, we started realizing that ISVs weren’t the only entities trying to deliver their software  to thousands (or even millions) of customers via a services model instead of a shipped bits model. We found that huge numbers of home built enterprise IT apps were essentially being written as SaaS offerings because of the simplified delivery and consumption model.Enterprise IT could write an application, deploy it as a their own “private” SaaS offerings, and have internal end users, partners, vendors, and even external customers, use those applications. For example, imagine a custom supply chain management application used by the employees of a large, global logistics company, or an HR app deployed to multiple lines of business within the enterprise. We also found that a cloud application architecture is not something that solves problems unique to ISVs, but that we could give the same or more value to enterprise IT. Furthermore, we started noticing that enterprises are building private clouds, essentially IaaS offerings within the enterprise, allowing for flexible access to massive pools of resources. This solves a number of IT problems, but now developers are aching for access to higher order value: essentially, a platform like SaaSGrid that could be deployed ontop of that IaaS to rapidly build complex cloud architectures and deploy those architectures to their private clouds. My conversation with Wainewright really honed in on understanding how and why enterprise architects are adopting cloud architectures for internally built custom applications.

Wainewright wrote up a great post entitled “The OEMing of SaaS: build or buy?” that describes private SaaS in good detail. At the end of his post, he posits that “…the case [is] against ‘private’ SaaS and in favor of having the provider run the platform” I don’t think this is necessarily a good position, at least in terms of a coherent taxonomy. First, we need to make sure we don’t confound Cloud topic areas. Where an application lives and it’s “visibility” are two different things. A Cloud application has a few attributes associated with it:

  1. Where it’s hosted (yes, I’m using the word hosted. Cloud does not mean apps still aren’t hosted, they’re just virtually hosted)
  2. It’s visibility, or in other words, who is allowed to use it (anyone who pays, anyone who pays but restricted to a defined group, no payment required but not for general consumption). Think of Salesforce.com as ‘public’ while something like an app written by my former employer Morgan Stanley for their own investment bankers as ‘private.’ Public and private need not have the same meaning in the SaaS context as they do in the infrastructure context.
  3. What architecture dependencies (if any) the application has

Being ‘against’ private SaaS, at least by how we define it (where again, ‘private’ is a visibility construct that helps determine who is allowed to consume the app) has nothing to do with where it runs (the provider running the platform). For example, if an enterprise chooses to use a Cloud platform like SaaSGrid, they are choosing to use it because it solves some very tricky architecture and operations problems. Morgan Stanley, for example, might choose to build a multi-tenant app for it’s thousands of retail banking branches on something like SaaSGrid to solve distribution, scale, provisioning, and entitlements problems through multi-tenancy and infrastructure abstraction, but still run it on something like EC2. Running the app on EC2 doesn’t make the application ‘public’; it’s still only privately accessible but running on a ‘public’ cloud. That said, there is also nothing wrong with someone like Morgan Stanley deploying a their private SaaS app on their own infrastructure, or with building a private Cloud stack with something like SaaSGrid running atop their internal IaaS offering. There are huge advantages to this as well.

This leads me to a brief discussion of the evolution of Cloud in the context of enterprise IT (and maybe even the broader market in general). First, I think we’ll always have two distinct stack layers: IaaS and PaaS. The state of PaaS as a Cloud layer is important to understand. To date, most PaaS offerings have not focused on the changed software consumption paradigm where thousands or millions of people plan on consuming a centralized service. That’s still an architecture that most developers have to deal with.

Offerings like Heroku, which was referenced by Wainewright, abstract away the infrastructure and provide a package, deploy and run model for arbitrary applications. These platforms do little to nothing for the applications’ fundamental architecture qualities and runtime behavior, and merely simply part of the build, configuration and release process, and remove the need to deal with IT staff. In this case, forklifting an application off of a PaaS to another PaaS, or even to IaaS, is easy and requires no code changes. Unfortunately, these types of PaaS offerings are uninteresting from an advanced application architecture and engineering point of view (don’t misinterpret this as uninteresting in general. I find PaaS offerings to be amazingly valuable, just not in terms of solving challenging architecture and engineering problems like multi-tenancy, which are still dealt with “by hand”) If someone chooses a platform (PaaS or cloud-focused architecture platform) that provides a modern, advanced Cloud architecture out of the box and that provides your application with significant runtime value, you won’t think about  forklifting the same codebase from the platform to something like IaaS or some deploy-focused PaaS offering because you will lose all the architectural value you were after in the first place. This means that the Cloud  runtime, to prevent operational lock-in, must be decoupled from the provider. If it is not, you are in grave danger of being operationally beholden to the provider for fundamental architecture needs. This is extremely risky.

Enterprise IT faces extremely complex engineering challenges; they don’t build “websites”, they build sophisticated web applications that need to deal with challenging problems. The Cloud will evolve to acknowledge Cloud architectures as a topic separate from Cloud “hosting”, and that the two layers should be decoupled as a rationale step to ensuring freedom and openness. What I expect to see is that enterprise will adopt Cloud runtimes to solve their engineering challenges, and whether an app built on that runtime is deployed in their private cloud or  in the public cloud will be dictated by an entirely different set of parameters. Any external providers that think they can have people write code that will run in their Cloud and only their Cloud will not succeed in the long run.

Have you worked on private SaaS projects built by your enterprise IT organization? Do you think the Cloud will evolve into a runtime and hosting tier, or will you be forced to choose a runtime that is locked in to a single provider? I’d love to hear your thoughts!

Before co-founding Apprenda, Sinclair held positions at Morgan Stanley, Eden Communications, and the State University of New York (SUNY). Sinclair holds a dual Bachelor of Science in Computer Science & Mathematics from Rensselaer Polytechnic Institute, where he graduated Summa Cum Laude. Sinclair excels in understanding the economics of SaaS platforms and ecosystems, and is a frequent speaker and panelist at industry events

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