Tag Archives: cloud

Cloud Computing is Software in a Box

Share the article!

Cloud Computing is all the rage these days. Problem here though is there are too many definitions floating around. I would like to however propose yet another definition. Cloud Computing is Software in a Box, or more concisely “Cloud Computing is Software in a Virtual Box”.

What is “Software in a Box”? This is an idea that has been around for a long time. I wrote a blog about it back in 2003 (see: “An Alternative Way Of Packaging Software: Hardware Included!)”. For Cloud Computing this title would now read: “An Alternative Way Of Packaging Software: Data Center Included!”.

Years ago, Bill Gates once referred to pc manufactures like Dell and Compaq (Now HP) as Value Added Reseller (VARs). That is all they did was add value to Microsoft’s software by bundling their hardware with it. Selling software is all about packaging. Most software is bought because its packaging delivers convenience to customers. It is not usually whiz bang technology that makes the sale, rather is is about ease of use, that is usability. What can be easier than receiving a box from a vendor, then plugging it into the wall and into the network to get it running? Well it turns out, receiving a virtual box from a vendor and not be even easier!

The benefits of a “Software in a Box” were described in this old 2003 article:

  • Reduced development complexity – That is less configurations to support.
  • Higher Performance – Performance can be tuned to the hardware delivered with the software.
  • Better Security – The box can be hardened and tested prior to delivery.
  • Easier Provisioning – Just add power and network connectivity.
  • Reliability – Less configuration implies less parties to point finger at.
  • Pricing – People like paying for something they can touch.
  • Distribution – Ride on the coat tails of hardware vendors.

