Carry on camping

Thanks so much to everyone who attended the first CloudCamp London event on Wednesday night, and to the many sponsors who made it possible. Everyone I spoke to said that they had a great time and would love to come again, which is why there will be more events. For those who could not make it this time, the talks were recorded - podcasts and videos will be posted soon.

It was a night of contrasts. Seeing 250+ people turn up on time to a central London venue at 6:30pm was a delightful shock. The inevitable network outage and subsequent discovery that the router had been locked in an office and could not be rebooted was, shall we say, the perfect counterpoint. At this point I'd like to thank Skills Matter whose team were both infinitely attentive and superlatively patient.

For me the absolute highlight of the night was the chance to meet a very large number of interesting and cool people from all parts of the industry. In true British fashion this really got going once we'd wrapped up the presentations and uncorked the wine. Immediately, dozens of groups formed. It was great to see the various cloud providers comparing notes. It was even better to see them in deep conversation with folks like Alan Williamson, who gave one of the best talks of the night, a chequered, perhaps even tartan, account of his wins and FAILs with cloud services.

As James pointed out, this particular sort of socialised interaction is something Brits feel most comfortable with... once we get going. We can be a little slow to break out of our shells. I'm reminded of the old joke in which three national stereotypes are marooned on an island and within a day the French has formed a government, the American has organised a revolution, and the Brit is still waiting to be introduced.

Which brings me on to the 'Open Spaces' aspect of the event and the lightning talks. Putting it about as politely as possible this is the area 'most in need of improvement' for next time. We'd set a limit of ten minutes per talk which of course everyone effortlessly broke. This was entirely my fault for not bringing a stop watch and baseball bat. Next time, all lightning talks will be ruthlessly limited - possibly using an Ignite format. Admittedly some speakers were so engaging that the time flew by and the questions could have gone on all night. But - that's why we brought beer and pizza.

Secondly this was the first Open Spaces event for many people who came. I must confess to having been nervous about this beforehand, and on the web site had asked people to propose talks or topics. About twelve people were enthusiastic or sympathetic enough to offer talks. I figured this would be enough to motivate others to step up from the audience but, aside from one or two fluent folks such as Mark Masterson, it just did not happen. Argh.

At the SF event there were many talks and many people who like to talk. Was London CloudCamp making people laconic, or worse yet, shy? Based on the fantastic atmosphere throughout, and the great conversations people had till late in the evening, I don't think so. I think we can make the format much better. One idea is to have more smaller rooms and start with an hour or two of Open Spaces unconference, then mingle over beers, and have a few really rapid fire talks after that. Please do comment on this blog if you have suggestions!

What else? I had a wonderful time meeting and talking with people. People like Simon Wardley who broke the ice with a tour de force involving 101 slides in 10:01 minutes. People like Phil Wainewright, here seen with some analyst type demonstrating their green credentials, if not their handling skills, on a Segway. People from Sun like Wayne Horkan, and Sara Dornsife who impress by really getting the power of 'community' and who've really worked hard on making CloudCamp successful. The exceliant Adam Vile and his grid team. Thanks are due to Reuven Cohen who kicked off CloudCamp. Ruv, thanks for coming over to help us out with London too.

I was very grateful to Ben Hood from our team at CohesiveFT who was able to show a live demo of our new instant grid in the cloud capability jointly announced with Gigaspaces - using his 3G USB dongle after the network failed. And thanks are due to Dekel Tankel for letting us do that at the end of his talk on scalability issues in the cloud.

I will not forget the sight of William Fellows celebrating his birthday, and first talk at CloudCamp, by stage diving.

In just a few months CloudCamp has gone from an idea and a few emails, to an exciting and quite real phenomenon. Not only will there be more events in SF and London, but people have been getting organised in New York, Portland, Chicago, Paris, and Berlin to name just a few. How can this happen? It's about 'you'. The 'Camp' concept is all about community. There is NO barrier to entry. Please come to the next event in your town, or get involved in organising it. All are welcome.

Oh what a mesh we are in...

It has been a few months since the Microsoft "Mesh" announcement. I am still awaiting my developer preview account - but here are some thoughts from the aftermath.

On one hand the Mesh announcement was initially disappointing. My first response was "Foldershare + some new UI stuff + maybe it actually works". Then I heard some others say "Lotus Notes Documents".

