The Cloudscaling blog has a loyal following as can be seen from the website and RSS feed stats. As many of you long time readers know, I’ve been ‘in the game’ working on cloud computing technology or blogging about as long as anyone except perhaps those at AWS. In all of that time, my thinking and assessment of what’s happening and how it’s evolving has changed continuously. What was interesting for me this year is that this continuously changing perspective slowed to a crawl or perhaps even stopped. 2011 is the year that much of my thinking and perspective on cloud computing, particularly infrastructure clouds (aka “IaaS”) hardened.

That sounds tough. “Hardened.” I don’t mean hardened in the sense of rigid, but rather in the notion of wet cement drying. Many things that have seemed up in the air now seem settled and my doubts about the future of infrastructure clouds are gone. They are not only here to stay, but the shape and direction of them seem very clear. I’m not certain everyone else is clear, but I am. Perhaps I will be wrong, but I doubt it.

Let’s take a look back at the arc of my thinking and how things did NOT change in 2011. That will tell us what 2012 is likely to look like.

The Evolution of My Cloud Thinking
My thinking evolved through three clear phases:

Automation -> VMs & Virtual Datacenters -> New IT Paradigm

Phase 1: Automation
About this time of year, in late 2006, a short time after Amazon EC2 launched, myself and others prototyped a cloud application management framework similar to RightScale. At that time RightScale was named something else and had not been funded or publicly launched. These were early days.

As someone with a deep passion for automation, I remember thinking then that a lot of my lifetime interests (networking, storage, security, and systems management) were all converging and being managed by automation. For me, what was happening was all about automation … and lots of it.

Phase 2: Virtual Machines & Virtual Datacenters
Roughly summer of 2008, the first “CloudCamp” was thrown where a number of the cloud bloggers and thought leaders came together for the first time. Unknowingly we all centered about using the term ‘cloud computing’ to explain what this new emerging phenomena was. It was right after this event and over the summer of 2008 that the term “cloud computing” really took hold. This also led to the formation of the “clouderati”  and I simultaneously joined GoGrid as the VP Technology Strategy.

Perhaps GoGrid biased my thinking, but I started to move from a perspective that was cloud application centric back into my sweet spot of physical infrastructure and a focus on virtual datacenters or what I called at the time, “cloud centers”. In this view, virtual machines were king and inevitably, the question was: “how will we model existing datacenter environments?”

Phase 3: Cloud Computing is a new kind of IT
After leaving GoGrid in the summer of 2009 I had the opportunity to step back and take a fresh look at how things had evolved. I wanted to build my own cloud business again, but I wanted to skate to where the puck would be, not where it was today. I also could see that most everyone involved in the cloud computing space was spending time trying to retrofit the notion of ‘cloud computing’ to their existing business models and technology. Simultaneously, I still didn’t see any serious competitors to AWS.

What were they doing that was so different??

It’s not well known, but in the beginning of Cloudscaling’s (re)formation in fall of 2009 into mid 2010, I did a number of strategic and due diligence engagements on various IaaS vendors for VC firms, Platform-as-a-Service startups, enterprises, and enterprise vendors. During that time I was involved in deep technical dives on the technology and business models for these IaaS vendors. They ranged from GoGrid competitors to more of an enterprise cloud model. By late 2010 Cloudscaling, collectively, had deep architectural and business model understanding of roughly 10 different Infrastructure-as-a-Service (IaaS) players, not including the IaaS clouds that we helped build [1]. I am not sure anyone else had or has that understanding today. What we saw, was telling.

My primary takeaway was that even when it came to startups and direct AWS competitors, absolutely none of the infrastructure cloud players were developing their clouds like AWS. For the most part, they were simply integrating common-off-the-shelf (COTS) components to mimic an AWS-like environment. None of them had AWS velocity [2], nor were they paying attention to what made AWS special [3]. All too often, they identified ‘flaws’ in AWS that were instead unrecognized strengths. Examples of this include:

• Constrained feature set
• Standardized instance sizes
• Lack of VLANs [4]
• Ephemeral storage
• Generic load balancing service without fancy vendor lock-in features [5]

