The Elephant in the Room – A Transition to SaaS

Mar 11, 2013 by Dave Cohn

The debate questioning why SaaS should have a multi-tenant component is one that has gone on for some time. Although strong arguments exist on both sides, I prefer to focus on an example that illustrates why, in my belief, multi-tenancy is a must-have for SaaS.

No company launches a SaaS offering and then decides they do not want to maximize profits. Economies of scale play an important role in your ability to build an efficient product and become more profitable as you scale. A great example is a leading healthcare electronic medical records (EMR) company I worked with last year. Provided below is a snapshot of the current ASP model hosted within their own data center:

Customers Hosted	1000
Instances of Application	1000
Databases Under Management	3000
Time Required for Upgrades and Patches	1000+ Hours

This company had the lofty goal of expanding from 1000 hosted customers to nearly 10,000 in 12 months. Based on their estimations, after introducing some special coding for reductions, their database footprint would expand to nearly 20,000 under management within 12 months. There also would not be enough time in the year to upgrade all of their customers, based on current timetables and processes in place.

They were at a crossroads, and needed to fundamentally change the way they do business. Keeping the status quo would become unprofitable, and continuing to host their ASP offering with a single-instance approach for each customer would ultimately become impossible. Customers wanted to rid themselves of costly infrastructure required to run their application suites on-premise, and were looking for a cloud solution.

In came Apprenda. The transition would not be easy. By introducing single-instance multi-tenancy, and some of the other great SaaS features the Apprenda platform provides, the new model for their hosted infrastructure looked like this:

Customers Hosted	1000
Instances of Application	1
Databases Under Management	3
Time Required for Upgrades and Patches	~ 10 minutes

This new scenario seems like a no-brainer. Even if they scaled to 10,000 customers by year end, the management numbers would stay constant, and would enable them to seamlessly scale their business with ease. The “elephant in the room” was the shift in the way they did business. Since all customers would now be using the same instance of the application, major customizations in code on a per-tenant basis were out the window. This is not an Apprenda by-product; this is a change, in accordance, with a true multi-tenant approach.

What we did offer was the ease to give these major customers the choice to still use a heavily customized version on-premise, or hosted at-a-premium (to compensate for management costs). Since the same code base was used both for on-premise and Apprenda, there was no need for building a new product.

Moving forward with new customers, they could offer the multi-tenant SaaS approach at lower costs and easily manage the operational and business aspects without the prior headaches. The economics of scale of the new SaaS business was astonishing in its efficiency. As they added more customers, the cost of goods sold actually decreased since they were all utilizing the same underlying infrastructure for all.

While I am sure the multi-tenancy debate will continue, this provides a real-world example of a company that could not continue to turn a profit unless they embraced multi-tenancy. In this case, a fundamental change in the way business was done was essential, moving forward.

read more

6 Reasons Why Moving to SaaS Is Harder Than You Think

Jan 17, 2013 by Dave Cohn

Over the past few years of working with hundreds of ISVs around the world, I feel I have been privy to inside information from many leading companies and future market challengers. I have learned about the strategies and ambitions of many software vendors; where they are today and where they want to be tomorrow. One variable that tends to be common from vendor to vendor includes defining an end goal of SaaS. The true meaning of SaaS or Software-as-a-Service is as subjective a term as cloud. Ask ten different vendors how they define SaaS and you will most likely receive ten different definitions.

The truth though is SaaS is all or nothing.

To become a nimble, flexible, and competitive SaaS vendor requires major changes in the way your customers consume your application(s). Consumers are becoming more and more inclined to use software as an on-demand offering because the market is pushing them in that direction. Ridding themselves of the costly infrastructure and specialists required to run software is a big driver and on the mind of many decision-makers, including CFO’s. Like it or not, more and more of your customers will and are looking for a SaaS offering. If it is not from you, they will find it elsewhere.