But...upon reflection I think it is one of the first steps of a fairly subtle plan - either out of intent or accident. I am thinking intent. Sun said the network was the computer, other people have coined different variants of the phrase since then. Here Microsoft Mesh is saying "the big giant distributed hard drive in the sky is the computer". This is a very savvy move given how "hard drive"-centric the Microsoft platform is. Now add on a tarted up version of the roaming profile stuff that has been in Windows since NT, and how fast broadband is now, and a Vista machine - one can start having more lightweight infra with easier synchronization of assets. If the Mesh starts moving my files close to where I am in the background - even better.

Also - look at how MSFT is describing the user experience of the Softricity stuff they bought - now called Softgrid. Although in many ways unchanged from way back when Softricity wrote it, Microsoft uses interesting words. When you "stream" an application from the server - to run on your Windows Desktop (ultimately all of the application components arrive on your machine, all executing locally) MSFT emphasizes that the application is NOT INSTALLED on the local machine. It is just "copied to the cache and executes from there". Wow! That is what I have always wanted. If a bundle of files can be copied to the hard drive and then run without spewing bits all over the hard drive, and without having anything to do with the registry, and then runs, that is what we all want. Sounds remarkably like installing software on Linux, Unix, Solaris, or Mac. The worldwide hard drive, roaming profiles, application installation via file-copying, and licensing checked at runtime, not install (copy) time - really opens up some interesting opportunities in the Microsoft world.

THEN - there appears to be WinFS bits in here somewhere - which was supposed to be a pluggable filesystem. If that is the case and I can upload a bit of CLR somehow, somewhere, that executes based on actions in the file system, then I have a big, slow, global, message bus. Which again tees up some interesting possibilities.

As we just recently saw at CloudCamp San Fran and as I said on the PaaS Panel at Structure 08; we are in the "Cambrian explosion" period of cloud computing and we will see lots of interesting life forms before the winners become obvious. Microsoft Mesh certainly adds some interesting DNA to the ecosystem.

Elastic Rails Servers now with Phusion Passenger (mod_rails)

There's certainly been a lot of buzz about Phusion Passenger (a.k.a mod_rails) recently. With a prominent quote from DHH on their webpage, Phusion aims to take the Rails deployment world by storm by offering a system that's both easy to configure and claims to outperform Mongrel.

Now you can easily try out both Mongrel and Passenger by downloading Elastic Servers configured with either deployment strategy from our Rails 2 Portal. We've also added a handy Capistrano script for Rails Elastic Server deployment. Simply build a server, and follow the instructions on the Rails portal site to deploy your app.

Build your server today and download it for local testing or deploy it into the cloud with one click!

It Feels Like the First Time...

We are continuously growing our Component Portal offerings. By adding more choices to existing portals and creating places to test and digest brand new projects, the Elastic Server On-Demand is filling out nicely.

Ruby on Rails Refurb - Not just a Rails 1.x any more, we have added Rails 2.x!

We also added greater choice of web container, data bases, and a great list of popular RubyGems (including Capistrano). Remember you can deploy your app using the Bring Your Own feature set in the Personal Edition free trial. Upgrade today and experience development bliss!

New Portals - Click below to check them out!
Google App Engine Portal

Shindig Portal

LAMP Stack Portal

Cloudy weather ahead...

You probably heard - Google announced its "cloud" Google App Engine - tonight. Although they have stated that it will allow "automatic scaling and load balancing" it is most assuredly not a "grid". Now with Amazon's EC2 offering and Google App Engine, a key distinction between traditional grids and clouds can be seen.

Why are clouds different? Many of the grid computing offerings (not all I might add) seem to have a scientific air about them that is both offputting and overly elaborate. Academic solutions tend to slow themselves as the inventors work to perfect everything - focusing on the corner cases. Market solutions tend to give you a couple different configurations; each one pushing a nasty corner cases to the edge of the room and ignoring it. As long as your needs aren't in that corner - then this works for you.

Clouds are gathering in this way. Attempting to use Amazon EC2 "for real" highlights hundreds of things it can't do well, or yet. So what? There are hundreds of things it can do - if you want to get one of them done, use it. Or don't. Clouds don't care. That's another difference.

Clouds don't care.

Amazon - It's cloud is based on virtualization with Xen base containers. Anonymous servers, anonymous services, simple web API, nominal SLAs. But it is simply awesome if your use-case fits. By the way, CHEAP!

