It’s important to first understand where the term “cloud” originated, as it should really be used in a constructive approach to arriving at the definition of “private cloud” and the determination of how accurate of a term it really is. The term “cloud” originates from a scary place: network diagrams. Have you ever used Visio or a similar tool for modeling diagrams? If so, and if you’ve ever created diagrams that required some sort abstract network, you’ve undoubtedly used the “cloud icon” (which looks kind of like the dust-balls that the Road Runner would leave behind when being chased by Wiley Coyote). This icon was used to denote an abstract network at some responsibility boundary.

Ok, so the history of the term cloud is somewhat rooted in telephony, but we definitely adopted the icon for broader use in general network diagrams. Point being, the origins of the term “cloud”" had nothing to do with the public Internet, and I’d argue it still doesn’t. A cloud is simply an abstraction of network and resource responsibilities that one can leverage in support of some other functional tier or silo. The network diagrams that we’ve all created never restricted the use of the icon to the Internet, but rather remained open to use in any situation where you had to clump non-specific, potentially unidentifiable (but conceptually understood) resources into a dependency.

Given the history of the term and its typical usage, what makes the term “private cloud” so broken? Nothing. An enterprise can use Internet architectures to create internal, “private” resource abstractions. These are private clouds that can be used in a variety of capacities. Granted, larger enterprises are better positioned to leverage private clouds, but that doesn’t mean smaller enterprises won’t build them as well.

All this said, I do distinguish the Cloud, as a proper noun, from a general cloud. The proper noun Cloud should be used to identify the public internet.

How do you feel about the term private cloud? Does history not matter when it comes to best understanding the term? Let me know!

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.

]]> http://www.saasblogs.com/2009/12/24/will-saas-companies-benefit-from-a-virtuous-enablement-cycle/feed/ http://www.saasblogs.com/2009/12/10/do-you-have-to-leverage-x-as-a-service-to-be-a-saas-provider/ http://www.saasblogs.com/2009/12/10/do-you-have-to-leverage-x-as-a-service-to-be-a-saas-provider/#comments Thu, 10 Dec 2009 23:29:41 +0000 Sinclair Schuller http://www.saasblogs.com/?p=268 I love the idea that a balance exists between ideology and practicality. Questions of ideology and practicality always arise when it comes to building software, building a business, and building a software business. SaaS is no exception.

Interestingly, I had two different discussions with people who were of the position that aspiring SaaS company’s should “put their money where their mouth is” and use cloud technologies exclusively to build out their SaaS offerings, stating that it was a form of hypocrisy to offer SaaS and not use Infrastructure as a Service or Platform as a Service.

The question I have is whether it is necessary to bind yourself to “XaaS” technologies in order to be a SaaS provider. To be honest, I think that such a “requirement” is absurd. No, you don’t need to use IaaS or PaaS or anything of that nature to be a SaaS provider at all, let alone a good one. Not using XaaS says nothing about convictions. I find this sort of fanatical idealism a put off, and it’s interesting to me that people in the tech space moving to SaaS fail to realize that ‘Service’ is only new and special in the context of software. Humans have been running service business for hundreds of years. Do you think that telephone companies, electric utilities, cable TV companies, etc. only use services to run their business? No, of course not. There are many good reasons and cases to use XaaS suppliers to support your own SaaS business (EC2, etc.) and in other cases, you may need/want to run your own infrastructure. Currently, there is no clear cut rule or guide forcing one way or the other. The fact of the matter is , you can be a GREAT SaaS provider and run in a co-located space, in your own datacenter, on EC2, or whatever else you deem appropriate. What matters is the quality of service and the quality of the software.

Do you agree with the statement that a SaaS provider needs to be using IaaS/PaaS to be taken seriously, or do you feel that it’s OK for a SaaS provider to leverage non “XaaS” approaches?

Well, it wasn’t all for naught!

