A bit foggy on “cloud?”

Feb 24, 2010 by Sinclair Schuller

One question that has popped up in some blog posts recently is whether the notion of “private cloud” is a misnomer or if it conceptually even makes sense. Some of the conversation started when Andrew Conry-Murray posted that the term “private cloud” is bunk and no such thing exists. I have to completely disagree with Conry-Murray. His dismissal of “private cloud” comes from using too narrow of a scope and too restrictive of an understanding of a “cloud’s” applicability, intent, and history.

It’s important to first understand where the term “cloud” originated, as it should really be used in a constructive approach to arriving at the definition of “private cloud” and the determination of how accurate of a term it really is. The term “cloud” originates from a scary place: network diagrams. Have you ever used Visio or a similar tool for modeling diagrams? If so, and if you’ve ever created diagrams that required some sort abstract network, you’ve undoubtedly used the “cloud icon” (which looks kind of like the dust-balls that the Road Runner would leave behind when being chased by Wiley Coyote). This icon was used to denote an abstract network at some responsibility boundary.

Ok, so the history of the term cloud is somewhat rooted in telephony, but we definitely adopted the icon for broader use in general network diagrams. Point being, the origins of the term “cloud”" had nothing to do with the public Internet, and I’d argue it still doesn’t. A cloud is simply an abstraction of network and resource responsibilities that one can leverage in support of some other functional tier or silo. The network diagrams that we’ve all created never restricted the use of the icon to the Internet, but rather remained open to use in any situation where you had to clump non-specific, potentially unidentifiable (but conceptually understood) resources into a dependency.

Given the history of the term and its typical usage, what makes the term “private cloud” so broken? Nothing. An enterprise can use Internet architectures to create internal, “private” resource abstractions. These are private clouds that can be used in a variety of capacities. Granted, larger enterprises are better positioned to leverage private clouds, but that doesn’t mean smaller enterprises won’t build them as well.

All this said, I do distinguish the Cloud, as a proper noun, from a general cloud. The proper noun Cloud should be used to identify the public internet.

How do you feel about the term private cloud? Does history not matter when it comes to best understanding the term? Let me know!

read more

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

Dec 10, 2009 by Sinclair Schuller

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

How does commodity hardware impact SaaS?

Jul 7, 2009 by Sinclair Schuller

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

Non-standard PaaS – The Software Industry’s Rubber Stamp

Mar 2, 2009 by Sinclair Schuller

Coghead’s departure from the PaaS world sparked plenty of interesting debate. One small debate that caught my attention started on Phil Wainewright’s post about Coghead’s demise with a comment by Microsoft’s Eugenio Pace, which then spilled into a post Eugenio wrote here.

To give a brief synopsis, Phil argues that Coghead’s demise and the subsequent stranding of customers highlights the need for a “…standard for transferring not just data but application logic…” The argument stems from the fact that Coghead customers could not easily migrate their applications to another platform, potentially setting those folks back by months of development time, but more importantly, possibly having to throw in the towel on their applications if Coghead goes offline before they manage to perform the migration. Eugenio replied that such a standard essentially exists through standard technology stacks like Java & .NET and that if Coghead was anchored around one of these substacks, customers would not be stranded. He [Eugenio] went on to say that a “standard” was not essential. Phil responded with the following post over at eBizQ.

It’s probably of no surprise to readers that I’m siding with Eugenio on this one. First, let’s clear up some definitions. Let’s call well known development platforms like .NET, Java and Ruby to mention a few ’Standard stacks’. Standard here is being used to describe wide use and general acceptance: that is, I can walk into a development shop and drop one of those names, and engineers either work on that platform regularly or are very aware of its existence. Let’s refer to everything else as ‘Non-standard stacks.’ Something like Coghead or Caspio is definitely ‘Non-standard’; outside of the SaaS choir, few have heard of them. Note that I’m refraining from using words like ‘proprietary’; being proprietary is ok if you’ve achieved a gold standard status in the industry. 

Complex Apps Need Expressive Runtimes

First, a root problem of Non-standard stacks is that they do not Stand on the shoulders of giants. They attempt to re-invent full stacks but fail miserably. I’d be ok if these platforms focused on helping business analysts, casual developers, etc. but they all claim to solve the ailments of ISVs and software engineers. This is simply not the case. They are far too restrictive to be general purpose and solve complex issues. Stacks like Java, Ruby and .NET are unbelievably expressive. It’s like handing Michaelangelo a rubber stamp instead of a full set of paint and brushes: I’m sure he could have done something at the Sistine Chapel with a rubber stamp (see title), but it would look nothing like what we have today. For example, what happens if someone wants to build an audioprocessing application on Coghead (or an equivalent) and deliver it as SaaS? It can’t be done. The expressiveness required for this sort of endeavor is beyond any current Non-standard stack for SaaS. Clearly, .NET, Java and Ruby can support this endeavor. Now, build a Non-standard stack with the expressiveness of the ‘antiquated’ stacks and it has a fighting chance!