Google App Engine - Python version 2.5.2, "the datastore", Google Accounts APIs, URL fetch, email services, Django support, and a simple web framework "webapp". And did I mention CHEAP! Free for use by the first 10,000 developers to sign up. As best I could tell the 10,000 accounts were gone in about 20 seconds.

Look at the descriptions of these two real world services. They are not the stuff traditional data center solutions are made of. I can just see various IT types listing their objections to Google's new offering:

• Python mathematical routines are nowhere nearly as "performant" as Perl
  
• Django is nowhere as easy as Rails
  
• "the datastore" doesn't implement ANSI SQL - in fact what the hell is this GQL?
  
• Email API only let's me send messages - I MUST be able to read them
  
• Webapp is not sophisticated enough for me
  
• I need to compile a C library for use on the piece of hardware where it will run
  
• I am concerned about SLA's. I need guarantees! I won't agree to the Terms of Service!
  

You know what?

Clouds don't care. Your complexity is not their problem!

Each of these two clouds provide a lot if you are willing to be cheap, flexible, and creative. While complex types sit back and complain - those who take advantage are going to prevail. Look at evolution; big, fat energy inefficient organisms usually don't evolve to become nimble, energy efficient creatures. They go extinct and make way for the next wave of situationally optimal lifeforms. What do I mean by this sentence? One interpretation would be "don't expect ATT's Sterling Commerce to threaten either EC2 or AppEngine for cost, performance or speed."

Looking through Admiral Boom's telescope
More clouds are rumored, not released, but may be announced by end of '08. Maybe virtualized containers of any format? Maybe application containers of a new and interesting type? Here are some of the things coming:

Mashup engines - Here you go Yahoo, this one is free. Mashups are fine - but they tend to be information integrated at the moment of user consumption. What about all the gluecode that runs in the middle to make really cool mashups? The code that does temporality, flow, trend, events, averages, highs, lows, estimates - on all sorts of services - that I want to display visually after long running background aggregation. Long-running data mashups with quick visual displays.

BEA Project Genesis - announced at BEAworld Shanghai. BEA application services in a cloud. Standards-based (at the core) - subscription-based. Easy for developers to access. Drop in an EAR and start billing.

P2P Clouds - VcubeV lets you do Virtual Private Data Centers - the initial basis of a p2p cloud. Encrypted transmission, virtualized containers. Extensions to OpenVPN and VcubeV could let you run a slow but powerful P2P cloud. Run it like a co-op? Give cycles - get cycles?

Dinosaur "clouds" - What is the impact on business networks run by the likes of BT, ATT-Sterling Commerce and others. Multiple orders of magnitude more expensive, little customer choice, archaic APIs and monitoring services. Yikes.

At CohesiveFT we started our company precisely because we felt that open source, open standards, virtualization, and loosely-coupled architectures were going to utterly transform the way data centers worked. At this point I would say we were quite close in our anticipation, but that it is all happening even faster than we thought. Our Elastic Server service was designed to allow assembly of application components for deployment to containers and clouds. We look forward to supporting App Engine! See this space as they say.

Elastic Servers and Amazon EC2 Security Groups

If you have accessed the Elastic Server Manager which runs on port 2999 in each virtual machine we create, then you have probably noticed the Firewall tab.

Each Elastic Server comes with a built-in firewall which can be administered via the management UI or its web services. The Firewall tab can be used to manage the ports used by your server.

Some components have their default firewall ports already set in the Firewall tab. That is because someone (most likely us at the moment) has implemented what we call a "firewall rubberband" for that component. The whole topic of using "rubberbands" to snap things into Elastic Servers will be documented more fully in an upcoming post.

Regardless of what the specific server's firewall is doing - when using EC2 - you need to be aware of the Security Group which controls Amazon's firewall and access to your running EC2 image. Currently, we DO NOT coordinate the firewall settings of your VM with the Amazon Security Group (although on the roadmap). In order to access some of your services you may have to manually configure the Amazon Security Group.

Here is an example:

Suppose I build a Shindig OpenSocial server via Elastic Server On-Demand using my Amazon EC2 credentials. When I attempt to access my sample gadgets I can't get a connection via:

http://amazon-public-dns-name:8180/gadgets/files/container/sample1.html

