More On Cloud Middleware

Jan 31, 2011 by Matt Ammerman

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

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

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

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

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

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

read more

Cloud Middleware: The Language Shared by Network Engineers and Developers

Jan 28, 2011 by Sinclair Schuller

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

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

Jan 26, 2011 by Sinclair Schuller

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

2011 Predictions for Cloud, SaaS, Multi-Tenancy and More!

Jan 10, 2011 by Sinclair Schuller

OK, it’s already 2011 and I’m a bit late on providing some predictions for 2011 – but now is better than never! I sat down and thought about events in 2010 and whether those events have created a meaningful disruption with near term potential to affect 2011 outcomes, and this is what I came up with. Some of it is based on intuition, some on knowledge, and some experiences I’ve had at Apprenda in working with customers, prospects, and others in the industry. This is more of a mental exercise in subjective extrapolation rather than “prediction”, so don’t hold me to these;-)

1)Adoption of SaaS by ISVs will pick up more steam in 2011

a.Overall, an overwhelming majority of Independent Software Vendors (ISVs) deliver their software via the on-premises “packaged software” model. Consumption of software as a service (SaaS) offerings continues to grow at an amazing pace, but most of the demand has been satisfied by a couple of hundred companies that have surfaced in the past 10 years as wild success stories, such as Salesforce.com. As a result, I expect that on-premises player will continue to take notice and make the switch.

b.Competitive pressures within major verticals are becoming more and more real due to successful SaaS entrants, which will drive adoption of SaaS delivery as a market response. Existing software ISVs will start respond by moving part of their product lines to SaaS, or by choosing to offer down-market offerings as an initial experiment.

c.Counter to the perspective of many experts, packaged software ISVs will find strategies that work in their transition to SaaS. Transitional “poster-children” of each vertical will give confidence to other ISVs in the market that the transition can be made successfully.

d.Continued adoption of new technologies such as platform as a service (PaaS) and cloud application servers will bridge technical gaps that will ease the overall transition burden, fueling adoption of SaaS by more and more ISVs. I do not think SaaS is the nail in the coffin for existing ISVs, particularly with technologies like SaaSGrid in the mix which flatten the technical curve for both new application development as well as migrations.

e.Continued explosion of mobile usage creates further pressure (and significant opportunity) for companies to move to a SaaS delivery model. Most business applications that have a mobile angle typically need back-end systems to reconcile the data into primary applications, and SaaS is the only architecture that makes this feasible at scale across many customers.

2) The Upstack Scramble Intensifies

a.Big players continue to make big moves to seize the opportunity to control the new software battle ground in the cloud. Traditional platform vendors will realize that the application development and architecture tiers are huge opportunities, and that infrastructure virtualization and infrastructure tier technologies are not the competitive landscape of the future. Deals like the Heroku and Makara acquisitions make a lot of sense for players like Salesforce.com and Red Hat, respectively.

b.2011 and 2012 will be a make or break years for these big players, and the moves they make over the next 12 to 24 months will ultimately determine the next decade of control and leadership.

c.Commodity players, or players that have become commodity, seek to buy value up-stack through acquisitions.

3) Real Traction with Private Cloud/Internal Utility Computing and SaaS delivery

a.Mistakes and failures experienced in 2010 will be the lessons learned to drive the real solutions and seed private cloud and private PaaS adoption over the next 12 – 36 months.

b.Organizations want a unified and scalable platform for software delivery, and the vision of private cloud will begin to include technologies that sit above the virtual tier to give significant architecture and services value to internal development assets. A paradigm shift in how software developed internally for business units will kick off.

b. Enterprise projects will continue to explore leveraging Cloud architectures such as multi-tenancy for internal use. The cost savings and agility potential presents enormous savings profiles that push their way into enterprise development shops.

4) Cloud Washing Reaches Critical Mass and Collapses by EOY 2011

a.After attempting to cloud wash offerings, a number of small and mid-market ISVs will close shop due to competitive pressures and no real tactical response. This will help identify cloud washing as a poor strategy and that only real, measurable attempts to convert a SaaS model will lead to success.

