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

Mar 23, 2011 by

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

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

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

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

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

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

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

Cloud Ecosystem

read more

Related Posts

Tags

Share This

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

What is VMForce?

Apr 20, 2010 by

If you haven’t heard, Salesforce.com and VMWare plan on making a joint product announcement on April 27th at http://www.vmforce.com. Clearly, this piqued the curiosity of many, including myself. Thinking about Force.com, Salesforce.com’s strategy around the platform to date, and VMWare’s activity and intent to become more entrenched in the Cloud, my best guess is that it’s an Infrastructure as a Service (IaaS) offering, and maybe some sort of Spring-based framework layer that’s tightly integrated with Salesforce.com. Furthermore, it might even offer the ability to run native Force.com code/apps on top of it (I could see something like Spring being used  to create a harness of sorts to load Force.com apps on a native Java runtime)

Force.com is a high order abstraction requiring the use of a new programming language and a heavily diluted (read crippled) runtime. As a platform for extending the CRM functionality of Salesforce.com, it’s an amazing platform. As a general purpose platform for business applications, I think it’s too trivial of a runtime (anyone who’s read this blog before knows my position on this). Most mid-large ISVs solve complex problems addressable only through mature, expressive languages and complete runtimes and stacks. VMForce might be a step in the right direction – so let’s wait and see!

PS: For the literalists out there, one thing I noticed is that VMForce.com describes  it as a “product announcement” instead of “service announcement”. Maybe it’s some sort of special VMWare on-premises integration to the Salesforce.com Cloud?

What do you think VMForce is all about? Any drastically different theories?

read more

Related Posts

Tags

Share This

Do you have to leverage “X as a Service” to be a SaaS provider?

Dec 10, 2009 by

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?

read more

Related Posts

Tags

Share This

Demystifying The Cloud: Where Do SaaS, PaaS and Other Acronyms Fit In?

Dec 1, 2008 by

I’m sure we can all agree that the number of acronyms and phrases related to online software keeps growing rather than shrinking. In order to make sense of it, we really need to focus on understanding where different concepts fit in from a big picture perspective. For example, I am often asked if Apprenda’s SaaSGrid competes with Amazon’s EC2 or now with Microsoft’s Azure. For any long time readers, I wrote a taxonomy article a while back that distilled SaaS Platforms (which have materialized under the PaaS banner as of late) a bit beyond the generalized SaaS platform moniker. Similarly, I think the same is required of the current ‘cloud’ market space, although a bit more high level. Robert Anderson had a good post a little while back that distilled some of this, as did Peter Laird via a follow up to Anderson’s post. Despite the quality of these posts and and their approaches to this taxonomy problem, I think the issue requires a touch more refinement and clarity.

The reason this is important to me is because I hear a variety of cloud oriented acronyms and words tossed about with little regard to what they mean, what their relationships are to each other, and how they bring deliver value to varying market constituents. To start off, let’s rattle off a short list of things to address: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). Now, for a snapshot of definitions (and a bunch of very good links that I recommend everyone follow, despite how trivial the term may seem):

  1. Infrastructure as a Service - Traditional computing resources such as servers, storage, and other forms of low level network and hardware resources offered in  a virtual, on demand fashion over the Internet. IaaS in a general sense, provides the ability to ‘summon’ resources in specific configurations at will and delivers value similar to what one might find in a traditional datacenter. IaaS’ power lies in its massive on-the-fly flexibility and configurability. It can be equated to owning a magic wand that could conjure up a variety of network and server resources in zero time and occupying zero space. Examples include services like GoGrid, Amazon’s EC2 and even S3 ( as a storage infrastructure play)
  2. Platform as a Service (The space I play in via Apprenda’s SaaSGrid platform) - A runtime-system and application framework that presents itself as an execution environment and computing platform available over the Internet with the sole purpose of acting as a host to application software. Generally, PaaS focuses on enabling SaaS applications, so many well-expected core concepts, such as abstracting away multi-tenancy issues, are expected of any reasonable PaaS offering. Another key concept for PaaS is that it needs to run semi-arbitrary instructions. If it ain’t runnin’ code, it ain’t a platform! (Now, I’m using ‘code’ loosely here. For example, a drag and drop business process editor could be considered as living on the edge of a platform definition, but a set of marketing tools and human drive services is most definitely not a ‘SaaS Platform’) This beyond the definitions offered in some of the aforementioned articles that PaaS deals with scale issues. Examples include SaaSGrid and Google AppEngine.  There are also some higher level PaaS offerings with non-traditional IDEs and coding paradigms like Bungee or Force.com that require (IMHO, unnecessarily) new knowledge, skills, and component frameworks.
  3. Software as a Service – Specialized software functionality delivered over the Internet to users who intend to use the set of delivered functionality to augment or replace real world processes. Generally speaking, users within the SaaS space are aggregated into ‘tenants’, or bodies of 1 or more categorically related users. Think Salesforce.com CRM, or SugarCRM.