That’s when I began to understand that ‘cloud computing’ had less to do with automation or virtual machines/datacenters on demand and more to do with *how* AWS was building their infrastructure cloud.

Ask yourself these questions:

• Why isn’t VMware more successful in the public cloud space if it’s just VMs and VDCs?
• Why isn’t there a VMware-based competitor at similar scale to AWS? Or even close?
• There are now 100+ “VMs on demand” competitors, but almost none have the same growth rate as AWS … why not?
• What do the largest Internet giants (Amazon, Google, Facebook, SFDC) all have in common from an architectural standpoint and how is that different from a typical enterprise datacenter?

Cloud Computing vs. Enterprise Computing
I gave the third opening keynote at Cloud Connect 2011, behind Werner Vogels of Amazon and Lew Tucker of Cisco. That keynote drove much of the discussion during the first day around ‘enterprise clouds’ and their viability. In that talk was also the initial crystallization of my infrastructure cloud thinking:

We didn’t have one way to build infrastructure clouds … we had two.

One was rooted in the old modalities and thinking around existing datacenters and enterprise applications. The other was rooted in a new way of thinking about Information Technology (IT) that uprooted every approach that had gone before.

Enterprise Computing applied to ‘infrastructure cloud’ [6]:

• How do I virtualize and manage my existing datacenter apps?
• How do I achieve bottom line cost savings and extend server consolidation?
• How can my existing vendors help me create a ‘private cloud’?
• How can I be compatible with everything I own today?

Cloud Computing applied to ‘infrastructure cloud’:

• What can we do to allow application developers to experience ‘infinite scalability’?
• How can we simplify the allocation of traditional IT resources of networking, storage, and compute?
• What will it take to help next generation web applications ‘scale’ by simply adding more of these IT resources?
• How do we make it continually less expensive such that application developers can consume as much as they need?
• How can I, the service provider, make my cost of capital equipment and operational management as low as possible so I can pass those savings on to app developers? [7]

These are two very different schools of thought. One is about saving money for existing datacenters and applications. The other is about enabling new revenue streams via new applications and unlocking the potential for developers to add value to the business. The starkest example of this I can think of can be found in my blog interview with Adrian Cockcroft, the chief architect at Netflix on their adoption of Amazon Web Services [8].

A brief aside: This is why I think the NIST definition of cloud computing is such a huge FAIL. It’s focus is on the superficial aspects of ‘clouds’ without looking at the true underlying patterns of how large Internet businesses had to rethink the IT stack.  They essentially fall into the error of staying at my ‘Phase 2: VMs and VDCs’ (above).  No mention of CAP theorem, understanding the fallacies of distributed computing that lead to successful scale out architectures and strategies, the core socio-economics that are crucial to meeting certain capital and operational cost points, or really any acknowledgement of this very clear divide between clouds built using existing ‘enterprise computing’ techniques and those using emergent ‘cloud computing’ technologies and thinking. [9]

How 2011 Unfolded …
Ever since that keynote at Cloud Connect, it’s become more and more clear that not only is cloud computing a new disruptive displacement of the existing IT model (see blog link just above) in the same way that enterprise computing (aka ‘client-server’) displaced mainframe computing, but that it’s directly intersecting with other major trends in technology.

Infrastructure cloud computing directly intersects and either enables or works with:

• Big data, the explosion of data and data processing needs
• The post-PC era, or the notion of the rise of appliances and mobile platforms as the long term predominant platform, and the shift to ‘apps’ from ‘desktops’ [10]
• Consumerization of IT (TrendMicro whitepaper in PDF), or the notion that knowledge workers prefer more adaptive and flexible environments to get their work done such as they experience in their private lives with the large web application providers (Google, Amazon, Facebook, etc.)

I’m probably overlooking other related trends here, but what is blindingly obvious is that all of these trends are new opportunities, not old. Nor are they a re-hash of old opportunities. Every single one of them are driving infrastructure cloud computing growth. From the hidden, such as Apple’s iCloud, to the obvious, such as becoming the de facto platform for building big data or mobile app backend services.

As 2011 draws to a close this weekend, I’m beginning to see the upcoming ‘trough of disillusionment’ or ‘chasm’ as Geoffrey Moore called it.