I have been involved in conversations and strategic discussions with some of the top names in software, some of the leading enterprises and some of the future market leaders that you have never heard of yet. I do not consider myself a fortune-teller and have no crystal ball. However, I do have knowledge that I have gathered over the years regarding the transition to SaaS that I feel is valuable to share. While the transition to SaaS is valuable and necessary, the time and resources needed to build in-house is often extremely underestimated. Therefore, I have compiled the Top 6 issues that are often looked over when companies look to build SaaS in-house and broke them into the Infographic below. These 6 issues are only the tip of the iceberg. If you are interested in learning more about transitioning your software business to SaaS, I recommend you check out our whitepaper, “Making the Move to SaaS.”

 

 

 

read more

The Hijacking of PaaS: Cloud Runtimes are the Real McCoy

Nov 29, 2011 by Sinclair Schuller

Platform as a service (PaaS) has been hijacked. PaaS was supposed to be a critical bulwark in protecting cloud computing from the frail models of earlier computing eras, but to many, has become a category to dump anything that is tooling to help with some part of managing and deploying applications on cloud infrastructure. It will take some time to explain, hence the long post. I started thinking about this after reading posts by two cloud evangelists for whom I have tremendous respect and were venting their frustrations with the PaaS space – Krishnan Subramanian and Ben Kepes. Each published posts titled “AppFog Announces Java Support – What The Heck Is Happening In PaaS Space?” and “OpenLogic Announces General Availability of CloudSwing PaaS“, respectively, that delivered well-deserved jabs at the PaaS space. Why were the jabs “well deserved”? Because PaaS is littered with “me too” undifferentiated offerings that focus on “user experience” and “deploying apps”, that’s why. I’m less interested in understanding or claiming that a given vendor suffers from this, but more interested in the discussion of these issues in PaaS at broad. To understand this sentiment, we need to really spend some time to define what PaaS should be and what sort of trap the market is falling into.

To define PaaS, let’s first define an arbitrary collection of “traditional” Operating System (OS) instances on real or emulated hardware and any networking equipment associated with those OS instances as a resource pool. A PaaS’ can be best thought of as a computing platform that acts as a host to “guest” applications and that is layered atop a resource pool such that the details of individual  members of that resource pool are abstracted away and presented as a single logical layer to those guest applications. Guest applications are not privy to, bound to, or dependent on the details of components that are beneath the PaaS layer, thereby creating a rigid boundary. This abstraction reduces the amount of direct control an application has over its host environment, and in exchange, is provided certain functional guarantees and systems services. Furthermore, it could be argued that this PaaS computing platform be accessible to the developers who write guest applications in a self-service or near self-service way.  Up until this point, I think nearly anyone who considers themselves a student of cloud computing would agree. After this point, things seem to fall apart since:

• No one agrees on what PaaS should provide
• Those who do agree on what PaaS should provide tend cluster around certain functional capabilities, where the clustering *seems* (not certain of this yet) to not be motivated by ideology but by a market wide “easy win” mentality
• Hampering of creativity due to other cloud models such as IaaS distracting focus from making revolutionary progress on the more promising end game that is PaaS

The natural question anyone would have is “Sinclair, so what are the feature and functions that define PaaS beyond the systems definition you gave earlier?” I’ll do my best to provide some direction, and then circle back to the title of this post. As I described earlier, PaaS defines a layer that sits above a pool of OS/network resources, but below guest applications in such a way the details and control are abstracted away by the PaaS. As such, a corollary is that at a bare minimum, a PaaS *must* allow developers to deploy and manage applications in-spite of  the loss of control and being abstracted away from detail. This should not be looked at as a value of PaaS, but rather a requirement to achieve some level of fidelity with the pre-PaaS workflows that were part tooling, part developer manual labor, and part luck. No PaaS vendor should be proud of this achievement - it’s the scholarly equivalent of getting a ‘D’ on a test and trying to spin the fact that you barely passed as “100% success at not failing.” Granted, it’s a bit better getting a ‘D’ in that a minimally implemented PaaS at least takes the tedium of manual, time intensive, error prone application deploy and manage processes and automates them in a way that is generally flawless. Things like deploying apps and scaling apps become trivial button push operations on PaaS offerings, pushing application bits to servers and updating load balancers, among some other minor things. Nonetheless, this is not the revolutionary model that cloud computing has promised, at least that’s not what I consider “insanely great” and certainly wasn’t the model I envisioned to be world-changing when I co-founded Apprenda.

