Image by BULLETSAYS via Flickr

As
someone who has historically (read hysterically) stuck to the desktop,
I find that the cloud is intruding ever more on my consciousness. If
you’re already in the web camp, the cloud is probably already on its
way to being your bread and butter.

The more interesting
challenge (from my perspective) is how best to take advantage of cloud
based services from the desktop. How long before I’m adding S3/Nirvanix
backup into Home Document Manager? How long before I provide web based
access to the same data?

Whilst I still believe that for PC’s in
the home and business, rich desktop applications still offer massive
benefits over their web based competitors, if your app can successfully
straddle the cloud gap, there’s no need to have your feet in just 1
camp – you can open up new revenue possibilities with a hybrid solution.

If you have a data centric desktop application, it’s worth checking out some of the SDK’s available for your platform:

• Amazon S3 Libraries
• Nirvanix Storage Libraries

Have you integrated and cloud based services in to your desktop application?

What is the right model for
delivering MicroISV applications over the internet?

The Software-as-a-Service (SaaS)
delivery model for offering applications over the internet has really
caught fire…Salesforce.com drove big competitors in the CRM space
into extreme hardship (poor Siebel!), Google’s productivity applications
are being recognized as a great alternative to desktop suites. A friend
of mine with a traditional client-server app says that half the RFPs
they see now they can’t even bid on because they require delivery
over the internet on a subscription basis.

Five years back, everyone thought
that SaaS was going to enable software vendors to reach the small-and-medium
business market, but surprisingly the early adopters were large enterprises,
and that continues to be the focus of SaaS providers. And the reasons
are clear…large enterprises recognize that the total cost of ownership
of software goes way beyond paying the license fee…there are servers
to buy, update management for the operating systems and applications,
security management, performance management, and of course all the expensive
IT guys and gals to do this stuff. As well, many companies “lock-down”
their desktops and don’t allow their employees to install applications
so they can outsource desktop support to an off-shore call center.

So buying enterprise applications,
like CRM, ERP and HR, on a subscription basis was just the ticket…reduce
your IT headaches and have access anywhere, any time, over the internet.

Most microISVs still use the
shareware model for marketing their applications…download to your
computer for free, try it for a while, and maybe 1 or 2 percent will
decide to pay for a license. The SaaS alternative looks pretty attractive…nothing
for the user to install, no license keys to manage, and the stats on
customer retention by SaaS vendors like Salesforce.com is outstanding.

I think SaaS is a great opportunity
for microISVs, but they face several problems. Their apps usually weren’t
designed to be offered through a browser over the internet (that problem
can actually be solved quite easily), most hosting services that provide
the infrastructure for provisioning and hosting apps, subscription management,
and the like aren’t particularly interested in the relatively small
niche markets of microISVs, and SaaS marketplaces like AppExchange require
redevelopment of the app in a proprietary language that restricts you
to one marketplace.

But the biggest problem, I
think, is the subscription model. Subscription to an application still
requires the user to make a purchase decision based on the specific
app, make a payment transaction to subscribe, and make a psychological
act of commitment to it. Whenever you ask a customer to make an act
of commitment, particularly one that involves a purchase transaction,
you are going to experience a high attrition rate.

I think the right model for
microISV applications is what I call the “cell phone model”. For
my cell phone I pay a monthly fee that gives me a certain number of
minutes of talk-time (I’m not masochistic enough to have a Blackberry
yet). So it looks something like a monthly subscription, but when I
flip open my phone I can call any number in the world without “subscribing”
to it. I don’t have to make the decision to subscribe to Grandma’s
number, or subscribe to my girlfriend Sue’s number (God knows what
would happen if I ever let that subscription lapse!). I just dial a
number, and the phone company takes care of measuring my talk time and
remitting money to whatever carriers were involved in delivering the
call.

That’s what I think a SaaS
platform for microISVs should look like. The user creates an account
once, and then has immediate access to any microISV app in the library
at a reasonable hourly rate. The SaaS provider takes care of metering
usage, remitting usage fees to the ISV, and everything else.

Later this year we are going
to be launching a platform called ElastX based on this model
(the details won’t be available until July 7 on www.elastx.com).

Clearly, not all microISV applications
are appropriate for SaaS…some have to be run on the user’s computer,
or are in constant use so a pay-by-the-hour model isn’t feasible.
But there are thousands of apps that personal or small business users
might want to use for a couple of hours a week, and I think that SaaS
is a perfect distribution mechanism for them. 

Overview

FPS allows payments to be configured and prepared in 3 steps:

• A set of rules can be defined to configure which criteria must be met for a payment to go ahead.
• The parties agree to the rules and approve the transaction.
• FPS performs the transaction.

There are 3 actors in a transaction, the caller, the sender and the recipient.