Writing -> Wall
We are five years in and no one has emerged as a legitimate challenger to AWS’s market dominance. And, frankly, none are on the horizon. The enterprise infrastructure cloud providers I’m aware of have terminally poor growth rates (<10% CAGR in many cases) and most of them won’t see a return on investment before they hit their five-year hardware refresh cycle. Translation: these enterprise clouds are essentially net losses when evaluating them on a 5-year TCO basis. The hardware itself won’t even be paid for during that time, much less the cost of operations.

Meanwhile, AWS will reach $1 billion in revenue this year and those few that are following roughly the same trajectory as AWS have at least similar growth rates, if not scale (see slide 11).

While VCE touts $1 billion in vBlock sales [11], the onslaught of so-called ‘shadow IT’ hasn’t ceased or slowed down if AWS growth is any indication. Most of these ‘private cloud’ deployments have failed to deliver on the promise of cloud computing, hence app developers still adopt AWS in droves. Frankly, it’s stunning how many of the Fortune 1000 are running production apps, mostly next gen web apps or re-architected versions of last gen web apps, on AWS, but won’t talk about it.

The Road Ahead: 2012
In 2012, we’re going to see the gap between ‘enterprise clouds’ and ‘web-scale clouds’ widen as we enter the chasm. At Cloudscaling we are already seeing just about everyone with an ‘enterprise cloud’ out researching ‘low cost’ alternatives. Unfortunately, this is still missing the forest for the trees, as business agility and top-line revenue growth is a far more compelling value proposition for web-scale clouds.

I believe that 2012 will be a time of experimentation, learning, and quite possibly even larger ‘cloud failing’ than has gone before. Before it can get brighter, it’s got to get darker.

I don’t know the ultimate solution, but one thing is for certain, we’re all going to learn a lot making it through the chasm to the other side. The only other thing I can tell you for certain is that mimicking existing enterprise datacenters is a ‘looking back’ rather than ‘leaning forward’ strategy.

In this coming year I plan to spend a lot more time on this blog and in speaking engagements exploring all of these ideas, thoughts, and revelations in more depth.

–Randy Bias
Co-Founder & CTO, Cloudscaling

Building a cloud that works like AWS or Google involves a complete rethink of just about every concept considered canonical in enterprise IT for the past 20 years.

This is the message Randy Bias and Lew Tucker (Vice President and CTO, Cloud Computing at Cisco) delivered on the main stage CloudBeat 2011 last Wednesday.

High-level takeaways from the video (embedded below) include:

Enterprise IT is not ready to do real cloud. AWS is growing phenomenally: perhaps $1b in 2011 revenue and a 100% CAGR. But even with this market approval, enterprise IT is not psychologically prepared to run their infrastructure the way AWS does. Most large enterprises and service providers still design with the philosophy that each application architecture drives its own infrastructure architecture. The only successful public clouds turn that idea on its head.

Uptime at scale is in the software, not the hardware. Designing failover into the software – rather than the hardware – is another source of dissonance when moving from the enterprise IT mindset to cloud design. At scale, you cannot avoid hardware failure, so successful public clouds manage it though software architecture.

Open source is only part of the answer. Open source software is the only way to go if you want to build a cloud the way AWS and Google do. It’s not easy, though. More than 80% of your time will be spent dealing with issues beyond the cloud OS.

People do not need need to know what’s in the box. The box delivers an SLA and a set of services. It’s an appliance. This defines the move toward a utility computing model. You get one of 2-3 configurations for different classes of workloads, and that’s it.

If you skip through the introductions, the video is just under 20 minutes.

In the short segment, David and Ian explore the five key points that carriers and large service providers are beginning to figure when it comes to their cloud strategies:

1. Commodity Cloud is Winning. A growing list of carriers are beginning to realize that building with commodity-based hardware architectures is the only way to build large systems that are fault tolerant and cost efficient enough to be competitive with their non-carrier competitors.
2. Simplicity Scales. Large, fast, simple systems produce reliable and cost-effective platforms. Complexity does not.
3. Open Systems are Winning. The timing of Oracle’s public cloud launch compared to the sellout crowd in Boston for the OpenStack Summit is a perfect contrast that illustrates this. Proprietary systems are expensive and offer a questionable value proposition. Open source offers short-term risk to be sure, but a more promising future with limited lock-in and licensing overhead.
4. Building at Web Scale Requires New Thinking. In large systems, hardware is going to fail, regardless of how expensive it is. What makes a big cloud reliable and scalable is software, not hardware. Carriers are realizing that they can leave behind their old, expensive, legacy infrastructure when they build web-scale commodity clouds. They get a more competitive cloud with lower capex that’s easier to operate and has less operational baggage.
5. Carriers Have Big Advantages Over Google and AWS. Carriers have nearly limitless, cheap bandwidth. They have deep expertise in network architecture and operations. They own the wired and wireless broadband networks And, they can easily connect mobile and tablet apps to OSS/BSS systems that can help developers get paid and manage customer relationships.

Check it out. Tell us know what you think in the comments below.

Some of this will seem self-evident to those in the OpenStack community, but for those outside, I think they represent a fairly common set of questions that folks ask when trying to understand where Swift is at.

Q: Are there commercial installations of Swift ? Any changes to the code in those deployments?

A: Outside of Rackspace, we know of three additional commercial deployments: Internap’s XIPCloud, KT’s ucloud and Nephoscale. We are aware of a number of other folks working on deployments, but can’t name names. Altogether, these are some very large deployments outside of Rackspace that are running Swift in production. The core of Swift has been battle-tested not just by Rackspace, but by these other service providers as well.

Swift provides the core functionality of the object storage system. There are many systems that need to be designed and built around the core of OpenStack. This includes:

• network and load balancing architecture
• authentication/user management systems
• billing
• portal development
• customer support tools
• installation tools
• operations tools/processes
• hardware selection

These do not include the many configuration decisions that depend on cluster configuration. While we are running (and we believe the other deployments are as well) mainline versions of Swift, there is still much to build for a commercial install of Swift.

Q: Is Swift deployed at Rackspace ?

A: Yes! Swift wasn’t the original implementation of their Rackspace CloudFiles product. They implemented a more robust and more scaleable solution and began running it in production around the same time as the OpenStack release in July.

Q: Conversely, does Swift have all the code that is running at Rackspace or are there important parts that Rackspace runs, that are not in the Swift code ?

A: As mentioned above, much of the system is context-specific and isn’t fully open-sourced.

Q: When one is implementing an object store with Swift, any limitations or ”gotchas” that one should be aware of ?

A: There are many. We’re constantly learning about how our customers’ clusters behave. Nothing is going to teach us how these clusters operate quite like having a cluster that’s in production serving real customers.

On the whole, Swift behaves well. When properly configured, the zone architecture delivers exceptional durability of data and configuring a separate ‘front-end’ tier for the proxy and authentication services ensures scale-out for incoming API requests.

Early in a client deployment we went into pre-production (closed BETA) without monitoring and a server had failed without noticing it. There was no service interruption and Swift dutifully replicated data across to other nodes to keep 3 copies of data in place. We finally noticed when peak throughput numbers weren’t quite as high as they were previously. This really points out the robustness of the Swift architecture.

Q: From your experience, what are the top 4 or 5 lessons learned?

A: There are many lessons we’ve learned along the way:

1. Develop a repeatable deployment process early on. Misconfigured nodes will disrupt the normal operations of the cluster. Have a strong DevOps team in place to develop the software to manage the install & configuration of the cluster.
2. Have deep knowledge on the inter-workings of the cluster. The documentation is good and the code is very well written and understandable. Spend time to get to know the internals of how the system is supposed to behave based on your configuration. For Cloudscaling, this deep knowledge has made it much easier for us to deal with issues in product, fix bugs that we come across and make the enhancements/integrations that are needed to get our customers online.
3. Share your questions or comments about Swift or other OpenStack projects. We’re strong supporters of the OpenStack community, and we’d love to hear what you’re working on.
4. Assemble a cross-functional team as there are many hats that are needed for a successful standup. Data center technicians to help plan the power/cooling needed at the DC, networking experts to help design and plan out the network, a great software development team to write the integrations needed and fix issues related to the software systems of the cluster, Swift is built around common unix tools and folks who are good systems administrator skills can really help tune a running system.