So we’ve got these simple definitions out of the way, and in isolation they make sense, but how do they relate to one another and who cares about each? Diagram time!

Triangles and people, of course
(bigger)

We can definitely take a stack approach to this relationship; IaaS offerings can create a foundation for PaaS offerings, and PaaS offerings can do the same for SaaS offerings. Now, notice the curved arrows to the left of the triangle diagram? That identifies the lack of a tight coupling: SaaS offerings can be hosted through a PaaS, or can hop-scotch PaaS and build a delivery architecture on top of raw IaaS. Furthermore, IaaS can be replaced with raw metal (traditional infrastructure) by both PaaS and SaaS layers that might directly depend on it. This hop-scotching can lead to confusion about the competitive nature of offerings across these buckets (I’ll discuss that later). Another thing to note in the diagram is the use of ‘people’ icons which identify which constituents actually care about which part of the stack (clearly, all care about all parts, but some are more directly affected than others – and more importantly, some constituents jobs are defined by their usage and even expertise in a particular piece of the stack). SaaS tends to cater to end users looking to satisfy some business, general process or even recreational need. PaaS, however, primarily interfaces with application developers and software companies, providing them the tools and run time to quickly build SaaS offerings, while IaaS tends to focus on identifying value to network planners that need to organize specific, lower level resources in support of PaaS or SaaS offerings. These are the ideal constituents in the value stack. However, I frequently bump into cross talk, which is something that needs to be addressed.

So do PaaS offerings compete with IaaS offerings (i.e. can a SaaS offering be built without using a PaaS offering). As I described earlier, the answer is yes but with a dash of hesitation for good measure. When I’m asked the question (or on occassion, told that this is fact) “Does SaaSGrid compete with EC2?”, I always pause and search for a good way of describing the relationship. Essentially, we (Apprenda) can utilize an IaaS to deploy our SaaS platform as a PaaS offering, so in one respect, it’s a resource for us. On the other hand, someone can build scaffolding around an IaaS offering and create a SaaS offering. For example, you might cut a new server image on EC2 for each customer your provision to your new SaaS offering, and route subdomains to those images, and integrate it with some sort of authentication framework, and wrap all of this in some sort of billing and payments engine taking a Papier-mâché and duct tape approach to your offering.  OR, you can deploy it on top of a specialized layer like SaaSGrid (PaaS) that is built to deal with SaaS problems and requirements out of the box. So are they competitive? IaaS offers some semblance of a solution, but requires significant overhead compared to PaaS value propositions and is not built to inherently solve SaaS problems. My answer is definitely not. It’s like saying hard drive manufacturers are competitive with relational databases; when writing an application, you can choose to write straight to disk instead of a relational database (which depends on non-volatile storage like hard drives). However, you lose all of the benefit of the specialization presented by a database like indexing, query languages, searching and aggregation, backup functionality, etc. Generally, you’ll start asking questions like: how can I quickly access and search data I saved directly to disk? Oh, just download a library that indexes the data! What about a structured way to change search criteria? Easy, just create a domain specific language to search the data on disk. Sounds like someone is putting together a  Papier-mâché database ontop of straight disk access… Is writing straight to disk sometimes warranted? Absolutely. Most of the time, however, its that someone made the mistake of pitting hard drives against databases when they solve very different problems.

There are some blurry lines like Microsoft Azure, where they neatly span parts of IaaS and PaaS, but don’t offer a pure solution for either. For example, Azure doesn’t solve a majority of SaaS problems like tenancy in your architecture, customization, or business process issues like billing or migrating customers to a new version of code. Similar to the SaaSGrid to EC2 relationship but not as clear cut, something like SaaSGrid can utilize Azure for certain deployment needs reducing the notion of any competitiveness.

Do you find this articles categorization accurate? Do you feel that IaaS offers a valid substitute to PaaS for those writing software as a service offerings?

read more

Related Posts

Tags

Share This