Cloud: Top 3 Concept Shifts

There's a lot of advice (and hype) about Cloud technologies yet some recent articles around AWS reminded me how our expectations of traditional hosting have changed.  A business used to simply transition from one hosting provider to another via a simple "fork lift" between datacenter providers.  After working with AWS clients for just a year, I've found a few Cloud enablement specialists who echo sentiments that a traditional datacenter move won't work nowadays because of fundamental progress that's been made in infrastructure services.  I went to Amazon's HQ a few months ago for an architecting class where we stepped through migration details that revealed a kind of concept shift for technology migrating to any Cloud provider.

Here's my top 3 concept shifts that are a kind of learning curve to technologists who are moving from traditional IT to Cloud:

• pet versus herd - the "pet versus herd" mentality is a crude term that reduces compute resources to a commodity yet exposes emotional baggage.  Technologists traditionally treated their systems like pets, including the humorous personification of computers, whereas Cloud treats systems like herds, including the expected losses and gains of components.  This has little to do with DR (Disaster Recovery) and everything to do with perspective.  A less caricatured comparison is seeing how the traditional datacenter design goal was to provide always-on services by keeping the component instances always-up, while the Cloud design expects components to be in various states of utility but the services themselves are to never be interrupted.  This design shift has been epitomized by Netflix's Chaos Monkey.
• Infrastructure as code - some have assigned the concepts of "infrastructure as code" to a new role called DevOps, but whatever you call this change the fundamental shift is: 
• a) from infrastructure responding to the application
• b) the application requesting infrastructure.
The difference between (a) and (b) may seem semantic but the implementation of this shift has caused debates to erupt between traditional developer and operation silos, such as the infamous nightmare of developer's "code running servers amok". There are various Cloud services that enable infrastructure components to be dynamically called by applications but the key shift happened by building infrastructure with APIs.  
• don't repeat yourself - a key differentiator with Cloud versus traditional datacenter hosting is using services the Cloud provider offers.  Some of these services are akin to SOA (Service Oriented Architecture) but that has been around for awhile, instead I mean the IaaS (Infrastructure as a Service) concept that keeps popping up in Cloud discussions, as well as automation.  Automation always reeks of job insecurity in IT but actually addresses long standing waste in operations where we think our infrastructure requires some unique solution but really boils down to reinventing the wheel.  The shift is similar to developers switching to "don't repeat yourself" frameworks. 

I've seen "fork lift" style migrations into AWS and not all are simple (or pretty).  An old school migration offers customers little to no advancement in technology and minimal ROI.  Cloud enables a broad range of infrastructure services with APIs that change the way technologists design solutions.  Some of the most common services we implement for customers are:

1. eMail and messaging
2. virtual machines and images
3. network storage and disk volumes
4. virtual and private networks
5. firewalls and routers
6. databases and datasets
7. authentication and access mechanisms
8. logging and auditing
9. load distribution
10. web services

-- even with that long list, I've left off a growing number of IaaS options.  By shifting to these Top 3 Cloud concepts, technologists embrace the latest advancements in agility, reclaim time for genuine intellectual progress, and lower IT costs.  At ICF, we recognize that fundamental progress has been made by Cloud technologies and have committed our resources to understanding this shift so our customers will maximize their investment.

References:

AWS Tips I Wish I'd Known Before I Started

AWS Tips