The Up-stack Scramble – Cloud Nine for Developers will be Trench Warfare for Vendors

Mar 23, 2011 by Devon Watson

The Cloud Computing industry has been in a state of technologic and rhetoric driven flux ever since the term “cloud computing” was coined. Coming from both a software and venture capital background, I enjoy paying close attention to the often incongruent evolution of both our industry’s capabilities and its marketing claims. This disparity isn’t unique to the Cloud industry. Most new markets experience this while the vernacular jargon gets socialized and standardized on. Case in point, the term Nanotechnology was actually coined to refer to the concept of self-replicating autonomous bots (ala Michael Crichton’s Prey novel), what the world got was a much broader and less grandiose set of mainly micro-scale innovations all loped under that industry name.

Similarly, Cloud Computing was initially taken to mean perfectly abstracted infinitely elastic computing scale in an on-demand basis. We don’t have this yet. What we have, and Im referring specifically to IaaS since it is our basic building block, is easy to configure, easy to provision, on-demand, utility priced virtual machines. This is a great progression for the software and IT professions, but it falls short of fulfilling the fanciful capabilities drawn in people’s minds. Cloud IaaS makes it easier and cheaper to do what we’ve been doing for years, but hasn’t profoundly changed the actual requirements, workflow or operational hassles that developers and IT administrators face. As a Senior Enterprise Architect at a large enterprise remarked to me last year – “we’ve run the course with virtualization, we did that years ago.”

Making compute power available has been solved – the current challenge is to put that instant-on horsepower it to work. To be clear – this is being done fairly well in some use cases: big data crunching (CG rendering, map reduce) and consumer facing websites come to mind because they have scale mechanics that rely on simple replication and balancing.

Business applications, however, are still beholden to the underlying topology of servers that supports them. The application itself and the IT system must be intrinsically wired together in order to function properly. For example – business applications often store large amounts of data and will store data across multiple servers. If user number 523 logs in and her data is on DB server number 5, how do you fetch that data when she sends a request through UI server 3? Answer – the application has to know who she is, where her data is stored and how to retrieve it. This enmeshing is necessary to solve many similar complexities, but makes it extremely difficult to take advantage of today’s current Cloud infrastructures – without completely re-architecting and rebuilding applications from the ground up and adding multiple highly complex new systems.

In order for this current world of instant-on cloud servers to be truly impactful and revolutionary for developers and IT operators we must continue to elevate them further away from the underlying mechanics and break the bonds between application and infrastructure. In order to do this, we need some middle tier that abstracts the application away from the underlying server topology and surrounds that application with the management, authentication, user-routing and scaling mechanics needed to seamlessly take advantage of newly provisioned resources. This is why we are seeing a universal up-stack migration by the industry leaders like Amazon, Microsoft and SalesForce.com into the still-evolving realm of PaaS (platform as a service) where the original vision of throwing code into an autonomous external cloud of elastic computing power is starting to coalesce in a couple offerings.

SalesForce.com’s “Force.com” platform for instance holds true to the “deploy and forget” ideal, but ties the developer to a restricted programming environment based on their own proprietary programming language in return. To counteract this, SalesForce.com has made bold moves by first partnering with the leading provider of virtualization technology (the underpinnings of the cloud movement) VMware to create VMforce for Java and then acquiring Heroku for the Ruby programming language. It wont be long before these two additional platforms are able to take advantage of the value added capabilities built into Force.com. The last few months have also seen the acquisition of Makara (another PHP PaaS) by Redhat, giving this enterprise heavyweight a compelling Private PaaS story for their client base. Amazon, the standard in IaaS, has been building new up-stack capabilities in-house and recently released their Beanstalk service which simplifies scaling Java applications. Not to be outdone, VMware last week announced the acquisition of WaveMaker a Rapid Application Development tool that compliments their SpringSource acquisition. Its not hard to imagine a new RAD-PaaS offering with these capabilities.

Scrolling this stream of movement, it can be hard to divine where this is all heading and where the competitors will bump into one another. It all comes down to the application developers and what up-stack capabilities you can offer them that improve one or more of: their build-time productivity/speed; the business value they can incorporate into their applications or the ease/quality of the ongoing application delivery. The following graphic gives a basic snap shot of where we are and how I see this evolving.