Where my Amazon public DNS name is something like: ec2-72-44-51-65.z-1.compute-1.amazonaws.com

and 8180 is my Tomcat port.

The reason is even though my VM's firewall is accepting traffic on the Tomcat port, the Amazon firewall for my image is not.

To correct this I use the Firefox plugin for EC2 called "EC2 UI". After configuring the plugin with my credentials it lists the Public and Private AMIs I have access to. In the picture below you can see that I have launched an AMI called "pat-dig". You also can see that it has been launched in the "pat-dig" group.


To change the port settings in the security group I click on the Security Groups tab. In the picture below you see the result; the port settings for the pat-dig security group. Port 8180 is not one of them. The ports you see are the default port settings we use when making an AMI through our service.

In the bottom third of the screen you see the Group Permissions. To add the port 8180 permissions for Tomcat, click on the green circle with the checkmark in it. This will pop up the UI box below, where you enter the rule that inbound traffic on port 8180 should be delivered to the VM instance on port 8180.


After entering 8180 as the "from" and "to" ports. I click on add - which results in the refreshed display of the Security Group below.


I can now access my Shindig container running under Tomcat!

All at once I saw a crowd

Last week James Governor of Redmonk published a blog entry entitled “15 Ways to Tell Its Not Cloud Computing”. It drew some very interesting commentary from Mark Cathcart, John M Willis, Chris Petrilli and Gerrit Huizenga.

James was kind enough to acknowledge my input in his blog entry and in return I’d like to offer some views on why I substantially agree with his blog post. Please note that this is an emerging space and the idea of a cloud remains nebulous. So what James is really saying, I think, is: let’s ask what we want from cloud computing in the next few years.

Clouds are all about delivering a “retail like” experience to users - even within the enterprise. Here is an analysis what this might mean.

If you peel back the label and its says “Grid” or “OGSA” underneath… it’s not a cloud.

Clouds are about offering compelling economics for infrastructure as a service instead of as on premise servers or big desktops.

Clouds offer a fundamentally different abstraction than Grids. If there is a metaphorical ‘label’ then you should not be able to ‘peel it away’ at all. Grids provide a mechanism for running processes that implement a specific API, across multiple compute resources. Clouds provide a service for users to run whole applications by deploying them to a virtual data center.

Of course clouds can use a grid technology under the hood, for example to schedule slots. But the point is that many complexities are hidden from the user in order provide a clean and simple service. Whether the cloud is “public” like Amazon EC2, or in some sense an “enterprise” or “private” cloud, it delivers a “retail experience”. You should not need to read and understand multiple long documents to use it. I know of several hedge funds running grid style compute farms on EC2 using map/reduce on Xen images - it’s easier that way.

If you need to send a 40 page requirements document to the vendor then… it is not cloud.

In my opinion a cloud should offer “self service” capability. The cloud should not itself need to be customised by the provider, for individual customer use cases. This is not just about “productising” for the retail market. Consider an enterprise with two data centers. Clearly it saves money and time if applications can be migrated between data centers without refactoring. An enterprise knows it has implemented a cloud, when this is possible. Achieving this requires a certain abstraction.

If you can’t buy it on your personal credit card… it is not a cloud.

Well - sort of. This is about managing cost when multiple users share common server infrastructure. Without a means to capture costs of use and attribute them to users, explaining where value comes from becomes a matter of guesswork. This hampers investment in new enterprise projects by staff who want access to shared infrastructure, and commonly leads to ‘guerilla’ use of things like Amazon EC2 by staff on their own credit cards.

At CohesiveFT we meet customers who tell us that, as they migrate to ever larger pools of shared infrastructure services, they are unable to understand which business units are using which resource and when. Individual business units are unable to calculate cost/benefit. Costs get aggregated to maximum granularity and have to be justified by the CIO and CTO to the CEO and COO. In practice this makes it impossible to get things done.

The solution that I think the cloud model enforces is based on the discipline of a retail model. If data center providers made all users attribute costs as if they were paying by credit card, then everyone would know how much they were paying and for what. This would break down barriers to financing and starting new projects however small.

If they are trying to sell you hardware… it’s not a cloud.

