While I was in Seattle for Azure training preparing for Dell’s Azure Appliance , Dave @McCrory suggested that we also attend the Seattle Cloud Camp (SCC Tweets). This event was very well attended (200 people!). With heavy attendance by Amazon (at their HQ), Microsoft (in the ‘hood), and Google, there was a substantial cloud vendor presence (>25% from those vendors alone). Notable omission: VMware.
My reflection about the event by segment.
Most of the opening sessions were too light for the audience. I thought we were past the “what is cloud” level, sigh.
Of note, the Amazon security presentation by Steve Rileywas fun and entertaining.
Picking on a Dell competitor specifically: calling your cloud solution “WAS” is a branding #fail (not that DCSWA much is better).
Unpanel of self-appointed cloud extroverts experts:
The unpanel covered some decent topics (@adronbh captured them on twitter), unfortunately none of the answers really stood out to me. Except for NoSQL.
The unpanel discussion about NoSQL drew 2 answers. 1) It’s not NoSQL, it’s eventually consistent instead of strictly consistent. (note: I’ve been calling it “Storage++”) 2) We’ll see more and more choices in this area as we tune the models for utility then we’ll see some consolidation. The suggestion was that NoSQL would follow the same explosion/contraction pattern of SQL databases.
Session on Cloud APIs (my suggested topic)
The Cloud API topic was well attended (30+). The vast overwhelming majority or the attendees were using Amazon.
There was some interest in having “standard” APIs for cloud functions was not well received because it was felt to stifle innovation. We are still to early.
It was postulated but not generally agreed that cloud aggregation (DeltaCloud, RightScale, etc) is workable. This was considered a reason to not require standard clouds.
CloudCamp sponsor, Skytap, has their own API. These APIs are value added and provide extra abstraction levels.
It was said that there are a LOT (50 now, 500 soon) smaller hosts that want to enter the cloud space. These hosts will need an API – some are inventing their own.
I brought up the concept discussed at OpenStack that the logical abstraction for cloud network APIs is a “vlan.” This created confusion because some thought that I meant actual 802.1q tags. NO! I just meant that is was the ABSTRACTION of a VLAN connecting VMs together.
There was agreement from the clouderati in the room that cloud networking was f’ed up, but most people were not ready to discuss.
Cloud APIs have some basics that are working (semantics around VMs) but still have lots of wholes. Notably: networking, application, services, and identity)
Session on Google App Engine (GAE)
GAE is got a lot going on, especially in the social/mobile space.
Do not think a lack of news about GAE means that they are going slow, it’s just the opposite. It looks like they are totally kicking ass with a very focused strategy. I suspect that they are just waiting for the market to catch-up.
GAE understands what a “platform” really is. They talk about their platform as the SERVICES that they are offering. The code is just code. The services are impressive and include identity, mail, analysis, SQL (business only), map (as in Map-Reduce), prediction (yes, prediction!), storage, etc. The total list was nearly 20 distinct services.
I’ve had a busy week with Azure Training and Cloud Camp Seattle. It’s going to take a few days to unwind specific posts about both, but I wanted to hit some shiny new thoughts.
Services helping each other
Adjacent Services are dedicated and/or public services (XaaS) that are offered along side generic public cloud offerings. For a company like Dell (my employer), this could be specific brands of storage or databases (e.g. Oracle). I believe these are much higher margin XaaS than IaaS.
Layer 7 Load Balancers represent a more intelligent link between load direction and the applications. I heard people using this term in multiple contexts. For example, In Azure, the apps can set themselves as “offline” and they will stop getting traffic then they can turn themselves online when they are ready for more.
Cloud Rollout/Migration is a rolling upgrade scheme where you can send traffic to 2 versions of your application at the same time! You upgrade by zones and if you have >2 zones then you’ll have two active versions at the same time. Your data models need to accommodate this.
We don’t have enough Agile Cloud programming books (like Dave Thomas’ RoR Intro). We need a cloud programming book that STARTS WITH INTEGRATION TESTS and shows how to use all the adjacent services. I may just have to write one (or three).