read more

SaaS for the ISV Masses through SaaSGrid Express

Jun 7, 2010 by Sinclair Schuller

When my partners and I co-founded Apprenda, we had a number of very specific goals when it came to SaaS enablement and we wanted SaaSGrid to embody those goals. My co-founders and I all came from technical backgrounds where we were responsible for SaaS engineering efforts. We learned early on that when a SaaS application is engineered properly, its architecture is drastically different than plain old web applications (think multi-tenancy and scale-out) and that a huge number of auxilliary tools and subsystems (think billing, application life-cycle management, infrastructure management, subscriptions, identity federation, etc. and then some) are necessary for managing and operating a SaaS offering and business.

When you combined these “SaaS specific” aspects of a SaaS offering, the upfront and ongoing time and money investment required far eclipsed that of the application itself (the actual thing your customers want to pay you for!), and causes huge competency distraction. Taking on the build out and maintenance of a mature “SaaS stack” is akin to a software company deciding that it’s in their best interest to build and maintain their own DB technology in support of their business application.  Surely, most people buy RDBMS tech (like SQL Server) or download it (like PostgreSQL) to help ensure succcess, and firmly believe that they need not build their own. When we created SaaSGrid, we had some very specific things we wanted it to do:

1. Allow for the use of traditional stacks (in our case, the Microsoft .NET platform) and the wealth of tools and components already in existence for these stacks. New languages are best created in support of new modeling paradigms or changes in the ways we capture solutions, and not in support of a new delivery model. Traditional runtimes simply needed to be “enhanced” to really sing in an on-demand scenario.
2. Have it be comprehensive and not require a “paper mâché” approach to piecing together disjointed capabilities. Imagine that an operating system required that you find your networking substack from here, and a graphics subsystem from there, and then require that you mash them together. That would be sub-optimal in many ways.
3. Have SaaSGrid provide even the most complex capabilities, like multi-tenancy, as transparently as possible to the application code that runs on top of it. As technologists, we hate having technologies adulterate our code, so to the extent possible, we wanted SaaSGrid to be as low impact as possible.

We accomplished our goals and some, and our customers benefit wildly from SaaSGrid. But late last year, we were thinking about a number of things related to the market and to SaaSGrid. As a company, we’re committed to not only supporting the transition to SaaS, but to catalyzing it. I think great strides have been made with respect to software company adoption of the new delivery model, but the fact of the matter is, most ISVs are still not SaaS. Furthermore, those that want to become serious SaaS players have a tough time understanding how they can get there and what tools are available to them.

Enter SaaSGrid Express!

Anyone that follows my company Apprenda knows that we recently made a new product announcement with SaaSGrid Express. SaaSGrid Express is a freely downloadable application server that captures nearly all of the value of our tried and true SaaSGrid, and that can be used by anyone just to experiment or even to build a revenue producing business. Our goal with SaaSGrid Express is to let everyone experience the value that SaaSGrid has to offer, and more importantly, to democratize a highly complex SaaS architecture in hopes of moving the industry forward.

Phil Wainewright recently offered some excellent insight in his recent blog post regarding SaaSGrid Express; the goal of democratization also means that some people might get there hands on a technology but are simply not prepared to build their own clouds. But as Wainewright went on to point out, those same people would have gone down that path with or without SaaSGrid, so we’re happy that they’ll be able to walk away with such a robust starting point. Giving SaaSGrid Express to the world means that more people than ever before can experiment with and commit to a proper SaaS architecture, which will definitely help satisfy our vision of catalyzing the space. As Dana Gardner suggested, SaaSGrid Express opens up the potential for a “cloud standard” architecture and SaaS stack. If we accomplish that sort of de-facto standard, then the industry is definitely off to a good start. Having a de-facto SaaS stack means that people are not focusing on complex architectures, but on business value for their customers – which would be a huge win for everyone.

Something Special for YOU!

For those loyal SaaSBlogs readers that have an interest in downloading SaaSGrid Express and building an application, we’d like to offer you something special:

For the first 5 SaaSBlogs readers that sign up for SaaSGrid Express with the intention of building an application, or migrating your existing .NET offering, we’ll commit 1 hour of time from one of our engineers to personally work with you, and get you up and running with your project!

Just mention that you’d like to take us up on this special SaaSBlogs community offer in the comments section of the sign up form.

read more

A Future of Cloud Stacks or Cloud Silos?

May 11, 2010 by Sinclair Schuller

When thinking of the cloud, there are two sides to the coin: those who build SaaS offerings and those who consume them. For those who build SaaS applications, we’ve seen a glut of tools crop up to help engineer, architect and deploy SaaS offerings. Some are “horizontally” aligned (think EC2 on the IaaS side, SaaSGrid on the application server side, etc.) while others are “vertically” aligned holistic silos (think Force.com on the PaaS side – even with the recent VMForce announcement) and some are in a mid-silo middle (think Google’s AppEngine and Microsoft’s Azure, both “up to the runtime” PaaS stacks).

Given that there is so much velocity, tumultuousness and general confusion (acronym hell coupled with taxonomical conflation – aka the “everything and everyone is a platform” syndrome), we’re bound to see some order evolve in the future where the evolution will be motivated by what people actually use and adopt rather than the current landscape which is driven by who can yell the loudest.

The big question is what will the future of cloud architecture look like: a stack of interchangeable layers that allow one to choose best of breed or a group of incompatible but highly specialized “holistic silos?”

Looking at the history of infrastructure middleware, the answer seems to be quite clear. Typically, the trend has been that layering functional best of breeds into stacks provides the best combination of “lowest common denominator” coupled with the necessary functional value to “get things done” and keep risk minimal. For example, I can choose servers made by HP, a Windows OS, Java and JBoss, and build a killer enterprise app. If I so decided, I could have swapped Windows for Linux and essentially had a compatible stack experience.  Why, then, are silos cropping up in the market?

Silos like Force.com have their appeal. They promise a world where all your needs, ranging from hosting and execution runtimes in the cloud all the way through development frameworks and distribution channels. The problem, however, is that the software market cannot be addressed as a broad stroke.

The needs of software companies vary wildly: ISVs in the healthcare space may care more about hosting certifications than someone in the CRM space, while those in business intelligence need low latency, high compute availability and the others who altogether care very little about the hosting and it’s all about what middleware they are going to use. The number of needs permutations is staggering.

To think that Platform as a Service vendors that own the full stack, from hosting through runtime and even UI components, can ever optimize for each of these scenarios is ludicrous.  Furthermore, the silo providers ask for something huge in return for a suboptimal solution:  control of the ISVs destiny in all regards. That’s a high price to pay for a promise that can’t be fulfilled.

	Cloud Stack	“Half Stack”	Cloud Silo
Operations Management	SaaSGrid		Force.com, Quickbase
SaaS Middleware		Microsoft Azure, Google AppEngine
On-Premises Runtimes	.NET, Java, etc.
Cloud Infrastructure	EC2, Rackspace Cloud,  GoGrid

I’m a firm believer that most if not all software will be delivered online. It’s the only way to achieve true ubiquity, and it requires superior delivery. Each ISV is going to have to make lots of decisions as they move to the SaaS delivery model. Those decisions are going to focus on how to best solve all the critical problems associated with becoming a service provider. The only logical conclusion is that each ISV will look for best of breed tiers in a stack form that would allow them to create an optimized outcome. I don’t see a grand future unfolding where thousands of ISVs worldwide commit to incompatible silos that require taking on relationships that amount to single points of failure and risk. As a stack becomes more vertically consolidated (i.e., more siloed), the higher the risk grows for an ISV. If ISVs take on piece-meal stacks composed of highly compatible tiers, the walk away with the best of both worlds.

What do you think? Do you think that the next generation of business applications will be split across walled silos, or will the market adopt levels of commonality by converging to a stack approach with solutions provided by a few key companies at each layer, allowing for a “composable” stack approach that we’ve grown accustomed to?

read more

Will SaaS Companies Benefit from a Virtuous Enablement Cycle?

Dec 24, 2009 by Sinclair Schuller