_________________

Have more questions? Send us an email: info@cloudscaling.com.

At the time we released the initial guide (December ‘09), there was very little information out there about building scalable and cost effective infrastructure clouds.  In particular, the level of documentation at an architectural level is still quite barren.

Looking back now at the initial doc, it’s clearly grown long in the tooth (we’re working on a new revision!), but in the meantime we put some thought into a specific problem area: the network.

This new technical whitepaper talks at an architectural level about building scalable networking for infrastructure clouds. Infrastructure clouds are complex and challenging engineering problems.  Covering the topic in detail would take years and several books. Meanwhile, the best practices and state-of-the-art proceeds apace.

So, that being said, sharing these smaller technical pieces (~30 pages) that can go into some detail while remaining broad seems like a great way to share information and foment discussion.

To that end, we present a follow on to the 2009 IaaS Builder’s Guide that focuses specifically on cloud datacenter networking and network virtualization:

[download id="10" format="1"]

Would love to hear your feedback.  We’ll be delivering more of these papers towards the end of the year and into 2012 to share more of our learning and experience.

Thanks to our friends at NEC who sponsored the work on this paper, which enabled us to focus time and resources on this effort.

The thinking behind this presentation will also deeply influence the upcoming keynote I have at Cloud Connect 2011 in early March.  Cloud Connect is quickly becoming one of the best cloud computing conferences out there.  Alistair Croll does a fantastic job of bringing in more than just the vendors and hype.  The net result is a ‘frothy’ discussion that provides a lot of value.

Besides a keynote, I’m running the Private Cloud track and a number of other Cloudscalers will be presenting in other tracks including DevOps & Automation.

I strongly recommend you sign up for Cloud Connect.  If you register by this Friday it’s $400 off!

We also have two free conference passes.  We are trying to figure out some kind of non-cheesy way to give these out.  Competitions, etc. seem a bit overdone.  If you have any suggestions for how we could give these out to the readership here in a way that is congruous with our general blogging values (high content, high value), please comment below.

Meanwhile, embedded below is my keynote from Cloud Frontiers 2011 in early December of last year.  It’s in three parts (after the break below) and is HD quality, so I recommend full screen.

Cloud Frontier’s Part 1:

Cloud Frontier’s Part 2:

Cloud Frontier’s Part 3:

This really comes down to a particular TLA in use to describe grid: High Performance Computing or HPC.  HPC and grid are commonly used interchangeably.  Cloud is not HPC, although now it can certainly support some HPC workloads, née Amazon’s EC2 HPC offering.  No, cloud is something a little bit different:  High Scalability Computing or simply HSC here.

Let me explain in some depth …

Scalability vs. Performance
First it’s critical for readers to understand the fundamental difference between scalability and performance.  While the two are frequently conflated, they are quite different.  Performance is the capability of particular component to provide a certain amount of capacity, throughput, or ‘yield’.  Scalability, in contrast, is about the ability of a system to expand to meet demand.  This is quite frequently measured by looking at the aggregate performance of the individual components of a particular system and how they function over time.

Put more simply, performance measures the capability of a single part of a large system while scalability measures the ability of a large system to grow to meet growing demand.
Scalable systems may have individual parts that are relatively low performing.  I have heard that the Amazon.com retail website’s web servers went from 300 transactions per second (TPS) to a mere 3 TPS each after moving to a more scalable architecture.  The upside is that while every web server might have lower individual performance, the overall system became significantly more scalable and new web servers could be added ad infinitum.

High performing systems on the other hand focus on eking out every ounce of resource from a particular component, rather than focusing on the big picture.  One might have high performance systems in a very scalable system or not.

For most purposes, scalability and performance are orthogonal, but many either equate them or believe that one breeds the other.

Grid & High Performance Computing
The origins of HPC/Grid exist within the academic community where needs arose to crunch large data sets very early on.  Think satellite data, genomics, nuclear physics, etc.  Grid, effectively, has been around since the beginning of the enterprise computing era, when it became easier for academic research institutions to move away from large mainframe-style supercomputers (e.g. Cray, Sequent) towards a more scale-out model using lots of relatively inexpensive x86 hardware in large clusters.  The emphasis here on *relatively*.

