Meet the SaaSBlogs authors in NYC…or join us for a webinar next week

Sep 15, 2009 by

As many of you know, SaaSBlogs is written and maintained by the creators of SaaSGrid.  We have a few events coming up next week, and we thought you’d be interested:

Going From SaaS Product Idea to Paying Customers in Under 6 Months (WEBINAR)
When: September 25th, 2009 at 1:00PM EDT
Where: Register Here!

This will be a great event.  You’ll have an opportunity to hear from Nate Rowe, CEO of Appoint IT, who recently launched their product offering, and was able to go from a product idea to paying SaaS customers in under 6 months by leveraging the SaaSGrid SaaS Application Server.

You’ll also get a chance to hear from Luis Aburto, CEO of Scio Consulting, and myself.  It will be a great discussion, and you’ll see why SaaSGrid is quickly becoming the solution of choice for ISVs large and small as they make the move to SaaS.

You can find out more details about the event, and register here.

“How to Fail Miserably as a Cloud Software Provider” (NETWORKING EVENT)
When: September 22th, 2009 at 6:00PM EDT
Where: Public House, New York City

This will also be a great event, and an opportunity to network with some movers and shakers in the SaaS and Cloud Computing space here in New York.  You’ll also have an opportunity to hear from Apprenda CEO Sinclair Schuller, and he’ll be delivering a presentation entitled: How to Fail Miserably as a Cloud Software Provider”.  If you’re in the area or can be, you won’t want to miss it!

You can find out more and let us know you’re coming here. We hope many of you can join us!

- Jesse

read more

Is Multi-tenancy Just a Database Architecture?

Sep 7, 2009 by

Most everyone that’s part of SaaSGrid has converations either with customers, industry types, media, etc. about multi-tenancy capabilities that we “inject” into guest applications that live on SaaSGrid. One common misconception that we hear people spew out is that  multi-tenancy “is just a database thing.” That is so far from the truth! While many typically think of multi-tenancy as data segregation, it’s in fact much, much more. Usually, folks that haven’t done it (multi-tenancy) don’t get it!

First, let’s look at multi-tenancy at it’s core. What we’re really saying is that we want each customer to feel as if they have their own application instance regardless of what instance orientation is being used (single instance, multi-instance, etc.) Let’s look at the holy grail of single instance, multi-tenant. What we’re really saying is that generally (this doesn’t fit all applications, but most):

  1. Customers needs to login to some *shared* frontend.
  2. Customers execute business logic on *shared* compute resources
  3. Customers store/get data from a *shared* data stores
  4. Customers use auxilliary systems to manage their presence with the service

Is multi-tenancy just a database issue? I hope at this point some level of obviousness has become part of the equation. Multi-tenancy means that you architect your front-end to fit the instance flavor you’ve chosen (in our case, single instance) so that UIs can segregate provisioning and UI rendering. Second, services layers need to execute against data for the correct customer in a safe fashion (so one customer doesn’t clobber another customer), which means we need execution isolation from a tenancy perspective. Next, data needs to be stored and retrieved correctly per tenant. Last, everything from authentication systems to upgrade engines need to understand tenancy and distinguish tenants from one another.

The footprint of multi-tenancy, when done correctly, is huge on an architecture (which also means you’re not using SaaSGrid;-)) One shouldn’t trivialize it as “just an extra column on some tables” because it’s far from that, so make sure you really understand multi-tenancy before tackling it, as it’s one huge iceberg!

read more

The True Value of Cloud Computing

Jul 13, 2009 by

Two weeks ago I had the honor to be invited to participate at a small panel at Structure09 in San Francisco CA next to Matt Mullenberg founder of WordPress, Robert Miggins VP of Business Development at Peer1 and Geir Magnusson Jr. consulting architect at the Gilt Groupe.

The topic of the panel was about the effects of running Cloud Computing on commodity hardware, but somewhere along the conversation, somebody asked a question that prompted a bit more explanation  of the general effects of cloud computing.

See, most people are confused about the true benefits of cloud computing; often citing the cost of running a server from a cloud provider as being less than a traditional dedicated server from a traditional hosting company like Server Beach or alike. The fact of the matter is that running a server image from a cloud provider like EC2 is almost twice as expensive as it would be if you had a comparable dedicated server from a traditional hosting vendor.  The reason is because the true value of Cloud Computing, is not in the cost of running a particular server in comparison to its traditional counterpart, but in the flexibility and elasticity that one gets to instantly scale up or down an application at times of high or low demands.  For these capabilities, we gladly pay a premium.

The problem is that 95% of web applications (my personal estimate) are not designed to be able to take advantage of these properties and for a good reason. IT IS NOT TRIVIAL.  Having the power to instantly scale up or down an application to only consume and pay for the resources that are required at that point in time is an amazing capability and if done correctly it WILL be less expensive than running on regular hardware from a traditional hosting vendor since you don’t have to run at over capacity all the time only of those peak times, but taking advantage of that power is harder than most people think.