Mike Vizard over at IT Business Edge wrote a blog post a couple of days ago where he described SaaSGrid as potentially having “…the most impact…” on the Cloud market (using the word ‘market’ here very loosely) when compared to other cloud technologies like Force.com and Azure. I’m both flattered and clearly in agreement, but one subtle comment in his post caught my attention: “More targeted SaaS application environments will evolve…”

I entirely agree with Vizard’s sentiment, which prompts the next question: how will targeted SaaS application environments evolve and why will more crop of them crop up. I think the answer comes from understanding some of the history behind SaaS enablement technologies, what they mean to those who use them, and what the results of those who use them mean to the market in general.

Most good SaaS (and non-SaaS) enablement technologies crop up because of need, or what I’ll call negative pressure. For example, at Apprenda we built SaaSGrid because the founding team (myself included) had worked on a variety of SaaS projects in a “ground up”  fashion (I’ll write about the Apprenda founding story at some point). We found that an inordinate amount of time was spent on SaaS specifics, most of the bugs and maintenance problems came from the home-brewed SaaS stack, and most attention was deviated from the actual business problem the SaaS offering was trying to solve, leading to a gross loss of focus and an attempt to build a dual competency (building a SaaS stack plus building a domain specific business application).  The lack of a foundational SaaS stack created negative pressure (a vacuum, if you will), causing us to found Apprenda and build SaaSGrid, thereby filling that void for all others that were destined to take on the arduous “build” path. Our customer base includes companies that were “on the fence” with respect to building a SaaS business that decided to move forward because SaaSGrid reduced the hurdle of architecting a SaaS offering and building a SaaS business so significantly that they decided to move forward. In essence, technologies like SaaSGrid act as a catalyst.

(bigger)

From a macro-market perspective, enablement technologies focus on boosting product yield (essentially, SaaSGrid’s goal is to boost production efficiency and quality, thereby increasing production yield). This is what fulfills Vizard’s prediction of “More targeted SaaS application environments will evolve…” The catalysis of SaaS application development by application platforms like SaaSGrid boost yield, any success stories  reinforce  both the market story for SaaS and the enablement story, which will create positive pressure, or new enablement companies wanting to participate in or replicate the commercial success. The pressure isn’t void based, but in fact is rooted in the existence of success. This is a huge boon to ISVs with SaaS aspirations, because it means all eyes are focused on helping them achieve their goals.

Why is SaaSGrid so impactful compared to other technologies? Because we’re one of the few (and probably only from a technology perspective) that focus on bridging the gap of current technologies to a SaaS end-game, and not just on a generic “cloud” end game (i.e., we focus on the distribution model, not on the idea of ‘running code online,’ which is something very different). The idea of a “SaaS application server” is so fundamentally pure in its goals, that it resonates well with an ISVs aspirations and acts as that catalyst and foundation to success. Although this sounded like a big SaaSGrid plug, it’s truly rooted in my passion for this wonderful delivery model and the value we bring to other software companies.

read more

Farewall to PaaS Provider, Coghead

Feb 19, 2009 by Sinclair Schuller

Coghead announced it was shutting it doors yesterday evening. For those unfamiliar with Coghead, it was a much talked about PaaS offering that offered an online application editor for rapid application development. They fell under the category of non-standard stack, a “4th generation language and runtime” (4GL) if you will. It seems that slow adoption coupled with the economic situation got the best of them. This is clearly a big problem for Coghead customers, and is indicative of why I don’t particularly like the “PaaS requires a new language/runtime/stack (pick and choose) because older runtimes and languages simply don’t work” statements. First, the notion that something like C# (or any .NET runtime language), Java, or Python can’t work is simply a problem with fundamentally understanding runtimes and what they can and cannot do. Second, new languages and stacks are generally dangerous unless they have MAJOR support from a large platform vendor. Why? Risk. Coghead is letting folks know they can access their data until April 30th, 2009. Unfortunately, data is not the application and any VARs, ISVs, or IT departments are up the creek without a paddle when it comes to the application itself. If the apps were built on some industry standard runtime, and the PaaS injected native SaaS into the applications, they would still retain the ability to run and use the code elsewhere (this is what SaaSGrid does). Last, some 4GL has a tough time leveraging existing code assets that your company may have invested thousands or millions into.

