Throwing Around the Term “Multi-tenancy” Isn’t Helpful: Advice to App Developers in the Cloud

Mar 14, 2011 by

Before I get started, this post IS NOT a post about why multi-tenancy is a good thing, why it’s better than virtualization, or anything of that nature. I had to get that out before starting – there are plenty of posts that deal with this topic (one, two, three, etc.). Instead, I want to tackle a different issue: the issue of what multi-tenancy means in a variety of contexts as well as how its positioning by vendors is leading to mass confusion.

No particular event has motivated this post; instead, this post is the result of a number of conversations and miscommunications. A while back, I started noticing some disturbing trends in the market, and more specifically, in vendor pitches. Let me use a real world example of what I mean. Frequently, the sales team at Apprenda ends up in the following type of conversation at some point in our sales cycle (clearly, this is distilled for brevity):

Prospect: “I saw that SaaSGrid offers multi-tenancy.”

Apprenda: “That’s right; SaaSGrid gives your application access to various types of multi-tenancy using the same code base and application assets. It’s actually amazingly unique and takes significant effort out of your R&D.”

Prospect: “Yeah, but doesn’t <insert your favorite PaaS/IaaS here> offer multi-tenancy?”  or “Well, the folks over at <insert your favorite PaaS/IaaS here> said they offer multi-tenancy too.”

Apprenda: “That’s different. Those technologies are themselves multi-tenant. SaaSGrid is a server technology that allows your single-tenant application to be multi-tenant at all application tiers without the huge effort typically associated with going multi-tenant.

Prospect: “Wait, but that’s exactly what I heard <insert your favorite PaaS/IaaS here> say. You’re saying that they don’t do the same thing as you.”

Apprenda: “Correct. Most, if not all, cloud platform vendors that refer to multi-tenancy are references to their own architectures, meaning they can efficiently pack their customers onto shared hardware/OS instances and offer you better service and a low price point. What you’re asking is how you can be multi-tenant and offer the same to your customers. Others in the cloud can’t help you with that.

Prospect: “OK, so using their service doesn’t make sense then?”

Apprenda: “That’s hard to answer, but it usually makes sense in conjunction with something like SaaSGrid. Clearly, being on something like EC2 (which is multi-tenant at the infrastructure tier) has advantages to you. Using SaaSGrid means you can really lower your internal cost of offering your service to your customers, and either put the savings to the bottom line or pass it along to your customers.”

Prospect: “What SaaSGrid does seems pretty magical now that I’ve cut through the marketing BS, how do you do it?”

Apprenda: “SaaSGrid is a runtime. When deployed to SaaSGrid, your application is transformed and new capabilities are instrumented into all tiers of your application. When running on SaaSGrid, these transformations and runtime instrumentations ‘inject’ SaaS architecture DNA into your non-SaaS web application.”

As you can see, this sort of conversation is a distraction. Whether it’s a conversation with an analyst, industry pundit, or potential customer, I’ve found that the most important thing to do upfront is to level-set on what both sides mean/understand when they say “multi-tenant.” Why so much confusion? I think it’s due to two factors:

  1. The marketing pitch offered up by vendors and how those marketing sound-bites are contexualized
  2. The general overloading of the term “multi-tenant”

On the marketing side, vendors do a good job of highlighting multi-tenancy. The problem is that the lack of context around the “feature” of multi-tenancy causes significant miscommunication. From a marketing perspective, vendors are sucked into the Green Crystals Marketing described by Bob Warfield a couple of years ago. Most cloud vendors are touting that they are multi-tenant; they want you to understand that they have a cost-effective and safe mechanism to isolate their customers from one another. To understand this better, I’ve taken the liberty to copy and paste (with references, of course) some content related to multi-tenancy from various cloud vendors:

The AppFabric Container provides base-level application infrastructure such as automatically ensuring scale out, availability, multi-tenancy and sandboxing of your application components. (Microsoft, Windows Azure)

Cloud-enabling infrastructure to allow secure multi-tenant deployments, including fully integrated management, monitoring, metering and billing infrastructure (CloudBees)

If you are running numerous applications/application instances, XAP’s fine-grained multi-tenancy allows you to share them across all available machines, instead of running only one instance per machine. This allows you to support more users on each machine. (GigaSpaces)