Fast forward now, 8 years later, and we have these same benefits for Cloud Computing:

  • Reduced development complexity – Software can be pre-configured, tested and hardened for the target cloud platform. See: AWS Cloud Formation for handling complex networks.
  • Higher Performance – Software can be pre-tuned to the target cloud platform. For example, if one were delivering a Machine Learning based application, one could tune a solution for Amazon’s GPU cluster.
  • Better Security – The solution can be hardened in the cloud.
  • Easier Provisioning – Just sign up on a website.
  • Reliability – The cloud provider takes complete responsibility even for operational issues. One doesn’t need the expertise to configure a high availability setup.
  • Pricing – Pay as you go, use only what you need.
  • Elasticity – Seamlessly scale when demand increases.
  • In a former life as a Product Architect, I was working on a slide deck that showed how my company’s solution would fit in a prospective client’s network. I had drawn a solution that involved multiple boxes to cover the scalability, availability and heterogeneity of the solution. The feedback that I received was that there were too many boxes! I had also noticed come deployment time with a customer, it became painstaking to have to attend so many network interconnectivity meetings. My eventual solution to this packaging problem was that the software would now be deployed in a blade chassis with all the components pre-configured into blades and the network pre-configured with a virtual router in a blade. We were now back to a single 16u box!

    The drawback of Cloud Computing as compared to Software in a Box is the fact that the customer can’t hold it and as a consequence store it in one’s premises. At a mammalian brain level, a lot of people can be very uncomfortable with this. There’s also of course the concerns of hosting in a shared network,the security of data on shared storage and the robustness of network connectivity. To overcome these fears, one of course could deliver a “Cloud in a Box”.

    Share the article!

    On the Trustworthiness of SaaS Components

    Share the article!

    Marc Andreessen has an intriguing classification of Software as a Service (SaaS). He writes that there are three levels of internet platforms today:

    1. “Access API” – A platform’s apps run elsewhere, and call into the platform via a web services API to draw on data and services — this is how Flickr does it.
    2. “Plug-In API” – A platform’s apps run elsewhere, but inject functionality into the platform via a plug-in API — this is how Facebook does it. Most likely, a Level 2 platform’s apps also call into the platform via a web services API to draw on data and services.
    3. “Runtime Environment” – A platform’s apps run inside the platform itself — the platform provides the “runtime environment” within which the app’s code runs.

    SaaS architectures are naturally evolving from monolithic fixed services to architectures that permit pluggable customization by its users. The primary differentiator between SaaS and conventional software lies in who is operationally responsible for the service. That is, the day to day upkeep of the service is the responsibility of the SaaS service provider and not the licensee1 of the software. What’s new about Andreessen’s classification is that it emphasizes the distinction of which party has the operational responsibilities of each component in an architecture.

    Dividing up operational responsibilities is nothing new. What is new is how responsibilities are distributed to other parties that you can’t absolutely trust. In other words, SaaS services cross trust boundaries and have to ensure that all participant components behave in a controlled manner. How then does it ensure this at the same time allow a participant unfettered programmatic flexibility?

    It is common understanding on how to secure a web accessible API. But how does one secure an executable environment that can allow third parties to run code? The conventional way is to provide a kind of virtual environment or machine with a limited instruction set. Web hosting environments already do this, so there’s really nothing new about Andreessen’s ‘Runtime Environment’. What is new is where the line is drawn between the SaaS and the hosted customers plug-in.

    The selling point of a SaaS is that it provides sufficient value added service beyond a hosted virtual machine that a limited restricted runtime environment is an acceptable situation for the customer. So rather than providing the unrestricted x86 machine instruction set (xc3xa0 la Amazon ec2), a more limited instruction set is provided. Or put another way, a Domain Specific Language (DSL) is usually provided by the SaaS provider. Examples of these are the FBML markup from Facebook, the VXML markup for IVR hosting providers like Voxeo and the Linden Scripting Language of Second Life.


    These environments mirror the security environment of a Web Browser. A Web Browser must be secure from non well behaved code that is injected by a Web Server. In the analogous manner, a SaaS service must be secure from non well behaved code that may be injected by a hosted plug-in.

    The real twist here, that Andreessen may have completely overlooked, is that the plugin code runs within the environment controlled by the user and also in the hosted environment. What this implies is that you can have controlled code have unfettered access to private data. This is remarkably different than just providing a virtual machine or a DSL in a hosted environment. In the Runtime Environment there is additional effort to define and likely constrain remote access to one’s own data. In this execution model, one actually writes server side code that that returns a representation that is rendered by the hosted environment.

    Andreessen comments about the complexities in building a Runtime Environment:

    What are some of those issues? To list a few: You have to provide a runtime environment that can execute arbitrary third-party application code. You have to build a system for accepting and managing that code. You have to build integrated development tools into your interface to let people develop that code. You have to provide an integrated database environment suitable for applications to store and process their data. You have to deal with security in many different ways to prevent applications from stepping on one another or on your system — for example, sandboxing. You have to anticipate the consequences an application succeeding and needing to be automatically scaled. And you have to build an automated system underneath all that to provide the servers, storage, and networking capabilities required to actually run all of the third-party applications.

    It certainly is a lot of complexity, but is it really necessary? The Plug-in API model in addition to addressing the security issue is also more loosely coupled. That is, think of how SaaS services are continuously upgraded unbeknownst by users. Furthermore, the same Plug-in may render varying representations for the same data allowing its capability to be exposed in multiple SaaS environments. Runtime Environments will eventually demand portability, however portability is achieved by providing a restricted API and this is done by best via a DSL (see: Mega-Component Reusability)

    In summary, the Plugin API model is actually richer than the ‘Runtime Environment’ that Andressen seems to prefer. It is an order of magnitude easier to implement and it is more loosely coupled from the hosting platform. The ‘Plugin API’ can execute code in either the hosted environment and on its own. Furthermore, its trustworthiness is ensured on both sides of the equation.

    I for one would avoid unnecessary complexity and lean toward simplicity. This is all and good, after all, web developers are well acquainted with this style of execution.

    1 – You rarely ever own software, but you do often own the license for software.

    Share the article!