The caller is the actor who orchestrates the whole
transaction. She is responsible for obtaining the authorisations from
both the sender and the recipient. The caller must call the FPS APIs,
so must also have an FPS developer account.

The sender is the actor who is making a payment.
She will send money from any sources associated with her Amazon payment
account, whether it be a credit card, bank account or Amazon Payments
balance.

The recipient, for our purposes, the micro ISV, is the actor that receives the money. The balance of the transaction is added to the recipient’s Amazon payment account.

There are 4 types of Amazon Payment Account:

Personal accounts are generated automatically for
users when they first make a payment through FPS. Accounts are
initially restricted to payments by credit card, but can be enhanced
(with a confirmed email address) to include paying directly from a bank
account, and receiving payments from any source other than credit cards.

Business account have all the benefits of an
enhanced personal account, but with the added benefit of being able to
receive credit card payments.

Developer accounts are similar to Business accounts but allow for API access too.

Ultra accounts are special accounts for users who
have a consistently high volume of transactions. Ultra accounts receive
a discounted rate for credit card transactions.

Pricing

For Transactions >= $10:

• 1.5% + $0.01 for Amazon Payments balance transfers
• 2.0% + $0.05 for bank account debits
• 2.9% + $0.30 for credit card

Spreading the love – a few 3rd party FPS solutions:

• .netCharge – an ASP.net component backing onto FPS
• You can also create your own widget directly from Amazon

Amazon’s Simple Queue Service provides reliable storage and delivery
of messages between any number of computers that have at least periodic
access to the Internet.

SQS
has everything you expect from a messaging system, including loose
coupling and fault tolerance, with some things you might not, like a
distributed infrastructure that stores messages redundantly over
multiple data centres. And of course, being web service based, clients can be built on any platform that can use HTTP requests.

SQS Architecture

Like the other Amazon Web Services, SQS is elegant in its simplicity. It contains just 2 constructs:

• Messages. A message is a piece of textual data up to 8KB in size.
• Queues. Queues store related messages together with a common configuration.

SQS is implemented as a distributed system. It stores messages in
multiple servers and potentially across multiple data centres. Although
this has a positive impact on redundancy, reliability and scalability,
it also has its drawbacks. The distributed nature brings in a few
quirks that you need to bear in mind when developing an application
with SQS.

Message retrievals might return incomplete results. When
a request comes in from a client, the SQS system samples only a subset
of physical servers for messages to return. Although the subset
changes,  you cannot be sure that any particular retrieval
contains all the messages in a given queue.

Messages may not be delivered speedily. You cannot
rely on SQS as a massaging system if you require instant message
delivery. In the normal run of things, messages can take from 2 to 10
seconds to be delivered.

Messages may not be delivered in sequence. Although
SQS will try to deliver your messages in the order in which they were
sent, in a distributed system it’s not always possible. If you need to
have ordered delivery, you will need to add some sort of sequencing
layer on top of SQS.

Messages may be redelivered. SQS uses 2 criteria to
determine whether or not a message should be delivered; whether it
still exists in a queue, and its visibility state (see below). In a
distributed system however, one can never be certain that these
properties are synchronised across multiple physical servers, so your
application must gracefully handle the delivery of a message that
should be invisible or have already been deleted.

Managing Messages

SQS
will deliver a message as many times as it needs to in order to ensure
that it is properly received, processed and acknowledged. This approach
means that no message can be lost. Even if a message-receiving
component crashes, or a network goes down before a message can be
processed.

Messages are managed by changing a message’s visibility state. A messages state can be set to invisible for a certain amount of time. This amount of time varies from 0 seconds to 2 hours, and is set by the queue.

Because
a message only remains invisible for a set period of time, the only way
to prevent eventual redelivery is to delete the message from the queue.
Setting the visibility timeout appropriately is essential for efficient
running of your application. If you set it too short, the message might
be delivered again whilst it is still being processed. Ideally, a
message’s visibility timeout should be slightly higher than the time it
would take to process the message.

SQS Roles

Message Sender. A message sender contacts SQS and asks it to create a message on a given queue with some data.

Message Receiver.
The message receiver periodically polls SQS to see if there are any new
messages available on a specific queue. If there are messages on a
specific queue, and on the subset of sampled physical servers, SQS will
return up to 10 of these messages for processing. If a message is
processed successfully, the receiver will delete the message from the
queue. If it is not processed successfully, the receiver can opt to do
nothing, and let the visibility timeout expire.

Administrator. The administrator monitors the
queues and keeps the infrastructure running smoothly. This role can
bounce quite nicely off of EC2, in the sense that if a queue starts to
back up, it can simply spawn a new server to process the messages!

Pricing

$0.01 for 10,000 requests.