I’m writing this post to announce a new round of funding with one of the industry’s leading venture capital firms, NEA. For anyone in the space, you may be well aware of NEA’s track record, and particularly its interest in backing infrastructure software plays like SaaSGrid. We’re thrilled to have them on board! In tough economic times, it’s even more exciting to get such a passionate vote of confidence in the team and product.

To date, we’ve been very successful at growing as a company, acquiring customers, and delivering our message but this round of funding adds the right amount of fuel to catapult Apprenda into a new phase of growth and success. Through this round, we will continue to revolutionize SaaS technology, work with new markets, and solve more problems than we ever have.

I want to thank all SaaSBlogs readers to date; my conversations on SaaSBlogs (and outside) play to my passion of SaaS, added motivation to our success so far, and will continue to be instrumental in the evolution of SaaSGrid and our market story.

First, let’s look at multi-tenancy at it’s core. What we’re really saying is that we want each customer to feel as if they have their own application instance regardless of what instance orientation is being used (single instance, multi-instance, etc.) Let’s look at the holy grail of single instance, multi-tenant. What we’re really saying is that generally (this doesn’t fit all applications, but most):

1. Customers needs to login to some *shared* frontend.
2. Customers execute business logic on *shared* compute resources
3. Customers store/get data from a *shared* data stores
4. Customers use auxilliary systems to manage their presence with the service

Is multi-tenancy just a database issue? I hope at this point some level of obviousness has become part of the equation. Multi-tenancy means that you architect your front-end to fit the instance flavor you’ve chosen (in our case, single instance) so that UIs can segregate provisioning and UI rendering. Second, services layers need to execute against data for the correct customer in a safe fashion (so one customer doesn’t clobber another customer), which means we need execution isolation from a tenancy perspective. Next, data needs to be stored and retrieved correctly per tenant. Last, everything from authentication systems to upgrade engines need to understand tenancy and distinguish tenants from one another.

The footprint of multi-tenancy, when done correctly, is huge on an architecture (which also means you’re not using SaaSGrid;-)) One shouldn’t trivialize it as “just an extra column on some tables” because it’s far from that, so make sure you really understand multi-tenancy before tackling it, as it’s one huge iceberg!

First, let’s chat about commodity hardware in general. First, commodity hardware enables commodity computing. The basic idea is that we’ve moved away from supercomputers, or “scale-up” systems (i.e. throw more memory, CPU, and disk at a single physical box to make it better) and to a scenario where we can “scale-out” by adding more inexpensive physical units as a solution to scale problems. Normally, this is done as a reactive measure to a mounting scale problem. We see this in everything from plain old websites to SaaS architectures. As inbound load increases, we add hardware to resource pools thereby increasing capacity, we then load balance, and voila, all better! Interestingly, infrastructure as a service (dialing up raw resources like servers on EC2) makes this even more practical as a solution. It used to be that “commodity hardware” meant real iron, but now we can deal with this virtually and in an “elastic” fashion (the ‘E’ in ‘EC2′) We’ll categorize this reactive commodity-based measure as naïve scale-out. I don’t mean this in the pejorative, but rather in the formal sense; systematic scale-out of this type exploits coarse grained application level allocation and “bolts on” new capacity with the notion that any new capacity be only minimally aware (if at all) of the “old capacity” and the scale problem it is actually solving, hence the word naïve. Assuming that dynamic scale out needs are real enough to justify using cloud hardware (e.g. EC2, GoGrid), then we have an amazing tool to solve our problems.

Naïve commodity scale-out is amazingly powerful and has catalyzed web-scale operations, but is it the “end all” solution? Not even close. Commodity hardware, at least for most of computing, has allowed us to “back into” older software like RDBMS, traditional application servers (e.g. IIS, JBoss) and build certain types of software architectures in response to scale-problems. Realistically, however, it’s not terribly innovative on its own. What I find most intriguing is the “what’s next” discussion. If we look at the past few years, we should have good indication of what commodity hardware, and more specifically, commodity hardware in the cloud, is allowing us to do.