There a few others to use as examples, but this is fine for now. I’m not going to debate whether advertising that you are multi-tenant is an effective use of marketing real-estate. all of these snippets of text highlight multi-tenancy, but what is unclear is the context. For example, the first two indicate multi-tenancy at the platform tier; that is, multiple, unrelated code assets can share common OS instances. While this is powerful in its own right, it’s easy to understand how someone reading this text might walk away thinking “Excellent. Our requirements for our new SaaS project call for multi-tenancy. I can check that off our list.” The fact is, while ambiguous in terms of presentation, these technologies do not endow your application with multi-tenancy, they let you run in a multi-tenant environment. If you’re looking to build a multi-tenant app, you need to still architect multi-tenancy (‘architect’ is a verb according to the Oxford English Dictionary). In the gigaspaces case, although they refer to multi-tenancy in a way that lends itself to an “endowment” interpretation, it seems that they are focusing more on a grid approach of scaling the app to support more end users. While this is also valuable, it does not deal with segregation and isolation of logical groups of tenants (which is what multi-tenancy really is). At Apprenda, we even dealt with this definition in problem in our FAQ. This leads me to the next issue: term overloading.

Multi-tenancy is valid in 3 common computing contexts:

  1. Infrastructure: This is multi-tenancy the way someone like Amazon might refer to multi-tenancy on EC2. In the IaaS context, multi-tenancy means that multiple OS instances can run on the same physical hardware through hypervisor technology.
  2. Platform: PaaS multi-tenancy means that, like a Heroku or a CloudBees, the platform can isolate code from different apps/vendors on the same OS instance (usually by commingling processes and databases on OS instances). This removes the need to allocate a whole VM per application stack component, improving efficiency.
  3. Application: SaaS multi-tenancy, at least at the highest level of isolation, means that single runtime stack component instances are shared across multiple customers. For example, a single database might commingle data rows for thousands of customers while preserving isolation and performance.

Clearly, multi-tenancy means different things in all of these scenarios. There is nothing wrong with overloading, but it certainly doesn’t help the already high levels of confusion that exist around the word. If you’re an app developer in the Cloud looking to see what tech can help you, having a sense of clarity is most useful. Make sure you ask simple questions like:

  1. When you say ‘multi-tenant’, what do you mean?
  2. If multi-tenancy is a feature of your IaaS/PaaS, does that mean my app automatically becomes multi-tenant and I get to reap efficiencies from it?
  3. If I want my app to be multi-tenant on your IaaS/PaaS, will I have to still architect the app to be multi-tenant?

If you get answers of “I don’t know” or “No”, then clearly, you’re on your own if you want to build a multi-tenant SaaS app from the ground up.

Do you feel multi-tenancy is thrown around too often by the wrong parties? Is multi-tenancy confusing to you?

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

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

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

Mar 2, 2011 by

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

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

Operationally

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

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

Processing Trial Request

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

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

Provisioning Trial Account

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

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

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

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

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

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

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

Architecturally

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

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

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

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

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

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

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

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

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

Related Posts

Tags

Share This

More On Cloud Middleware

Jan 31, 2011 by

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

Related Posts

Tags

Share This

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

Jan 26, 2011 by

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

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

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

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

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

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

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

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

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

read more

Related Posts

Tags

Share This

Transforming and Deploying Software as a Service – For ISVs

Jan 12, 2011 by

For those ISV members of the SaaSBlogs community that might be interested, VMware has graciously invited us to participate in an awesome event that they have planned for January 27th. If you’re an ISV, and you’re contemplating a transition to the SaaS model, you won’t want to miss it! It’s a webinar specifically for ISVs, entitled “Transforming & Deploying Software as a Service“.

VMware is working with select partners such as Apprenda, to help ISVs deal with the specific complexities associated with Software as a Service. You’ll get a chance to learn how VMware’s virtualization technology coupled with SaaSGrid provides a foundation for delivering your software as a service. You’ll also get a chance to learn how other software companies are leveraging the SaaSGrid application server and VMware together, and achieving significant cost savings and time to market advantages over their competition.

We’re excited to be participating in the great event and we hope some of you will join us! Here’s a link to the a page with more information, the agenda and details.

EVENT DETAILS

Date: Thursday, January 27th, 2011
Time: 10:00AM PST / 1:00PM EST
Place: Online

Find out more now>>

On a similar note, I’ll personally be at VMware’s first ever ISV Summit during their Partner Exchange event next month speaking as part of a round table.  Feel free to reach out and let me know if you’ll be there and would like to meet up.

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