Data transfer is on a sliding scale – $0.18/GB from 0 to 10TB, $0.16/GB from 10 to 50TB and $0.13/GB for any amount over 50TB.

All in all, an enterprise level messaging system, but for a very low cost. Just the right formula for the micro ISV!

The EC2 service allows you to resize your server pool (hence
‘elastic’) at a moments notice. If there is a demand spike, you simply
spawn more servers, if there is no more work to do, you make them all
vanish. As with Amazon’s other web services, you pay only for the
computing power you use. You can also scale the amount of processing
power available to you by using more or less powerful servers.

Your virtual server farm can be controlled by either an API, or by command line tools that Amazon provides.

Overview

There are 3 main components to the EC2 service:

• Instances. These are the virtual servers that run inside your farm, and perform the tasks that would otherwise be done by real servers.
• Environment. Instances run inside the EC2
  environment. The environment provide configurable access control,
  contextual data and other information that your instances need to do
  their work.
• Amazon Machine Images. AMIs are not dissimilar to Virtual PC or VMWare images. They represent a snapshot of your server, and serve as the boot disk.

Instances

Each EC2 instance is a Linux server to which you have root access.
The servers run inside a Xen virtual environment. Since the underlying
hardware is virtualised, its performance can be tuned within certain
preset parameters. Don’t let their virtuality fool you though, they are
configured to give you a very reasonable (and well defined) amount of
bang for your buck.

What do I mean by well defined? EC2 instances are rated by Amazon in
terms of the ‘EC2 Compute Unit’. 1 EC2 unit is approximately equal to
the ‘oomph’ provided by physical machine with a 1.0 to 1.2 GHz AMD Opteron processor, circa 2007.

Server instances can be spawned with one of 3 specifications. They
are classed as small, large or extra large. A small server boasts 1ECU
of power, with 1.7GB RAM
and 160GB of storage. An extra large instance boasts 8ECUs of power
(virtual quad core), with 15GB of RAM and around 1.7TB of storage. The
prices vary from 10¢ per hour for a small server to 80¢ per hour for an
extra large server. More details on the specifications of the machines
can be found on the EC2 home page .

AMIs

Every EC2 server instance is based on an AMI. This is a disk image
of the server’s root file system. When you launch, or spawn a new
server, it boots from the image with all of its installed software,
configuration and data that is stored in the AMI.

You can log into the instance with root priviledges and install and configure any software compatible with your instance’s Linux kernel.
Any changes you make to the system when it is live can be bundled back
into a new AMI that is the starting point for the next time your server
boots. If you so chose, you could create an AMI from scratch using a Linux distribution of your choice, Ubuntu for example.

The AMIs are stored in S3,
and they must be registered with EC2 before you can use them. You can
opt to keep the AMIs as private, so that only you can use them, or you
can share them. You can even create commercial AMIs and offer them to
other users on a paid basis. You simply register them with EC2 as a
paid image, then Amazon’s DevPay system will detect when it is run, and
bill its users a rate you define.

The EC2 Environment

The EC2 environment provides a set of services to your instance,
including networking, security, ephemeral storage etc. Access to the
instance is granted via key based SSH, so that only someone in
possession of the correct private key can access the system.

All internal and external IP Addresses were dynamic in EC2, there
existed no mechanism to hold on to a static IP, but it seems Amazon
have recently introduced good ol’ fashioned static IPs . In addition,
any data written to the ephemeral storage is lost when the instance
dies, so, as is quite common with Amazon’s web services, it’s up to
you, the user, to implement any persistance strategy.

Spreading the love – here are a couple of projects built with EC2 in mind.

• EC2 Firefox UI
• SOAPSonar

EC2 offers a big leg up to fledgling micro ISVs who lack the capital
to invest in serious computational power, but with EC2, it seems a
little more….civilised.

What say you?

Amazon’s
Simple Simple Storage Service provides endless storage for any
conceivable kind of file or data. It provides a highly scalable,
secure, distributed storage network, accessable from any internet
connection, and can be used for everything from backing up personal
data, to distributing multimedia content to millions of users.

Amazon offers a Service Level Agreement
which states that if their uptime dips below 99.9%, you can claim
service credits to offset the disruption. In practise though, you have
to provide Amazon with detailed logs to prove that you suffered
disruption, and that the disruption was caused by S3. The SLA details can be found here:

http://www.amazon.com/gp/browse.html?node=379654011

Overview

One of the great things about the S3 service is its utter
simplicity. S3 has just 2 types of construct, namely buckets and
objects. Your S3 account can contain any number of buckets, your
buckets can contain any number of objects and an object can hold data
and metadata. That’s it. There are no folder structures, no renaming
support, no in place editing, nothing. Almost any application would
need to impose a layer on top of S3, and therein lies its brilliance.

