SaaSGrid Is Here!

Dec 2, 2008 by Sinclair Schuller

I wanted to drop a quick note to everyone that today we’ve announced SaaSGrid’s public release. I wanted to thank everyone that is part of the SaaSBlogs community. I’ve had lots of interesting conversations (both online and offline) with readers. Many of those conversations directly have affected how we approached SaaSGrid as a technology and business solution, so again, thank you! I hope to continue to share conversations with everyone here.

As for SaaSGrid, it’s been a long R&D journey and we’re ecstatic to have reached today’s release. For anyone unfamiliar with SaaSGrid, it’s a cloud operating system (literally) that makes writing and commercializing SaaS offerings with Microsoft .NET very easy. It removes quite a few headaches from the architecture and engineering perspective, and provides a tightly woven business services layer for managing operational and customer facing aspects of your business. So, if you’re building a SaaS offering and are planning (or looking for a reason to) to use a .NET based language and stack, look no further!

We do a few interesting things from the business model perspective. Apprenda does not host applications for software companies. Instead, we enable existing hosters to offer independent cloud instances of SaaSGrid. This means that you can write an app and leverage SaaSGrid, but get to choose which Cloud Provider to publish your application to. You basically write code in Visual Studio in a single-tenant fashion, use our API for certain SaaS related duties, upload your app (UI, web services, database schema) to a SaaSGrid cloud of your choice, click a couple of buttons through a control panel and you’re up and running with a true multi-tenant, ready to accept money SaaS offering! There isn’t anything else out there that affords this sort of power and flexibility.

If you have any questions or comments, definitely leave them and I’ll be sure to answer (or if you prefer, reach out to us through the site or e-mail me directly: sschuller-at-apprenda.com)!

read more

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

Dec 1, 2008 by Sinclair Schuller

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!