Let’s use Amazon as a focal point (for no particular reason other than they exemplify where some of the change is headed) When we first think of Amazon, we think of infrastructure as a service: raw servers via, EC2 and web scale storage via S3. But now, Amazon is starting to evolve. Recently, they announced Elastic Map Reduce, which is essentially a step up the stack to the algorithm layer made possible by the mass parallelization offered by commodity cloud hardware. In my opinion, we’re going to see a revolution where “the cloud” will no longer mean boring servers that can be “fired up” on command, but rather a whole array of tools like Elastic Map Reduce that are the software layers that expose commodity hardware’s real value. We even see this with our beloved SaaSGrid - rather than being a traditional “single server” or “single cluster” application server, SaaSGrid establishes a “fabric” across arrays of servers (commodity) and creates a unified hosting layer, allowing the applications it hosts to trivially leverage an expanse of servers. This is a great thing to see, given that the complexity of engineering software to actually leverage commodity hardware layers is a difficult thing to do correctly, and will open the door to a host of SaaS applications that weren’t physically or economically possible before.

Let’s use the U.S. government as a discussion point. In 2005, the federal government was a sprawling institution of 3.3 million civil servant and military personnel with 10 million other works that were direct government contracts and “grant workers,” for a total direct and indirect workforce of 14.6 million people! Clearly, we haven’t included state and local government in this mix, but I think you get the picture; the numbers are staggering. These millions of employees leverage software every day. For many scenarios, generally available SaaS offerings like Salesforce.com will fill many needs, but the government ecosystem also requires a massive number of niche applications to help in very specific tasks. For example, consider managing parking tickets or traffic violations. Generally speaking, custom software would be used for this task. The internal market for niche applications is just as staggering as the raw employment numbers.

So how does SaaS play into all of this? Let’s consider much of internal government IT functions at this point. If some municipality needs a software package to manage traffic violations, it either (a) writes it or (b) contracts a consultant to write it and then runs that software on some server it owns or leases. The municipality next door has a similar need and pursues a similar path. You can extrapolate this process to many different municipalities, each with their own on-premises solution. The fact of the matter is, many will have the same or extraordinarily similar requirements when it comes to their traffic violation systems. What you end up with is a generally unnecessary gross over allocation of resources. Each municipality is maintaining infrastructure and code on its own, resulting in pressure on the IT budget, inefficiency in terms of delivery and maintenance, and general headaches.

These niche applications are completly warranted in terms of functional need, but can SaaS help with the delivery and save the government time, money and effort? Absolutely! SaaS is often overlooked as an intra-enterprise (i.e. private cloud) deployment model. For example, considering the common functional overlap for our traffic violation app, as well as the lack of strategic value associated with hosting the app themselves, municipalities would benefit from “banding together” or relying on a super-scope governmental body (think the county or state governments in the U.S.) and having the application written once and delivered as a service to each municipality. Furthermore, this model could be extrapolated to a number of applications, allowing the centralized management and delivery of applications, as well as governmental standardization. This would create huge savings for the government, allow for an unbelievably flexible sharing and deployment model, and get rid of waste.  I’m excited to see SaaS architectures materialize within organizations as a viable model that changes the way these organizations write and consumer internal software.

What’s your opinion? Is SaaS only beneficial to the government from a consumption point of view, or is the
idea of leveraging the delivery model on a “private cloud” for internal applications equally (if not more) powerful?

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