Careful design and planning is required when building the application to facilitate this elastic scaling, but that is why companies like my own exist. In my opinion (and thankfully I’m not alone on this one), the future of software is on the web, but this new breed of web applications or SaaS Applications have many particular requirements that are key for their success that truly complicate the requirements to building the applications. Things like a true multi-tenant application, customer provisioning, application metering and billing only to mention a few are a must in order to succeed and are not trivial to design.

Cloud Computing is extremely powerful on its own because when done right, it can provide great financial rewards as well as operational rewards but understand that the hardware layer alone is merely a tiny piece of the puzzle.  The true value of Cloud Computing will be much more appreciated when it is coupled with a platform layer like SaaSGrid that abstracts away the hardware layer and provides a unified foundation to enable the elastic properties at the application layer without the explicit interaction of the application developer.

What are your thoughts? Are you using Cloud Computing strictly for hosting or are you taking advantage of its elastic properties?  What do you think about SaaS Application Servers like SaaSGrid?

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

read more

How does commodity hardware impact SaaS?

Jul 7, 2009 by

One topic that fascinates me is the discussion of commodity hardware. Recently, Abe Sultan, our VP of Engineering at Apprenda, spoke on a panel with a few other great folks regarding the topic of leveraging commodity hardware. People LOVE to talk about commodity hardware, but what does it really mean in the context of SaaS and SaaS enablement? Before understanding what it means, I think we really need to understand what the fuss over commodity hardware is, and what the landscape might look like.

First, let’s chat about commodity hardware in general. First, commodity hardware enables commodity computing. The basic idea is that we’ve moved away from supercomputers, or “scale-up” systems (i.e. throw more memory, CPU, and disk at a single physical box to make it better) and to a scenario where we can “scale-out” by adding more inexpensive physical units as a solution to scale problems. Normally, this is done as a reactive measure to a mounting scale problem. We see this in everything from plain old websites to SaaS architectures. As inbound load increases, we add hardware to resource pools thereby increasing capacity, we then load balance, and voila, all better! Interestingly, infrastructure as a service (dialing up raw resources like servers on EC2) makes this even more practical as a solution. It used to be that “commodity hardware” meant real iron, but now we can deal with this virtually and in an “elastic” fashion (the ‘E’ in ‘EC2′) We’ll categorize this reactive commodity-based measure as naïve scale-out. I don’t mean this in the pejorative, but rather in the formal sense; systematic scale-out of this type exploits coarse grained application level allocation and “bolts on” new capacity with the notion that any new capacity be only minimally aware (if at all) of the “old capacity” and the scale problem it is actually solving, hence the word naïve. Assuming that dynamic scale out needs are real enough to justify using cloud hardware (e.g. EC2, GoGrid), then we have an amazing tool to solve our problems.

Naïve commodity scale-out is amazingly powerful and has catalyzed web-scale operations, but is it the “end all” solution? Not even close. Commodity hardware, at least for most of computing, has allowed us to “back into” older software like RDBMS, traditional application servers (e.g. IIS, JBoss) and build certain types of software architectures in response to scale-problems. Realistically, however, it’s not terribly innovative on its own. What I find most intriguing is the “what’s next” discussion. If we look at the past few years, we should have good indication of what commodity hardware, and more specifically, commodity hardware in the cloud, is allowing us to do.

Let’s use Amazon as a focal point (for no particular reason other than they exemplify where some of the change is headed) When we first think of Amazon, we think of infrastructure as a service: raw servers via, EC2 and web scale storage via S3. But now, Amazon is starting to evolve. Recently, they announced Elastic Map Reduce, which is essentially a step up the stack to the algorithm layer made possible by the mass parallelization offered by commodity cloud hardware. In my opinion, we’re going to see a revolution where “the cloud” will no longer mean boring servers that can be “fired up” on command, but rather a whole array of tools like Elastic Map Reduce that are the software layers that expose commodity hardware’s real value. We even see this with our beloved SaaSGrid – rather than being a traditional “single server” or “single cluster” application server, SaaSGrid establishes a “fabric” across arrays of servers (commodity) and creates a unified hosting layer, allowing the applications it hosts to trivially leverage an expanse of servers. This is a great thing to see, given that the complexity of engineering software to actually leverage commodity hardware layers is a difficult thing to do correctly, and will open the door to a host of SaaS applications that weren’t physically or economically possible before.

read more

SaaSGrid Interview on Microsoft’s Channel 9

May 6, 2009 by

A quick note for anyone interested: I was recently interviewed by the folks over at Microsoft at their NYC offices. We’ve embedded the video on the Apprenda homepage or you can access it directly at MSDN’s Channel9. The interview mostly focuses on SaaSGrid and a bit on the Microsoft stack. I hope you find it to be a valuable 7 or so minutes!

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

read more