Friday Dec 04, 2009

Startup Weekend London

Startup Weekend, phew what a weekend it was !!!

58 hours where attendees were from varied backgrounds such as "developers, startup entrepreneurs,business managers, marketing peeps, graphic artists and more" but what they all did was build something that could be a business. The projects, all nine of them were completed over the weekend at Sun Startup Essentials HQ in London, where the attendees were fed and watered constantly to keep the brain and coding power going into the late night hours.

So with mentors and helpers a plenty, what did the attendees actually produce ?

If you want more information and to see where and when the next Startup Weekend is then go HERE now.



Intent Box
intentbox.com
intent-box
Shows your friends activities you are interested in so they might join you.

ThingQ
thingq.com

thingq_logo
A decision-making tool. The service allows you to make choices using the factors that are important to you.

Meetupalert
Took the Twilio challenge, gives you a phone call when a new group you might want to attend comes up on Meetup.com.

LayerOn
Customization of cars using diff materials (Vinyl, goil foil, leather)

CarbonRank
carbonrank.org

CarbonRank

Bookmarklet that shows carbon info for various companies / car models / products allowing you to make a more informed “green” decision.

Unknown
A mystery project conceived over a bottle of vodka by team Austria.
(Who opted not to present, launch pending…)

99nudges
99nudges.com

99nudges-logo-large

Helping break bad habits and form healthier new ones by starting small.

Garage Sale
onegaragesale.com

logo

Take a picture of your stuff, slice it up and sell it faster.

Know Hive
knowhive.com

An enterprise collaboration tool.

Tuesday Jan 06, 2009

Cloud Relationship Model

Hiya All, welcome to my first guest post at Startup Essentials; today I'm going to be talking about the cloud relationship model I've developed and it's use as an artefact when discussing cloud computing.

I wanted a simply model which I could share with people and use as a discussion point, whilst still capturing the major areas of cloud computing which I considered most pertinent.  I developed a model about six months ago and have since found it useful when talking with people about cloud computing.

Here's the model and I'll go though it's major elements below.


Major Cloud Communities

In the cloud there are three major participants:

  1. the Cloud Providers; building out Clouds, for instance Google, Amazon, etc. Effectivetively technology providers.
  2. the Cloud Adopters / Developers; those developing services over the Cloud and some becoming the first generation of Cloud ISVs.  I have included Cloud "Service" developers and Cloud ISV developers together. This group are effectively service enablers.
  3. Cloud "End" Users; those using Cloud provisioned services, often without knowing that they are cloud provisioned, the most obvious example of which are the multitude of Facebook users who have no idea there favorite FB app. is running on AWS. These are the service consumers.

I think it's important to talk about these communities because I keep hearing lots about the Cloud Providers, and even more about the issues and 'needs' of the Cloud adopters / developers, but very little in terms of Cloud "End" Users.  In a computing eco-system such as this where "services" are supported by and transverse technology providers, service enablers and service consumers an end to end understanding of how this affects these reliant communities is required. Obvious issues such as SLAs for end users and businesses which rely upon high availability and high uptime from there cloud providers come to mind; however other "ilities" and systemic qualities come to mind such as security, and that's before looking at any detailed breakdown of functional services.

The point here is that the cloud adopters / developers and interestingly the cloud "watchers" (i.e. the press, media, bloggers and experts) would be mindful to remember the needs and requirements of genuine end users; for myself it'd certainly be invigorating to hear more on this topic area.

Billing / Engagement Models

Simon Wardley, a much more eloquent public speaker than myself, does a wonderful pitch which includes a look at the different "as a Service types" which he boils down to being a load of "\*aaS" (very amusing, and informative, try and catch Simon presenting if you can).

I wholeheartedly agree that there is a large amount of befuddlement when it comes to the differing "\*aaS" types and sub-types, and new ones are springing up relatively frequently, however I also think it's important to not ignore the differences between them.

For me, and many others, I think first popularised by the "Partly Cloudy - Blue-Sky Thinking About Cloud Computing" white paper from the 451 Group, the differing "\*aaS" variants are identified as billing and engagement models.  That white paper also postulates the five major Cloud Computing provider models, into which the majority of minor "\*aaS" variants fall.  They are:

  1. Managed Service Provision (MSP); not only are you hiring your service from the cloud, you've someone to run and maintain it too.
  2. Software as a Service (SaaS); pretty much ubiquitous as a term and usually typified by Salesforce.com, who are the SaaS poster child.
  3. Platform as a Service (PaaS); the application platform most commonly associated with Amazon Web Services.
  4. Infrastructure as a Service (IaaS);
  5. Hosting 2.0