(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

How Important Is “Non Intrusiveness” in a PaaS Offering?

Sep 12, 2008 by Sinclair Schuller

I recently had the pleasure of showing a demo of SaaSGrid to Eugenio Pace at Microsoft (who had some nice things to say about SaaSGrid in his latest article “Northwind Hosting exists, it’s better than what you saw and it’s called SaaSGrid“) A side conversation we had during the demo was the impact of PaaS on an ISVs application structure, code base, and business processes. We did agree on something very important: that a SaaS platform should do as much as possible for the ISV with as little impact on the application it hosts.

In my opinion, non-intrusiveness is core to net total value delivered. A PaaS offering’s net value should be measured by it’s total value minus any penalty associated with intrusiveness. For example, a PaaS offering might save you 8 months worth of engineering time, but if it requires your engineering team to learn a new programming language and technology stack, use an impactful and unfamiliar programming model, restrict your deployment capabilities, and hamper your business processes, you may have wiped the 8 months worth of savings away! Clearly, there are some cases where a move to a new language, development paradigm, etc. is warranted (if that weren’t the case we would have never moved from Assembly to C#), but we are not at one of those cut-points. Interestingly, modern technology allows us to do things like “endow” an application with SaaS with very little intrusiveness whereas in the past, this may have required a new stack.

In your opinion, when is a new programming language, technology stack, etc. warranted (i.e. what’s the value threshold for deciding to leap into a super-intrusive stack)?

read more

What PaaS Should Learn from the August 2003 Blackouts

Apr 15, 2008 by Sinclair Schuller

We’re in an interesting transition within the software space. Specifically, we’re all in agreement that SaaS is changing the industry in a very positive way. More importantly, however, is the recent evolution of platform as a service (PaaS), which is where Apprenda lives. Recently, we’ve seen more and more noise around PaaS (both consumer and enterprise PaaS offerings) with players such as Google via their AppEngine, Salesforce via Force.com and Amazon via EC2 introducing PaaS flavors at different levels in the PaaS taxonomy. As I’ve mentioned on other occassions, I enjoy looking at the histories of other industries and looking for lessons. One analogous situation that is chock full of lessons is the business of electricity, it’s generation and it’s distribution.

Now that more companies are throwing their hats into the PaaS arena, I’m keeping an eye on what could become a disturbing scenario. Greg Matter from Sun Microsystems wrote a blog post about a year and a half ago where he stated that “…there will be, more or less, five hyperscale, pan-global broadband computing services giants.” For the most part, this is an ok scenario at a specific layer – the delivery platform layer. Disturbingly, what we’re seeing is that some of the major players like Google and Amazon are approaching the market in a monolithic stack fashion. That is, even though their PaaS offerings are in their infancy, they seem to be adamant at controlling all aspects of the PaaS stack. AppEngine creates a set of libraries, which sits on a service delivery layer sitting atop of Google’s compute resources. Force.com creates a library and language layer, which sits atop a delivery platform, which sits atop compute resources. What I’m seeing is a disturbing trend that as an industry we should avoid. Let’s take a page from the history (and future) of the electric industry.

Transmission of electricity and power in the United States has faced two major outages; one in the 1970′s in New York City and another in 2003 that affected a majority of the Northeast. In the U.S., electricity generation and distribution are separated from transmission, thus creating functional decentralization. However, generation and distribution is highly centralized. The problem with this is that it creates large single points of failure with significant, non localized downside in the event of malfunction, is conducive to congestion, and unmanageable complexity. Now, some of these problems predominantly affect efficiencies (such as being too complex) while others affect customers (single point of failure) in near catastrophic ways. Both the blackout of the 70′s and of 2003 were costly and devastating, bringing parts of the U.S. to a veritable halt.

In 2003, I was working in Manhattan during the blackout and ended up having to walk across the Brooklyn Bridge in what almost seemed to be a pre-apocalyptic scene from a movie. This was a direct result of a poorly designed system that outgrew itself and couldn’t scale well because the centralized nature of the grid. As a result of these issues, many have suggested introducing decentralization to America’s power systems: individuals such as Al Gore have made it a key point to create a decentralized “electranet” while action groups such as the Union of Concerned Scientists have pointed to decentralization as necessary and critical to insure reliable power. We created a system that did not anticipate our massive energy needs and that unecessarily coupled at strategic layers. Now we have to do significant work to try and correct errors and prevent the cost of failure that is growing superlinearly with our growth in consumption. A majority of proposed corrections have to do with breaking a part a monolithic electric grid stack into manageable layers. Notably, this partitioning may even help create a scenario that is much more free trade friendly and more efficient: the notion that somehow this monolithic approach created some sort of benefit through tight coupling and specialization is absurd.

PaaS and SaaS (which in the future will all most likely be hosted via one platform or another) create a producer -> distributor -> consumer scenario familiar to those in electric power distribution. From my perspective, the idea that PaaS providers want to establish monolithic stacks is akin to the centralization of power generation and distribution, which comes with all the associated downside and ris. From the top down, most complete PaaS offerings will come with an API/service integration layer, a service delivery platform (SDP) layer, and a compute layer. But are these layers unnecessarily coupled?

When looked at it from the strictest sense, APIs and the underlying platform establish a well known functional contract between the application and the SDP. If a software company looking at a PaaS offering agrees to that functional contract and can extract all functionality they need from the PaaS, they commit to the PaaS at that level. Once built, applications are deployed, managed and operated through the PaaS. Service contracts exist between the SDP layer and the compute resources that the SDP lives on. This is an ongoing relationship that carries  good level of risk not measurable by commitment to the PaaS at the functional contract level. Once up and running, the opaque nature of the compute resources from the applications perspective creates a scenario where the application and its creator have little control and recourse.

A PaaS provider may start off giving you exceptional service, but over the course of a few years, performance degrades drastically. This degradation tends to occur at the compute resource layer or at the linkage between the SDP and compute resources layer. You’ve committed to the API and SDP, making it difficult to decouple. Worse yet, being on a monolithic PaaS stack, you can’t alleviate the degradation in service contract since the provider is one and the same in an exclusive relationship where by virtue of agreeing to the functional contract, you’ve agreed to the service contract both current and future. This is the same ridiculous architecture we’ve inherited in power generation and distribution. If Greg Matter is correct and things shakeout to 5 (more or less) PaaS providers, I sure hope it’s not 5 monolithic stacks. I’d hate to see the results of the first blackout. My goal is to push toward a much more resilient mechanism for PaaS, avoiding the pitfalls that come with gross centralization that is present in purely monolithic stacks. Yes, some might say “But company X would NEVER fail us” – I’m sure people also said “Our electric grid will never go down” and “Enron is too big to go out of business.” History is the world’s teacher, and if we’re wise, we’ll be attentive students.

Do you feel that it will be ok to function atop a few monolithic stacks, or should the PaaS focus be on decentralized PaaS mechanisms? What are your predictions for the future of SaaS and PaaS?

read more

Should You Scale-proof SaaS Offerings Early?

Dec 7, 2007 by Sinclair Schuller

A SaaSBlogs reader recently sent me a link to an article by Dharmesh Shah over at OnStartups. In a nutshell, the post articulated that building a highly scalable architecture when creating a new application is premature and creates a large resource tax on a startup’s already limited resources. This led to a vibrant thread of comments with people arguing both sides, but one comment by Dharmesh really stood out (and surprisingly wasn’t even acknowledged in the remaining comments) was the following:

“One point I didn’t make in the article, but probably should have: When making tradeoffs regarding scalability, you are at some level incurring technology debt. Debt is not always a bad thing — it can often help you grow. The key is to make sure that the “interest rate” on the debt does not outweigh the benefit of the tradeoff. So, if making a scalability tradeoff will likely cause you to rewrite the entire system, it’s probably not worth it. But, if it’s simply a matter of “Pay X now or 1.2X later”, it might be better in some cases to just pay 1.2 X later”.”

This comment provides sound rationale to the “should I scale-proof my offering early” question. From the standpoint of an entrepreneur, don’t waste your resources if scaling is not your core business (because some products have that as a core function) or if the cost massively outweighs the benefit since your immediate goals should include getting your first (or fifth, or tenth) customer, not worrying about your one-thousandth. That said, if you can scale proof your application at a low cost and avoid incurring technology debt, it’s generally wise to do so. Looking at the boundary cases, it becomes obvious. I offer you two choices: you can engineer your application for a cost of x and not be able to handle reasonably large scale or spend 1.02x and be able to deal with really large scale if and when it comes. Generally, you’ll choose 1.02x since the cost is negligible and the risk mitigation is high (this is why we pay for health, auto or any other insurance). Conversely, if I told you that the cost was x but that engineering for scale would be 1.2x or worse (say even 2x) you would most likely opt out and rightly so. After all, imagine that auto insurance personally cost you the amount of a car each year, you’d likely do everything possible to avoid getting it (granted, there are intricacies such as personal injury, etc. but work with me here! These non-tangible intricacies even exist in software – it’s one thing if you’re app doesn’t scale and you can’t take on new customers, but what if it grinds operations to a halt long enough that you lose existing customers or reduces the stability of the application to zero)

The goal of SaaSGrid, aside from providing an execution runtime and business services for SaaS offerings, is to allow for scale-proofing a SaaS offering at a negligible cost, biasing the cost/benefit analysis highlighted by Dharmesh toward choosing to scale rather than opting to incur debt. We strive to push for that trivial case of making the choice “obvious.”

If you’ve participated in building a SaaS offering, did you deal with the scale question early or late and how did your experience turn out? Have you ever had a “windfall”, a rare but possible scenario where you don’t experience organic growth but rather experience a large fluctuation in customer traffic due to some event?

 

read more

The Not So Obvious Advantages of a SaaS Platform

Oct 29, 2007 by Sinclair Schuller

I’ve written about many of the obvious advantages of a SaaS platform before: harnessing a platform to reduce implementation time, cost of implementation and/or transition (for you ISVs with existing product lines), reduction in operational costs, and the list goes on. But what about not so obvious advantages? After some fruitful discussion with individuals at various organizations, I’ve identified some not so obvious advantages to building your next offering atop a SaaS platform (where the SaaS platform encapsulates a delivery, execution, and business services stack):

1. Cross Team Knowledge: In larger ISVs and corporations, multiple teams develop products in parallel and many times inadvertently duplicate efforts and functionality if good communications don’t exist between teams. If an ISV is pursuing multiple SaaS offerings across teams, standardizing on a SaaS platform (in-house or otherwise) creates common, transferable knowledge across teams. This creates baseline knowledge compatibility and teams can be useful to each other as they learn to exploit various parts of the platforms functionality.
2. Long Term Flexibility: Having a true SaaS platform as a foundation for a SaaS offerings creates a level of natural decoupling between the SaaS delivery stack and the products built on it. This allows for future products to be built atop the delivery platform since the platform tends toward abstraction rather than specialization. As a result, the flexibility of reusing the delivery mechanisms becomes a reality. In situations where the delivery stack and service are fused together, it becomes very difficult to use just the delivery platform. Far too often, the delivery stack was designed to fit the specific needs of the offering.
3. Independent Evolution: When infrastructure or non-strategic software is baked into a product, it takes an evolutionary back seat to strategic code that directly affects the value proposition of the offering. As a result, that part of the product never evolves, and new efficiencies end up being lost opportunities. Utilizing a decoupled platform allows for a powerful stack to evolve independently of the business functionality it hosts. This creates a powerful mutualism between the host and hosted software. What’s even more interesting is that using a third party rather than in-house platform can balloon this benefit since the platform evolves with wide and varied community input rather than in isolation.
4. Insulation via Isolation: Isolating delivery platform from product code creates an insulative (warning: insulative is a made up word) effect allowing for some degree of code portability as well as project creep safety. Having a baked in delivery stack results in a higher yield of bugs creeping up from the stack or down from the product, making quality control more difficult than necessary.

I’m sure that there are many more non-obvious benefits (I can think of a few more, but I think you get the point). Given these as well as the obvious benefits, it seems natural that over time the prevailing implementation choice would be to decouple the delivery stack from the strategic code, much like application and web servers did in the past. Do you agree or disagree? Has anyone experienced negative side-effects of baking the delivery and execution stack directly into the product? Feel free to comment!

 

read more