Most x86 clusters today are built out for very high performance *and* scalability, but with a particular focus on performance of individual components (servers) and the interconnect network for reasons that I will explain below.  The price/performance of the overall system is not as important as aggregate throughput of the entire system.  Most academic institutions build out a grid to the full budget they have attempting to eke out every ounce of performance in each component.

This is not the way that cloud pioneers such as Amazon.com and Google built their infrastructures.

Cloud & High Scalability Computing
Cloud, or HSC, by contrast, focuses on hitting the price/performance sweet spot, using truly commodity components and buying *lots* more of them.  This means building very large and scalable systems.

I was surprised at the ISC Cloud Conference when I heard one participant bragging about their cluster with 320,000 ‘cores’.  Amazon EC2 (sans the new HPC offering) is at roughly 500,000 cores, quite possibly more.  And Google is probably in the order of 10 million+ cores.  Clouds built around High Scalability Computing are an order of magnitude larger than most grid clusters and designed to handle generic workloads, requiring hitting the price/performance sweet spot when building them.

Grid workloads can be very, very different.

Some Grid Workloads Drive the Grid Community
In talking to the grid community I learned that there are effectively two key types of problem that are solved on large scale computing clusters: MPI (Message Passing Interface) and ‘embarrassingly parallel’ problems.  I’m using terms I heard at the conference, but will use MPI and EPP (embarrassingly parallel problem) so that I can shorthand throughout the rest of this article.

MPI is essentially a programming paradigm that allows for taking extremely large sets of data and crunching the information in parallel WHILE sharing the data between compute nodes. Some times this is also referred to as ‘clustering’, although that term is frequently overloaded today.  Certain kinds of problems necessitate this sharing as the computed results on one node may effect the computed results on another node in the grid.  MPI-based grids, the de facto standard for most academic institutions, are built to maximum throughput and performance per system, including the lowest latency possible.  Most of them use Infiniband technology for example to effectively turn the entire grid into a single ‘supercomputer‘.  In fact, most of these MPI-based grids are ranked into the Supercomputer Top500.

An MPI grid/cluster, in many ways, looks more like an old school mainframe and technology such as Infiniband essentially turns the network into a high-speed bus, just like a PCI bus inside a typical x86 server.

EPP workloads, by contrast, have no data sharing requirements.  A very large dataset is chopped into pieces, distributed to a large pool of workers, and then the data is brought back and reassembled.  Does this sound familiar?  It should, it’s very similar to Google’s MapReduce functionality and the open source tool, Hadoop.  EPP workloads are very commonly run on top of MPI clusters, although some academic institutions build out separate or smaller grids to run them instead.

The majority of grid workloads are of the EPP type.  The diagram below shows this.

I had one person confide in me that “MPI power users drive grid requirements for vendors and assume that if their problems are solved, then the problems of [EPP] users are solved.”
This is interesting since these two types of workloads have different needs.

HPC vs. HSC
The reality is that High Scalability Computing is ideal for the majority of EPP grid workloads.  In fact, large amounts of this kind of work, in the form of MapReduce jobs have been running on Amazon EC2 since its beginning and have driven much of its growth.

HPC is a different beast altogether as many of the MPI workloads require very low latency and servers with individually high performance.  It turns out however, that all MPI workloads are not the same.  The lower bottom of the top part of that pyramid is filled with MPI workloads that require a great network, but not an Infiniband network:

In keeping with Amazon Web Service’s tendency to build out using commodity (cloud) techniques, their new HPC offering does not use Infiniband, but instead opts for 10Gig Ethernet.  This makes the network great, but not awesome and allows them to create a cloud service tailored for many HPC jobs.  In fact, this recent benchmark posting by CycleComputing shows that AWS’ Cloud HPC system has impressive performance particularly for many MPI workloads.

HSC designed to accommodate HPC!

Which brings us back.