Going back to the title of this post, all PaaS’ are NOT created equal. Most “PaaS” offerings’ feature sets amount to the basics I described earlier. You see, PaaS vendors took the low friction approach of building “platforms” that merely stand up stack instances for apps being deployed through them (notice I didn’t say to them; these PaaS offerings do not act as containers to guest applications, but rather as fancy networked installers) and deal with some network component setup. In fact, some do as little as templating VMs with frameworks and stack components so that apps can be deployed with dependencies in place. This has short term sizzle, but in the long term does not provide any meaningful world changing value. What we have is a categorical skewing that sets up a market to conceptually think of something grander when they hear PaaS, only to find something less interesting.

The problem is that most generational shifts in computing were accompanied by new runtime models where the runtime or meta-runtime acts as a host to guest applications. Think OS, or application server, or even a browser’s Javascript engine. Cloud computing is typically broken up into 3 layers: SaaS, PaaS, and IaaS. PaaS was supposed to be the layer where the generational runtime model became defined for cloud computing; the layer that provides higher order intrinsic value peculiar to the new computing paradigm of cloud and resource abstraction. Some of us PaaS vendors share this vision and have started down technical strategy trajectories that define new runtime models for PaaS-based apps, while others have not. Cloud computing changes the computing model enough that to be a “platform” but not build a new runtime is likely to provide trivial value, and as a result, little differentiation among similarly tooled competitors. The lack of differentiation comes from feature convergence that is natural when systems lack a new model that can act as a spring board for differentiated value – which is exactly what a runtime provides. Subramanian and Kepes were likely identifying with this feature convergence, hence their frustration.

So why does a runtime need to exist, anyway? First, let’s level set on one thing: one of the major goals of cloud is to abstract away details of underlying resources. Period. Cloud forces an application-centric model (Thanks goes to James Urquhart for articulating this), and as such, needs to remove distractions created by irrelevant, low-level details. Much like VM-based runtime paradigms such as the JVM and CLR got rid of the need to deal with what integers were stored in what CPU registers, cloud should get rid of the need to worry about execution time details about OS’, network routing, etc. Cloud has done two things: it has raised the ceiling for potential application architecture complexity AND opened the door to new types of previously unavailable value. Without going through a formal proof of sorts, it should be obvious that a PaaS that merely pushes bits onto servers and updates load balancers is incapable of supporting the execution needs of applications that need to deal with abstract resource concepts and new levels of architecture complexity due to the nature of network-distributed resources. It would be akin to thinking that a fancy C++ library could provide pari passu value to the JVM: it simply couldn’t. As a cloud application executes, it needs an underlying active system that is doing constant heavy lifting to make magic happen, and not just waiting on the sidelines for the next app or infrastructure management event. A great PaaS will:

• Provide self-service access to developers
• Provide application management tools and capabilities
• Use a runtime model that sits underneath an application as it executes, but above the infrastructure with the intent of abstracting away non-strategic details
• Provides frameworks and APIs to access higher order value
• Manage the infrastructure in a way that shields the application from as much impact as possible

The last piece of this book-of-a-post is helping identify what a PaaS runtime looks like. An anchoring theme for a PaaS runtime is active participation in the execution of guest application code. As such, you will typically see non-trivial PaaS offerings do some number of the following things:

• Implicit participation in application messaging at various tiers of typical application architectures. Additionally, the PaaS my provide declarative or imperative control to guest applications over application messaging.
• Use “resident code” to instrument behavior into executing application code. Much like traditional runtimes forcibly load libraries into your memory space, PaaS runtimes may load code and data that co-habit your application memory space
• May use code generation to augment guest applications in a way that is orthogonal to the guest applications functions, but in alignment with the PaaS runtimes execution needs. This might be tough to understand if an example is not provided, and the only example I know of is what our Apprenda PaaS does. To simplify the example, let’s consider web services deployed to the Apprenda PaaS. REST and SOAP web services go through a compile phase when they hit our hosting containers. This compile phases adds control end points for direct P2P style communications with any instance of that SOAP or REST service, allowing the “node” to participate in direct control calls from the runtime fabric. The end result is that each node is an independent peer entity on the distributed system that is Apprenda, but is also “stitched in” to fabric behavior.
• Activate behavior autonomously based on what guest applications are doing. For example, on an application crash, detecting the actual error (where possible) and acting on it would be an example of this sort of autonomic management.
• Provide APIs and frameworks to the guest applications that trivialize access to complex architecture value. Think publish/subscribe, map/reduce, and message brokering models.
• Might influence or modify how requests and even threads behave in the application as the application executes.
• Provide general purpose APIs  for runtime services from the platform.

This list is definitely not exhaustive, but you get the picture. This the stuff that makes cloud runtimes real and interesting, and this is what differentiates some PaaS’ as being “insanely great” versus others that, while not bad, don’t provide this level of value. This is the stuff that the future is made of, and hopefully the market evolves quickly enough where Subramanian and Kepes can both agree that innovation and value abound.

read more

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

Jul 27, 2011 by Jesse Kliza

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

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

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

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

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

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

Register Here>

We hope you’ll join us!

read more

Which Part of the Public vs. Private Cloud Elephant Are You Touching?

Jun 10, 2011 by Sinclair Schuller

The private/public cloud discussion is something that has been getting lots of attention. I think one of the big issues is that different perspectives are causing people to speak differently about the same thing, and confusion around what public vs. private really is (e.g., what is a Private PaaS running on public IaaS) adds fuel to the fire. Maybe a parable can help. One of my favorite (albeit overused) parables is that of the Blind men and an elephant. The story is as follows: four blind men discover an elephant for the first time. Since they have never encountered an elephant before, they each touch a part of the elephant that they are closest to, feeling about so that they can assess what it is they are touching. One man grabs the elephants trunk, and determines that he is clearly touching a snake. Another grabs the tail, and concludes that it is a rope. The third, wrapping his arms around the leg, announces that it is clearly a tree. Last but not least, the fourth blind man runs his hands along the elephants side and determines that they have discovered a wall.

Clearly, they’re each interacting with the elephant, but are also each describing the elephant (based on their individual perspectives) in drastically different ways.

This is extremely relevant to today’s cloud computing discussion. Essentially, the problem we have is that cloud computing is our elephant, and although we are each interacting with cloud computing, we are suffering from the same problem as the four men in the parable; our “perspective blindness” causes us to only base our understanding on what we are capable of assessing, thereby failing to see cloud computing as a whole. This was extremely apparent after I wrote a post for GigaOM. Both in comments and in Twitter, I had people supporting and rejecting the notion of cloud technologies transplanted into private settings (such as deploying private IaaS or private PaaS). Some argued that public cloud provided X, and Y, and Z while private didn’t. At the end of the day, both public and private cloud can provide significant value to the various constituents in enterprise IT. To understand why private cloud might make sense to some and not others, we need to understand the relationships between the various parties in enterprise IT in the context of cloud computing:

(bigger)

Granted, the diagram doesn’t capture the finer grained details of the relationships, but it does define a framework to work off of. Each constituent in enterprise IT has a “primary” role when considering the application as the first class citizen of  the system:

1. Consumption
2. Application Development
3. Infrastructure Management

Each constituent is analogous to one of the blind men touching the elephant that is cloud computing. Let’s look at this more specifically. If you are a business end user that needs to source a certain application X, you can either a) use a solution that the developers within your organization have built on some private cloud or b) use an external SaaS provider (which apparently is  a growing trend in IT). From the business end users perspective, they don’t care if an app is running in a private cloud or public cloud, or is a custom solution coming from LOB developers within the enterprise or an external SaaS provider. They need an app for some specific business function to create value and solve problems. We can find lots of tangential reasoning as to why they should use public cloud only, but from a practical perspective, they just need to know that whatever app they are using fulfills all of their requirements (and constraints). If the app is provided by their own LOB developers and is deployed to the private cloud, that’s fine. If  they are using a public SaaS app, that’s fine too. Some apps might provide additional value in a public form factor, but it shouldn’t be the deciding factor.

Similarly, from the perspective of enterprise developers who build custom apps within the enterprise, they want to know if they can quickly and easily deploy their apps and get functionality from an underlying stack. The current IT model is broken: each dev team builds an app a different way, when it’s time to deploy, they contact IT and wait 30-60 days for a server to be provisioned, they manually configure the app, and manually deal with the app’s lifecycle using the same cumbersome approach that was used to get it up and running. Cloud (particularly PaaS)  presents a very agile model with blazing fast time to market, advanced architecture qualities, and little friction. Developers are simply looking to get past this antiquated approach; they might want to deploy to a public PaaS like Azure, but if central IT offered a private PaaS, they might prefer that because it’s less friction in terms of adoption and from their perspective, they get the same major benefits: upload and deploy apps at a button click, get scalability for free, and get other benefits like distributed caching as services. From the developer’s perspective, they’d get what they need, regardless of the form factor. It gets even more difficult parse if you consider that central IT could deploy a private PaaS to either their own private cloud, or to a public IaaS provider like EC2. Is that a public or private PaaS? Clearly, the IT team owns the Amazon account and is deploying their own PaaS layer to public infrastructure. From the developers perspective, it’s a private PaaS (as in owned by their organization), from central IT’s point of view, they are using public cloud. For me, this is a very real topological distinction since our customers can license SaaSGrid and deploy it to their own bare metal infrastructure and get a private PaaS, on their private virtualization cloud and get private PaaS, or on something like EC2 and expose a PaaS to their internal developers. We don’t necessarily care, but the lines are clearly blurry as to which is “more public”:

1. Private PaaS on Private Cloud
2. Private PaaS on Public IaaS
3. Public PaaS

Is number 2 more public or more private? This highlights the absurdity of the debate that continues to come up in nearly every public/private conversation. At the end of the day: who cares? If the end users in an organization want a specific offering provided in a SaaS fashion: great. If they use an offering built by their LOB developers and deployed to their private PaaS on their private cloud, or their private PaaS deployed on public IaaS, they’d be just as happy.

In some instance, public cloud makes the most sense, in others private cloud. Sometimes, real costs of adopting public cloud severely impact it’s ROI, so private cloud gives some of the benefits with less costs, causing private cloud ROI to be higher. In other cases, public cloud can be adopted using little friction and is the way to go. I think the sooner we recognize that the fierce debate of whether the elephant is a snake, a rope, a wall or a tree is silly, and that we should each be comfortable with the fact that our perspectives might influence or judgment, the sooner we can all focus on extracting value from cloud tech.

Do you agree that both public and private cloud are relevant? Are you passionate that cloud is public only or nothing? If so, why?

read more

Using a Bus to Frame an Understanding for Public Cloud vs. Private Cloud

Jun 6, 2011 by Sinclair Schuller

I recently wrote a piece that was published on GigaOM that uses a bus (as in vehicle) analogy to try and establish a conceptual framework for the public vs. private cloud discussion. Check it out here!

read more