Recently, Bob Warfield over at Smoothspan wrote a couple of excellent multi-tenancy oriented posts. In one of those posts, Warfield drilled into the Salesforce.com numbers I mentioned earlier in an attempt to quantify the impact of their architecture on cost of service. Warfield gave some analysis around multi-tenancy on the overall cost of service incurred by salesforce.com. Looking at the salesforce.com annual report, it’s apparent that it costs salesforce.com $0.12-$0.13 per $1.00 of revenue to deliver its service for a total of $127 million for the year on roughly $1 billion in subscription revenue. Warfield identified that if they’re running 1,000 servers, we can use Amazon pricing as a roughshod estimate of what the actual servers would cost them if they were running on the Amazon cloud: about $4.7 million per year. That leaves about $122 million unaccounted for! As Warfield pointed out, clearly there are lots of other expenses. It’s most likely that these expenses are due to lack of automation and overabundance of personnel due to said lack of automation. To a degree, this means that multi-tenancy is doing its job: the software’s architecture and resource utilization is but a fraction of total cost of service.

To understand this better, let’s use Warfield’s numbers and recast the scenario with the question “What if Salesforce.com weren’t multi-tenant?” Currently, we know that about 55 customers are supported per server. Many propose virtualization as a route to multi-tenancy since it’s so easy to fire up an instance on say, EC2, and create a 1-1 affinity for a customer to a server. If we imagine Salesforce.com to use this architecture instead, one where virtualization is used instead of a multi-tenant approach, we get a drastically different picture. I won’t calculate the EC2 costs, but instead will use Warfield’s numbers: one EC2 instance costs about $4,700 per year ($4.7 million/1,000 instances). If we dedicated a single instance to each customer (that’s 55,000 instances based on Salesforce.com’s number of customers), it would cost Salesforce.com $258 million! Let’s be generous and give it a 2:1 leverage (maybe there is some server sharing) and cut the instances in half, we’re still pushing $129 million. Assuming that this virtualized approach got rid of all internal staff and expenses at Salesforce.com related to cost of service, we’d have to hit that 2:1 leverage to even be competitive with their current cost structure. More than likely, taking a virtualized approach wouldn’t entirely get rid of Salesforce.com’s “out of architecture” expenses since I’m pretty confident that not ALL of the remaining $122 million is dedicated to simply running their 1,000 servers, but some big chunk is. Even if a virtualized or in the cloud approach had a 2:1 leverage and slashed 75%  of the $122 million, Salesforce.com still wouldn’t have the cost profile they do now.

Point? It seems multi-tenancy at $4.7 million worth of hardware/software resources has a big something to do with the overall cost profile. As Warfield pointed out, something else is making up a brunt of the cost, but the architecture approach certainly seems to have depressed it’s part of the cost to something reasonable. Now, how about a multi-tenant architecture on EC2? I’d love to see some cost specifics in the wild on this sort of arrangement!

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

The conversation has been interesting to follow because it seems that the common theme everyone (including myself) wants to address is the cost effectiveness related to multi-tenancy. In one camp, there are those of us who argue that in many delivery scenarios, multi-tenancy has a drastic impact on delivery costs (even in light of modern virtualization techniques) and in the other camp, folks feel that the cost advantages are overblown/non-existent: merely a manifestation of ‘green crystals marketing.’ If you didn’t gather from the last sentence, I’m firmly in the camp that believes (I’ll go out on a limb and even say knows) that multi-tenancy can have huge relative effects on cost of delivery. I won’t dive into the cost effectiveness (since I’ve touched on this in the past), but instead, focus on a different discussion: the positive impact of multi-tenancy beyond cost, and why other 1-to-many architectures don’t make sense for SaaS.

First, let’s lay some groundwork. SaaS itself is more than just “cheaper software,” but in fact SaaS has a certain number tenets associated with it. SaaS is important because aside from helping drive TCO down for the end customer, it introduces the notions of ubiquitous access, collaborative use of data and function, and rapid adoption of newly introduced value (if your SaaS provider adds new bells and whistles, you just get them. No installs, no updates, etc.) Arguably, the TCO properties will bear less of the ”burden of proof” over time, since most line of business apps will converge to SaaS; TCO won’t differentiate one SaaS offering from another since they’ll all be saying the same thing, but the value that each delivers on the other SaaS tenets I just rattled off. The real question then becomes: does a multi-tenant architecture positively impact an application outside of TCO and does it provide an increase in net value to the end user? The answer is most assuredly yes! Let’s understand why.