The Moral of the Story
So, what we have learned is that scalable computing is different from computing optimized for performance.  That cloud can accommodate grid *and* HPC workloads, but is not itself necessarily a grid in the traditional sense.  More importantly, an extremely overlooked segment of grid (EPP) has pressing needs that can be accommodated by run-of-the-mill clouds such as EC2.  In addition to supporting EPP workloads that run on the ‘regular’ cloud some clouds may also build out an area designed specifically for ‘HPC’ workloads.

In other words, grid is not cloud, but there are some relationships and there is obviously a huge opportunity for cloud providers to accommodate this market segment.  At least, Amazon is spending 10s of Millions of dollars to do so, so why not you?

We’re hiring the devops dream team. Cloudscalers have built major IaaS, PaaS and SaaS systems. We need Senior Developers and System Administrators who recognize ‘Infrastructure is Code’ and embrace the fusion of development and operations.

Contact us if you:

• Have a background of shipping software in a team environment
• Are familiar with test-driven development, continuous integration/deployment
• Are lazy! Have a tendency to automate everything
• Have strong systems, network and storage experience
• Have experience automating infrastructure provisioning
• Are experienced with configuring an application runtime stack
• Are intimately familiar with Linux (Debian, RedHat)
• Have familiarity with existing public cloud computing platforms
• (AWS, Rackspace)

More about Cloudscalers—we love:

• Chef / Puppet
• Building APIs
• Linux Packaging
• Virtualization & hypervisors (Xen, ESX, KVM)
• VMWare APIs (specifically virtual infrastructure (VI) and virtual server)
• OpenSource Cloud tools like, Eucalyptus, OpenNebula, Abiquo
• Opensolaris

And tons of other nifty things. If building the next generation of cloud computing infrastructure interests you, please let us know! We’ll be listening to @cloudscaling on twitter and you can reach us at jobs@cloudscaling.com.

    Xen Cloud Platform offers ISVs and service providers a complete cloud
    infrastructure platform with a powerful management stack based on
    open, standards-based APIs, support for mutli-tenancy, SLA guarantees
    and deteailed metrics for consumption based charging.

From the website:

    In a classical router or switch, the fast packet forwarding (data path)
    and the high level routing decisions (control path) occur on the same
    device. An OpenFlow Switch separates these two functions. The data
    path portion still resides on the switch, while high-level routing decisions
    are moved to a separate controller, typically a standard server. The
    OpenFlow Switch and Controller communicate via the OpenFlow protocol,
    which defines messages, such as packet-received, send-packet-out,
    modify-forwarding-table, and get-stats.

This means you can create a fully multi-tenant, highly secure, extremely flexible, cloud network topology that maps exactly to your requirements.  This contrasts starkly to the current cloud networking today, which is either extremely restrictive (Amazon’s EC2), has scaling problems (e.g. 802.1q VLAN tagging), or doesn’t give you complete control (Rackspace Cloud, et al).

Let me clarify what I mean by complete control before anyone is offended. Rackspace Cloud does provide more control than EC2, but it doesn’t put you in the driver’s seat.  Imagine that instead of having a fixed network architecture like, every customer has a ‘frontend public network’ and a ‘backend private network’, you have something that allows arbitrary network configurations?  Customers get a ‘private’ network by default and buy networks as their applications need them.  Now having a separate network for database servers per PCI compliance (or other) rules is trivial.

Many other things are possible if you move towards an OpenFlow-based network architecture with a centralized control system, including:

• Distributed firewall just like Amazon EC2′s distributed firewall
• On-demand network introspection / tapping
• On-demand in-line firewall / IPS
• N-tier network topologies
• Distributed Virtual Switch (a la Cisco Nexus 1000V)

There are many other possibilities.  The eventual promise here is network virtualization as good as storage or computing virtualization is today.

Way to go Nicira and Citrix!

Of course, we welcome comments and feedback.  They will be incorporated into future revisions.  The paper itself does go into some technical depth in a few areas, but we can provide quite a bit more color in our workshops.

For your reading pleasure, I present our first big technical whitepaper:

• The Infrastructure-as-a-Service Builder’s Guide v1.0 (PDF)

Thanks!

The Cloudscaling Team

Ps. We realize the definition of ‘workload’ or ‘cloud workload’ is not as crisp as it could be and request your feedback and thinking on better nomenclature or definitions.  Credit will be given as appropriate.