As for Coghead, it’s always a shame to see a startup go, despite our market approach differences. I wish the Coghead team the best of luck. Fortunately for customers, it didn’t take long for many of their competitors in the “WYSIWIG” DIY application platform space to come to the rescue:

1. Intuit QuickBase>
2. TrackVia
3. Caspio
4. TeamDesk

There have also been a few development firms offering to ease the pain as well:

1. Scio Consulting (Full disclosure, Scio is a partner of ours at Apprenda)
2. DeliveredInnovations

While it’s great to see that there are options for Coghead’s customers, it also causes me wonder once again why anyone would want to lock themselves into a full non-standard stack offering?  Granted, I have a bias as one of the creators of SaaSGrid, because our model is the exact opposite. However, our model is the exact opposite because we didn’t even see that as a reasonable approach to doing business and this is a clear example of why. A startup should focus on ensuring that it’s customers are safe and are not sinking time and money into something that cannot function outside of that runtime. If you’re building ontop of a runtime that does not have a natural “fail safe”, take a lesson from what’s going on here.

Is my fear of non standard languages overblown? Is reducing risk a better ‘key feature’ of a 3GL based PaaS, or is the fact that it can leverage existing software assets the more appealing attribute? If you are a Coghead customer, have you found alternatives yet?

The SaaSBlogs group on LinkedIn now has 1450+ members and it’s growing every day; make sure you are not missing out and join today.

read more

Is Outsourcing Software the Same as Outsourcing Other ICT Processes?

Dec 6, 2007 by Sinclair Schuller

We generally try to compare current decisions and ideas to decisions and ideas that we’ve made/had in the past and that parallel those that we are currently evaluating. This tends to be a good way to “analyze” the decision or idea and pick it apart. Organizations are familiar with outsourcing certain types of Information and Communication Technology (ICT) processes, so the idea of “outsourcing” is not new. We have our websites hosted offsite, we use offsite backup services, we use telephone and VoIP service. When comparing outsourcing other ICT processes to the parallel decision of outsourcing software (using SaaS offerings), is it equivalent? At first blush, the answer seems to be yes (clearly, I’ve set this up to argue the opposite).

Taking a look at most of the ICT services we’re accustomed to outsourcing, we can profile them as horizontal in nature; telephones, websites, backup all seem to unrelated to the specifics of the organization doing the outsourcing. Providers of these services generally do not have to deal with any vertical intricacies (other than exploit properties of the vertical for marketing purposes).  Being that the set of outsourceable services are horizontal in nature, there is generally a high level of substitutability. This is also true (particularly for the SMB) with respect to things like SaaS delivered CRM, HR, finance type offerings. Although an SMB may not want to switch from some CRM SaaS provider, if they have to they can and they will because of the horizontal nature of the offering. This makes the decision to outsource that type of software to a SaaS provider similar to that of not hosting your own website, etc.

What about highly vertical SaaS offerings? This is where things are different and outsourcing software does not parallel outsourcing of traditional ICT processes. Offerings that are “more vertical” make the decision of outsourcing the said process more difficult since there is a significant change in substitutability and in the number of providers offering the service. After all, are there more providers selling dairy farm management software or more providers selling “generic” CRM software?

(bigger)

Software, unlike other ICT processes, can highly target a vertical. Unlike traditional (read horizontal) ICT processes or even horizontal SaaS offerings, vertically aligned SaaS offerings may link to a consuming organization’s core operational processes tight enough that lack of control over the service delivery may be risky, so the decision making process on whether to outsource that software or not is significantly different than the decision making process used in traditional ICT outsourcing or in subscribing to CRM functionality as a service. I think this is part of the reason that things like CRM and HR have led the SaaS wave, and verticals are laggards. To be fair, however, vertical software offerings have traditionally been very expensive. SaaS may open the door to the delivery of highly vertical functionality to customers who would be unable to afford the functionality via any other delivery model. As a result, in many cases the question may not be outsource the software but rather live without the software altogether or use an offering delivered by an outsourced provider.

Do you think all ICT processes are created equal and have equivalent outsourceability? Are highly vertical, “close to home” types of software more difficult to offer via SaaS or do the economics quell any concerns?

 

read more