Thursday, March 10, 2011

Cloud lock-in a bigger issue than security

Before LabSlice I was employed as a Security Architect for a major bank. Banks, government departments and  health providers are naturally suspicious of technology solutions that they do not fully control. This is why cloud security is frequently listed as a concern for big industry, typically followed by operational uptime concerns. What you can't control with your big budget is usually what you fear will backfire and cause you trouble.

But that's not my stance. In general there is little that differentiates normal security concerns from cloud security concerns, and the big players (Amazon, Google and Microsoft) can usually deliver better security controls than most companies can achieve themselves. With certifications such as ISO 27001, annual SAS70 audits and the attainment of PCI-DSS, cloud vendors are showing themselves to have stronger datacentre controls than most companies, or at least SMBs. And true cloud computing (IaaS and PaaS) only provides you the infrastructure, not the application. It's up to you to develop bullet-proof security for your application, by adding appropriate access control, data encryption and frequently monitoring the activities of your application.

So if the cloud is so secure, why do I have a nagging feeling about Amazon, Google and Microsoft being the biggest cloud providers around? My bet is that cloud security concerns will eventually die out, as the next generation of IT professionals start to realize that they have been playing right inside the wolf's den. Cloud lock-in is the problem of the future.

How you will be locked in to your cloud:
  1. Whilst there are some efforts to build cloud agnostic consoles and APIs, these efforts will ultimately bear little fruit. Ever-so-slight differences between cloud providers will make it difficult to extract yourself from one cloud and move to the next. One of the top cloud vendors is already well-known in the industry for locking people into their solutions, and there should be no difference in how they play out their business model in the cloud.
  2. Cloud vendors are not your standard host providers (eg. GoDaddy). Rather, the large cloud providers are already well-established players in multiple industries. Consider that players like Google are providing you a very easy platform on which to build the next social application, whilst at the same time they are trying very hard to enter this market themselves. In many ways I see cloud providers owning a platform that helps them deliver services they want to own in the future, and it's no surprise that the 3 major players are strongly targeting startups. I don't see a company like Google allowing the next Facebook or Twitter to easily migrate their platforms away. The bigger you get, the more hurdles you will find when you talk to your cloud vendor about migrating away.
  3. When you use a cloud vendor today you are not just buying compute power. Rather, you are building on top of a compute stack selected by the vendor, from the operating system right through to the programming languages made available (even IaaS locks you in to certain stack decisions). Migrating from one application stack to another is never an easy task.
My bet... Within 5 years you will hear little about cloud security, but you will find a lot more companies stuck with vendors that they would prefer they didn't select to use today.

Sunday, March 6, 2011

A taxonomy of the Amazon Cloud

Using the Amazon cloud is a challenge, partly due to the overwhelming number of terms that must be understood to just get your servers up and running. Below is a taxonomy break-down that you can use as a reference for getting started with the Amazon cloud.:

  • Cloud Computing: A self-service environment for the creation of highly-scalable applications, with the immediate availability of compute power and granular levels of billing.
  • Amazon Web Services (AWS): A set of services delivered by Amazon that can be used to meet your needs for a cloud-based application.
  • Elastic Compute Cloud (EC2): A service, accessible through either a console or an API, that allows you to launch, stop, start, terminate and otherwise manage the servers leased from Amazon's datacenter.
  • Elastic Block Storage (EBS): Effectively a hard-disk that stores your server image.
  • Simple Storage Server (S3): An HTTP based solution for the storage and retrieval of data, typically used as a file hosting solution that is scalable and which does not need to run off servers that you own and run.
  • CloudFront: A Content Delivery Network (CDN) that is associated with S3, and allows you to distribute your data to physically distinct datacenters around the world, thereby placing files closer to your users and improving their ability to retrieve files quickly.
  • SimpleDB: A non-relational data store that is highly-scalable and tuned to manage large volumes of abstract data attributes (key/value pairs), made accessible to developers via a basic API.
  • Relational Database Service (RDS): A relational database (MySQL) that is hosted and managed by Amazon, and made available to developers that do not want to manage their own database platform.
  • Elastic Load Balancer (ELB): A load-balancer is a solution that distributes traffic evenly to the cloud servers that you own, with intelligence to avoid dead and overworked nodes.
  • Regions: Compute power you use from Amazon (EC2 and EBS volumes) runs in a physical datacenter, whereby there are currently 5 datacenter regions you can use; Northern Virginia, Northern California, Ireland, Singapore and Tokyo.
  • Availability Zones: Each physical region is further broken data into zones, whereby a zone is an independent section of a datacenter that adds redundancy and fault tolerance to a given region.