When you hear the word “native” with respect to architectures, it usually means that the software architecture has ingrained artifacts of an architectural style. When we say multi-tenancy, it means that the software architecture is built to natively understand (and cope with) multiple constituents accessing shared volatile and non-volatile compute resources, maintaining virtual segregation and isolation despite said sharing. There are two big takeaways from this:

1.       Generally speaking, multi-tenancy is captured in an abstract, foundational way within these sorts of architectures so that anything written on/above this part of the stack is inherently multi-tenant. We’ll coin the phrase ‘functional tenancy projection’ at this point. A ‘functional tenancy projection’ is the notion that any new function or dataset defined in a properly architecture multi-tenant system is trivially multi-tenant. This is true from everything from application code to ‘system code’ that helps manage and maintain the operations of the application. I’ve briefly discussed the before, but this is possible because of the notion of cross-cutting concerns.

2.       A multi-tenant architecture, by virtue of natively isolating and segregating tenants from one another within a common application and resource set, may trivially de-segregate those tenants. So what, you ask? Because of collaboration! Well architected multi-tenant offerings can trivially allow for tenants to function in ‘de-segregated’ groups, thereby sharing data and function. The ISVs creativity would be the only thing limiting the amount of value that can be delivered to the end customer via collaborative function.

These two takeaways make multi-tenant systems *very* different from virtualized single tenant architectures. When someone makes references to SaaS via virtualized single instance architectures, they indicate that each customer is maintained in a completely isolated virtual container, rather than sharing resources.  In other words, the application doesn’t capture tenancy, but instead the infrastructure does. Traditionally, this was a cumbersome proposition because it meant that IT had to fire up a server per customer, so there was a clear advantage to a multi-tenant architecture since everything from provisioning a customer to updating code was trivialized. With the advent of virtualization, this was no longer the case. A customer instance could be spun up virtually (and trivially), updates were easier, etc. Essentially, with virtualization, one can build a multi-tenant “exoskeleton” that routes requests and mechanizes maintenance processes, so the “virtualize it all” camp has some merit to their claim since it is starkly different than the multi-tenant vs single-tenant discussion that people had in a non-virtualized world a few years ago. The problem comes when we try to understand whether advanced form like those defined in the “two big takeaways” are possible. Unfortunately, properties like the two big takeaways simply aren’t present in a single-tenant, single instance architecture. Let’s look at each takeaway through a single-tenant lens.

1.       Adding new application logic to a single instance, virtualized architecture becomes trivially available to all customers since the multi-tenant “exoskeleton” would roll out that code to each instance. To a degree, this is equivalent to ‘functional tenancy projection’ in the application layer. But what about “systems” code? If I need to add new maintenance capabilities, can I? If I want to manage something like ubiquitous access, would that systems functionality be trivially multi-tenant? Probably not. Each addition of systems functionality is not a ‘tenant projection’ but must instead address tenancy directly. This means that it takes longer to write these parts of the application and it takes longer for customers to experience value.

2.       Since the application code knows nothing about tenancy, the idea of writing functionality that allows for collaboration on data and function becomes far less than trivial. The “exoskeleton” would have to support piping data and function between tenants, creating a cumbersome mechanism for collaborative interaction. This is what happens when something that isn’t multi-tenant wants to play in a multi-tenant world.

Granted, these are just two positive advantages of multi-tenancy, but they actually unfold into a host of other positive attributes that simply cannot be attained easily in single-tenant, virtualized architectures. Hopefully this leans some of the discussion away from cost and toward understanding the positive business impact of multi-tenancy.

For good ‘ole time’s sake, I will briefly revisit the cost question in my next post. Warfield’s discussion of the Salesforce.com 1,000 server measure was intriguing, and may help shed some light on what we really need to understand when comparing multi-tenant architecture to virtualized single-tenant approaches.

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