b.Forces vendors to articulate how their strategies and solutions that is unique and truly “cloud.” Continued success of pure-cloud/SaaS plays will evidence that cloud washing adds no value.

5) Force.com Starts to Realize Momentum Potential

a.Force.com/Apex’s stuttered start begins to gain true rhythm now that Salesforce.com has diversified its cloud to be competitive outside of its proprietary track, particularly in Ruby and Java arenas due to Heroku and VMForce.

b.Force.com will continue to show strong among those extending Salesforce.com’s CRM functionality and potentially within the enterprise where it can be used to displace situational “spreadsheet” applications.

6) Cloud Middleware Provides Democratized Access to Complex Software Architectures

a.General development/programming skills declining, coupled with a continued increase in architecture complexity creates a gapping void that new middleware needs to fill

b.Just like the years when desktop OS’ spurred innovation by enabling companies to focus on their software and not the underlying complexities associated with its delivery – new solutions will fill the gap and catalyze a similar era of innovation once again.

c.Middleware solutions like SaaSGrid will drive multi-tenancy as a defacto standard since the primary concern of difficulty and cost to implement is trivialized.

7) QE[pick your number] won’t be a panacea for the economy – but SaaS and Cloud will help

a.Economic factors will continue to put pressure on operating budgets. Companies will be looking to do more with less; that is, they’ll want to boost efficiency while slashing budgets in order to survive in the modern economic climate. Due to size, IT budgets will be scrutinized and IT managers will be challenged to come up with solutions.

b.SaaS will be seen as a means of democratized access to solutions that drastically improve efficiencies while driving down the cost of IT. Infrastructure as a service will be leveraged to reduce the operating burden associated with in-house infrastructure.

c.Doing more with less, optimizing business performance – SaaS based B2B solutions will grow significantly in 2011 as a result.

I’d love to get everyone’s thoughts. Agree/disagree? Why? Did I miss something or does this seem to cover the right surface area?

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

Salesforce.com’s Heroku Acquisition: A Clear Stake in the Ground

Dec 25, 2010 by Sinclair Schuller

Salesforce.com, over the past few years, has been reinventing itself as a platform company. IMHO, this is an extremely difficult thing to do for a company who’s cash flow is defined by the CRM market, an acronym that Salesforce.com adopted as a stock ticker. When Salesforce.com first announced Apex, it’s new fangled programming language and pseudo-stack, I took a highly critical stance because it was a clear attempt by a marketing and business team to tackle problems that only technologists can properly understand: building runtimes and frameworks that could provide a foundation for future software in the Cloud. My gripe was that Salesforce chose to create a new language that wasn’t rooted in a development paradigm shift where changes in a programmers ability to express solutions are the motivator, and instead decided to base the language development on seemingly more selfish interests and coupled the languages runtime to their operating and hosting environment. Essentially, they created vertically integrated lock-in, which is terrible for customers and the lack of purer motivations on the language development side produced a sub-par development stack best suited for small add ons.

Now we’re in 2010, and the story is starting to change, and seemingly for the better. At Dreamforce this year, Salesforce.com announced the acquisition of Heroku, the well known Ruby PaaS. Not too long ago, Salesforce.com and VMWare announced VMForce, bringing Java into the Salesforce.com cloud. Salesforce.com’s  evolution seems to be taking it down a path of stack agnosticism. This could be due to good strategic decisions making, or out of an attempt to correct a failed path with Force.com/Apex. Whatever the case maybe, its clear that Salesforce.com is embracing other stacks, and no longer focusing on creating a new $1 billion business by brute force.

It will be interesting to see where Salesforce.com goes with this. Will they make Java officially part of their Cloud by folding up a partnership with VMWare and instead make a Java Cloud their own competency? Might they go after Microsoft’s base by building or acquiring a value proposition that targets .NET developers and attempts to attract that group (who own 40% or so of the development market share) away from Azure? Who knows how far they’ll go, but one thing is clear: the Heroku acquisition clearly signaled that they want to do something different, and that something includes languages and runtime’s well outside of Apex. I really am glad that they’re adding true value and no longer beating the Force.com drum exclusively.

How do you feel about Salesforce.com’s Heroku acquisition? Any predictions on the success or failure?

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