S3 allows you to set access controls on both buckets and objects,
governing who can do what. Each bucket and object is uniquely
addressable with its own URI, for example:

http://s3.amazonaws.com/mybucket/myobject

S3 also allows you to map on your own domain, so you could publish the same resource at, say;

http://www.agilemicroisv.com/myobject

S3 is hugely distributed. It is spread across multiple server in
multiple locations. Currently, you can house data in either the US or
Europe. This is a two edged sword. On the one hand, it provides huge
benefits in terms of reliability, scalability and redundancy, but on
the other hand, its distributed nature can cause the odd headache.

• Objects are not files. S3 does not support any
  file system-like operations on your objects. You cannot rename, move or
  modify files in place. You must get a local copy, make any changes,
  then commit the new file back.
• Propagation latency. Your files are distributed
  over multiple servers in multiple data centres. This can cause issues
  if you have users trying to access the same data at the same time from
  different locations. Let’s say I upload a file, and you try to grab it.
  The object might not appear to you straight away, which can cause all
  kinds of fun with missing and out of date objects. If concurrent access
  is important to your application, you will end up writing some sort of
  version control or intermediary layer.
• S3 requests will fail. Occasionally. It’s not a
  bug, rather a deliberate consequence of the architecture. Any
  application will need to gracefully expect the occasional failure, and
  retry after a small pause.
• S3 IP addresses will change. Occasionally. Again, because of the distributed architecture of the system, you shouldn’t employ any local DNS caching for more than a few minutes.

It’s a great system, but if you’re going to use it, you need to have
a good grasp of what it is, and perhaps more importantly, what it isn’t.

Pricing

Users of Amazon’s web services are billed on 3 fronts.

• Storage. Storage space in S3 is charged at 15¢ per gigabyte per
  month for data stored in the US, and 18¢ per gigabyte per month for
  data stored in Europe.
• Data transfer. Data sent to S3 costs 10¢ per
  gigabyte uploaded. Data retrieved from S3 is charged on a sliding
  scale, depending on how much data was downloaded during the month: 18¢
  per gigabyte for the first 10 terabytes downloaded, 16¢ per gigabyte
  for the next 40 terabytes (between 10 TB and 50 TB), and 13¢per
  gigabyte for any additional data (over 50 TB).
• API requests.
  You are also charged based on the number of API request messages S3
  processes on your behalf. You must pay per-request fees for the
  requests performed by your own application, as well as requests made by
  others when they download data you have made available from your
  account.

Amazon provide a calculator to estimate your usage costs:

http://calculator.s3.amazonaws.com/calc5.html

I’m not sure why the US is cheaper than Europe. It might be infrastructure costs, it might be the worthless dollar.

Spreading the love a little, here are a few applications that have built on top of the S3 APIs:

• Bucket Explorer
• Interarchy
• JetS3t Cockpit
• SpaceBlock
• S3Fox Organizer
• JungleDisk

Image from Wikipedia

Infrastructure costs can be one of the main drivers that prevent micro ISVs from bootstrapping instead of seeking venture capital. Although I’ve been dimly aware of the Amazon Web Services
for a while, it’s only in the last few days that I’ve taken a closer
look and seen what they can offer to businesses in general, and to
micro ISVs in particular.

So what do they offer? Well, in short, they allow cash strapped startups to punch above their weight.

I thought it might be useful to write a series of post briefly
outlining what the Amazon Web Services are, and what they could do for
your average micro ISV. So here’s a quick peek at what they will entail:

• Amazon Simple Storage Service: S3 – A secure, online storage space for any kind of data.
• Amazon Elastic Compute Cloud: EC2 (beta) – On demand virtual linux servers.
• Amazon Simple Queue Service: SQS – Delivers short messages between any computers or systems connected to the internet.
• Flexible Payments Service: FPS (Beta) – Back your payments onto Amazon’s payment infrastructure.
• Amazon SimpleDB (Beta) – Store small pieces of text in a simple database structure.

The post schedule will be as follows:

• S3 9th April
• EC2 10th April
• SQS 11th April
• FPS 14th April
• SimpleDB 15th April

I wonder if selling Software as a Service might help turn this on its head. How could we shift the balance to making existing customers our priority?
And would we want to? As opposed to customers being ‘in the bag’, a 1
year subscription means you have 1 year in which to convince your
customer to not leave in favour of the competition. A potential
customer is someone who might have a genuine interest in your product,
or they might have a fleeting interest in your product. An existing
customer is someone who definitely has an interest in your product, the
question is are they impressed enough to subscribe for another year?

New customers are important. No-one will last long without
recognising that fact. Focusing on your existing customers will turn
your customer base into a sales tool. Testimonials will flow, forums
will be buzzing with a positive support vibe. I’ve seen support forums
full of angry questions like “Where is the support?” Not a great sales
tool.