“What it Takes to be a SaaS Provider” – an interview with Mike Seckler

Dec 29, 2008 by

Below is a link to an interview conducted by Phil Wainewright with Mike Seckler, co-founder of Employease and Apprenda board member.  In the interview, Phil and Mike highlight some of the considerations and obstacles that ISVs must tackle to be truly successful.  The 8-minute podcast is well worth a listen for new ISVs and SaaS veterans alike.

“What it Takes to be a SaaS Provider”

Please post comments and let’s start discussions around any topic or point made during the podcast that you’d like to elaborate upon.

read more

What’s in a SaaS Version Release, Anyway?

Dec 22, 2008 by

One topic that is rarely addressed on blogs or in conversation is release management: the processes and science behind rolling out a new version of your SaaS offering. So imagine you’ve created the world’s next Salesforce.com: how do you plan on handling new releases? This question is stickier than it seems. There are a variety of operational decisions to make. At a minimum, you should ask yourself:

  1. How often to I plan on releasing? Most companies I’ve spoken to about this have indicated monthly or bi-monthly (every two months, not twice a month) releases for bug fixes and basic functionality introducton, and larger scale “version releases” yearly. The decision of “how often” should be driven by a combination of customer needs and expectations coupled with feasibility. For example, if you are in the awkward position of managing an offering with features that have long development cycles (3-4 months), then don’t try and cram things into a single month simply to be on the monthly release bandwagon.
  2. Do I offer a ‘preview release’? It isn’t uncommon to offer a subset of your customers (particularly the early adopter type) a sneak peek of a new version or giving them a pre-official release upgrade. This keeps early adopter customers happy and gives you the opportunity to get some critical feedback on your new features, but does introduce some logistics around multi-version support (see question #3).
  3. Do I support multiple versions? This is a religious war in SaaS world. Some folks are adamant about one version and one version only, while others see it as critical to proper customer management. On one hand, supporting only a single version (i.e. migrating all customers to a new application version once released) simplifies a variety of tangential topics like support. On the other hand, single version releases may not play well with real world dynamics. For example, on a major release, large clients may request that they delay upgrading for a month or two with exposure to a “sandbox” upgrade of the new version, allowing them to train staff on new functionality prior to making that new version part of modus operandi.
  4. Do I need a parallel release environment? Now that you’ve got 1-3 answered, how do you plan on actually cutting a new release? Are you going to maintain dual, matching environments and “cut over” or are you aiming at a patching mechanism that can physically roll out new bits over the old ones with rollback capabilities, or even trickier, will your versioning be meta driven allowing you to match customers to the appropriate version bits and coordinate this on a release management engine? Each of these approaches has different cost, risk, and implementation difficulty implications.

The questions I’ve posed are a small part of the many decisions to make during your release management planning. Other parts of defining a release strategy aren’t options, but required. For example, little things like when you migrate your customers to new bits, you should migrate their contracts in lock step. What does this mean? Well, if you’ve added functionality that you’re bundling for free in a subscription or have removed functionality from the application and are currently charging customers for that now removed functionality, update their contracts so they get the free stuff or so they are no longer paying for things that don’t exist! Little things like this are key to ensuring customer satisfaction and a hiccup-free release.

One last tip is automate! Look to automate this process in a way that is flexible but that keeps mistake-prone human hands out of the equation. This will be critical, regardless of what decisions you make above.

How do you feel about multiple versions? What tips do you have from the real world for ISVs planning a release management system for their SaaS offering? Have you encountered any unexpected headaches? Do share!

The SaaSBlogs group on LinkedIn now has 1100+ members and it’s growing every day; make sure you are not missing out and join today.

read more

A Chance at Practical Info for SaaS Companies

Dec 7, 2008 by

I recently came across an initiative named Coming of Age with SaaS that is co-sponsored by Microsoft and Mural Consulting. It’s a free webinar on December 16th that seems to cover a lot of practical ground related to a variety of SaaS topics ranging from product development to customer service, so I figured the SaaSblogs community might be interested and it sounds like it might be worth checking out. Have fun!

 

 

read more

SaaSGrid Is Here!

Dec 2, 2008 by

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

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