A Standard Probably Won’t Help

Assuming one is ok with the limited stack and understands that they will function in a small corral, then the discussion moves to ‘lock in/lock out’. The whole conversation stemmed from the idea of ‘lock-out’ experienced on Coghead. Yes, having an intermediary ‘logic standard’ would have prevented lock out. I can appreciate Phil’s desire for a ‘kill all’ logic standard, but it’s quite impractical, almost impossible to implement correctly, and wouldn’t eliminate the ‘lock in/lock  out’ problem. Eugenio really hit the nail on the head with some of his comments regarding “minimum common denominator syndrome” (the fact that a standard has to be the baseline and expose only control mechanisms that are common across translation targets) and the fact that each implementation can innovate atop of the standard, but this is hidden from the standard. Most folks want to take advantage of innovation, but if you do and you live in standard world, you’ve now re-locked yourself. It seems that it doesn’t really solve the problem, only pushes the boundary out into the world of mediocrity. Many moons ago, I was a Java architect and  also worked as a .NET architect. I can assure you that even in similar stacks, the idea that the ‘logic’ could be captured generically in a standard is difficult to swallow. For the sake of making a point, imagine writing an audio processor delivered as a SaaS application in this generic standard (XML or otherwise). Next, what happens when rogue group X doesn’t like the standard? They’ll define a competing ‘standard’ of course! This never happens in the dev industry…

If you’re locked into Java or .NET, yes, in agreement with Phil, it’s still lock-in, but not anywhere near as bad as lock in to a non standard stack. Locking to a standard stack provides some sense of ubiquity with a max downside of having to figure out where and how to run your IP, and how to fill the gaps left by the now done platform. Lock in to a non-standard stack means a downside of disaster.

The Better Way

At Apprenda, we chose to implement a real multi-tenant, SaaS commercialization and architecture platform ontop of a giant – .NET, and allow those writing apps to leverage this. This gives you a certain amount of mobility and ubiquity, and defers SaaS architecture and commercialization issues to the platform. In SaaSGrid’s case, we treat SaaS like a cross-cutting concern, which leaves most of the application to it’s own concern. This ensures that lock in/lock out is minimized and the application can actually function somewhere other than SaaSGrid, but when in SaaSGrid it runs fully as a service. I think Eugenio’s point that this design seems much more reasonable and would have helped ISVs with application from simple to complex deal with the disastrous Coghead outcome. This is very different to Phil’s examples of Heroku or Engineyard for Rails.

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

read more

What About SaaS and Offline Use?

Jun 25, 2007 by Sinclair Schuller

Both conversations with various individuals as well as recent news of goodies like Google Gears and Microsoft’s Silverlight made me think long and hard about SaaS and ‘offline mode’ (for lack of a better term). Starting at the mile high view, one thing I noticed was a clear distinction between intended and unintended disconnectedness. What’s the difference and is it important? To answer the second question: yes, it is important! Now about the difference – it’s all about the data!

The scenario where one intends to go offline is a much better scenario than unintended. Intentional offline is best described using the salesperson scenario: “I’m getting on a plane in 2 hours, and it’s a 5 hour flight, I’ll be offline.” In this scenario, the salesperson may have a predetermined notion of what data they will need from their sales automation SaaS app so they can accomplish some work during the 5 hours. The explicit intent allows the salesperson to make decisions about the needed data like: “I need all of my records for the past 3 days” and a smart ‘offline mode’ could (within reason) allow that data and any dependencies to live on the client side until it’s synchronized back up after the flight.

Unintended offline mode frankly sucks. Some people want a SaaS app that can maintain a subset of functional integrity in the event that a squirrel chews through some LAN cable. Now, while feasible, a good offline mode in this scenario is much more difficult to come by. It’ll require careful choice of caching strategies depending on use case, as well as constant updating and synching.

Has anyone implemented an offline mode (intentional or not) for a SaaS or client/server app? If so, what sort of headaches have you bumped into? If not, are you planning on rolling out this sort of functionality?

 

read more

Live from SaaSCon 2007

Apr 17, 2007 by Matt Ammerman

Hello from sunny Santa Clara.  We’re at SaaSCon 2007 at the Santa Clara Convention Center today and tomorrow.  From the looks of the exhibit floor and the sound of the early keynotes this morning  there is plenty of opinion and information floating around. An interesting keynote was the ”Evaluating SaaS Infrastructure” keynote which described the challenges of providing SaaS applications from a “behind the curtain” vantage point.  More on that later.

The exhibition floor is poised to open up for the first of three showcase sessions in about fifteen minutes.  Apprenda is located at booth 410, and don’t forget Apprenda CEO Sinclair Schuller will be on the ‘Understanding Platforms and Ecosystems’ keynote panel tomorrow morning. 

We’ll be blogging as often as possible during the event.  If you’re in the Santa Clara area, hope to see you here!

read more