Clouds represent a way to separate ‘opex’ from ‘capex’. People making investment decisions about cloud resource needs should not need to factor in any amortised capital investments in hardware, because they only pay for what they need, when they need it. When a business case is being made for a new enterprise project, if hardware purchasing costs do not appear in the ROI calculation, then you probably have a cloud. Then, the data center managers decide how much hardware to buy and at what price to offer their cloud services to business units. An internal market may be used for dynamic pricing.

If there is no API… it’s not a cloud.

If there is no API then it is not a service. Clouds virtualize resources (e.g. CPU, storage) as a service. Hence clouds must have APIs, e.g. a means to load and start up an application, or to stop it.

If you need to rearchitect your systems for it… it’s not a cloud.

The key word here is ‘need’. What we are discovering is that virtualizing whole compute environments may be the right way to ‘do’ utility computing. Whether computers are delivered as bootable images or as VMs, this means that people are not required to completely rewrite their application to run it in the cloud. Do we need to explain why this is more attractive than the alternative? I didn’t think so.

Note that people surely will come up with new ‘green field’ applications that depend critically on the cloud infrastructure. These ‘virtual stacks’ are very exciting too.

If it takes more than ten minutes to provision… it’s not a cloud.

Is this controversial? As John M Willis points out, the whole notion of provisioning is being replaced by autonomics and elasticity for managing running systems. At CohesiveFT, we also argue that elasticity really means provisioning includes built-to-order system assembly.

If you can’t deprovision in less than ten minutes… it’s not a cloud.

This is really critical. Being able to stop something and clean it up, is much more important than being able to start it. Anything else just adds friction which translates into less incentive to use the service in the first place and hence less agility and other benefits.

If you know where the machines are… it’s not a cloud.

Location matters for many applications such as trading systems, and complex clusters, because location impacts latency. But then the latency properties of a service ought to be exposed as part of its contract with the user. Then, perhaps users are willing to pay more for lower latency, or for better bit throughput.

What clouds ought to do, however, is get us away from any ‘my rack, your rack’ thinking because that breaks the retail model by recoupling opex to capex.

If there is a consultant in the room… it’s not a cloud.

Of course if you want to build your own clouds and work out the business case for moving system administrators over to new roles such as “virtual sysadmin” then get a consultant.

For actual use of a retail-like service by the enterprise, or within the enterprise, you should not need a personal shopper unless your use of clouds is a vanity project.

If you need to specify the number of machines you want upfront… it’s not a cloud.

The point is that you can increase your load whenever you like, so long as you can pay for it. Hence it does not matter if you start with zero machines or ten thousand. This is not the same as saying “you cannot request how many machines you need”.

If it only runs one operating system… it’s not a cloud.

This is about cloud providers not forcing end users to adopt their particular operating system distro and build. It characterises the difference between the new ‘self service’ clouds based on virtualization technology, and the CPU-rental model of a couple of years ago.

Generally the people we meet have their own ideas about which O/S to use on their computers, so why not extend this to the cloud? The alternative is to offer a data center service which only runs a particular O/S build - this kind of Linux, that distribution, and that build. In an enterprise, this simply does not scale across multiple data centers over time. For a retail cloud, it’s out of the question. This is why it is hard to see retail and enterprise clouds working commercially unless the compute unit is a virtual image or bootable image.

If you can’t connect to it from your own machine… it’s not a cloud.

Clouds are about consolidating resources in order to benefit from economies of scale. When a service is inaccessible or unavailable, then that diminishes its value to the service provider as well as the end user. We have found that people want to do things like spread their loads across their own machines, and data centers, or across multiple clouds securely. We call this ‘multi-sourcing’. Obviously some degree of secure accessibility is a prerequisite for this.

If you need to install software to use it… it’s not a cloud.

“You” means the user - clouds are about making life easier for users. If you are an enterprise with a cloud, or using clouds, then you may have teams all over the world, including folks coming and going all the time, or working from within IT suppliers or at customer sites, then your cloud will have a lot of users. You want to reduce any costs that you are currently paying for them to access your IT resources. This is why a ‘retail experience’ is so essential. Cloud means service.

If you own all the hardware… it’s not a cloud.

Because you don’t want to own all the hardware. It eats up power and space, gives off heat, and needs people to look after it. As more and more “green tape” appears in the form of environmental regulation, and if oil prices go higher, trust me you won’t want to own and be responsible for owning and managing hardware.

If you need a three page blog post to explain it ... it’s not a cloud

Enough already!