One of the best breakdowns and visual analysis of this space is the model in Peter Laird's "Understanding the Cloud Computing/SaaS/PaaS markets: a Map of the Players in the Industry" article which is well worth a read.

Major Architectural Layers

Also included in the diagram are the major architectural layers that are included in each of the above billing / engagement models offered by the Cloud providers. They are:

  1. Operations; and this really is operations supporting functional business processes, rather than supporting the technology itself.
  2. Service layer; made up of application code, bespoke code, high-level ISV offerings.
  3. Platform layer; made up of standard platform software i.e. app. servers, DB servers, web servers, etc., and an example implementation would be a LAMP stack.
  4. Infrastructure layer; made up of (i) infrastructure software (i.e.virtualisation and OS software), (ii) the hardware platform and server infrastructure, and (iii) the storage platform.
  5. Network layer; made up of routers, firewalls, gateways, and other network technology.

This rather oversimplifies the architecture, as it's important to note that each of the cloud billing / engagement models use capabilities from each of the above architectural layers; for instance their can be a lot of service simply in managing a network, however these describe the major architectural components (which support the service being procured), not simply ancillary functions, effectively what are the cloud providers customers principally paying for. 

Delta of Effort / Delta of Opportunity

This is much more than the 'gap' between the cloud providers and the cloud users, wherein the cloud adopters / developers sit, the gap between the cloud providers and the end cloud users can be called the delta of effort, but also the delta of opportunity.

It is the delta of effort in terms of skills, abilities, experience and technology that the cloud adopter needs to deliver a functional service to their own “End Users”.  This will be potentially a major area of cost to the cloud adopters. But it's also the delta of opportunity;in terms of 'room' to innovate.

The more capability procured from the cloud provider (i.e. higher up the stack as a whole), the less you have to do (and procure) yourself.  However the less procured from the cloud provider the more opportunity you have engineer a differentiating technology stack yourself.  This itself has it's disadvantages because the cloud adopters / developers could potentially not realise the true and best value of their cloud providers infrastructure.

I suspect that there is an optimum level, around the Platform Layer, which abstracts enough complexity away (i.e. you don't have to procure servers, networks, implementation or technology operations staff), but also leaves enough room to innovate and produce software engineered value.  Arguably the only current successful cloud provider, based upon market share, perception, revenue and customer take up, is Amazon Web Services (AWS) who provide a PaaS offering.

Summary

Hope you enjoyed the article, in summary if developing cloud services or even building out a cloud infrastructure I would recommend that you focus on your users and if your a cloud provider, your users' users; remembering that only a certain percentage of those users will be customers (I won't getting into discussing Chris Anderson's 5% recommended conversion rate for the long tail, however I would recommend understanding what some of those calculations might be).

If you're looking to develop services over the cloud, think carefully about where you and your teams skills lie, and where would you most want them focusing there efforts; working on installing and tuning operating systems and application platforms or writing business value focused applications and services, before choosing at which level to engage with your cloud provider(s).  

I haven't mentioned enterprise adoption of cloud based services, and that's because I'd like to post that in the near future in a different article.

Hope you enjoyed the article and all the best,

Wayne Horkan

<script type="text/javascript"> var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); </script> <script type="text/javascript"> var pageTracker = _gat._getTracker("UA-1786643-1"); pageTracker._trackPageview(); </script>

<script type="text/javascript"> sc_project=2522023; sc_invisible=0; sc_partition=24; sc_security="0e1ffe66"; sc_text=1; </script>
  • Unique Visitors: <script type="text/javascript" src="http://www.statcounter.com/counter/counter.js"></script>
  • Locations of visitors to this page

    <script type="text/javascript" src="http://s38.sitemeter.com/js/counter.js?site=s38horkan" target="_blank"></script>

    About

    Connecting the Startup Essentials community with all the events, information and resources required for them to grow and scale.

    Search

    Archives
    « April 2014
    SunMonTueWedThuFriSat
      
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
       
           
    Today