Sunday, May 1, 2011

The cloud goes down

Lots of businesses were affected by the recent Amazon EC2 cloud outage. Whilst annoying, it is still prudent to consider that Amazon delivers a higher uptime capability than most companies could achieve by themselves. We were also impacted by the EC2 outage, and were actually asked by ComputerWorld magazine to comment: http://www.cio.com.au/article/384466/amazon_cloud_outage_bad_business/.

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.

Friday, February 25, 2011

Cloud security: Keeping those keys safe

Jack Murgia, from Cloud Controllers, sent me an interesting query last week: "How does LabSlice ensure that the Amazon Web Services (AWS) Access Keys remain secure within the application?"

This is a great question, as the AWS Access Keys are the keys to the house for any business using the Amazon Web Services cloud. It's true that our application stores more keys than most (we provide an AWS management service that utilizes our customers' keys), but you will more than likely find keys used within your application, whether to upload files to cloud storage (S3) or within scripts that are launched by your application.

In fact, any cloud service provided by any vendor will ultimately involve some sort of key, certificate or credential authentication to give the application access to various cloud resources. So extend these ideas to the cloud of your choice...

We secure our cloud platform by:
  • Leveraging the inbuilt security controls of our development platform: In our case we use the ASP.NET Membership Services to manage application authentication and password storage, declarative security to limit access to sensitive parts of the application (eg. those that utilize AWS keys) and page security definitions to ensure that only particular users have access to particular pages. None of these controls are specific to the cloud, but security at home starts by making sure you have locked your doors and closed your windows.
  • Storing sensitive attributes in encrypted format on disk: Storing the AWS keys in encrypted format protects them from systems administrators and other management folk that may need to get console access to our application. It also ensures that the keys remain secure when nightly backups are taken and shipped to S3.
  • Running all key transactions over HTTPS, not just the login page: This seems to be a new trend in security (likely due to FireSheep) and we decided to adopt it as well. It's a useful additional control to protect those AWS transactions that are run under the context of our customers' AWS Access Keys.

But this is about cloud security...

Notice that the security controls we use have little to do with cloud computing. So is there anything cloud-related that we do to improve security? Turns out there is. I have come across three useful controls that are very cloud specific and that both us and our customers are implementing:
  1. Termination protection: This is a feature of the Amazon cloud that blocks APIs from terminating a machine. It's somewhat of an operations control, to stop your administrator from mindlessly terminating a production machine. But it's also a useful security control in case your Access Keys somehow leak out, or maybe to protect yourself against a malicious employee days before their own termination.
  2. Access Key permissions: By default most keys used in the cloud give global access to everything. As cloud vendors mature, so do the restrictions on these keys. If you're using keys for limited activities (say, to upload files to S3) then it's a good idea to restrict permissions solely to those activities. Our customers also limit the AWS Access Key permissions of the keys they use on our system. For example, Cloud Controller's policy (see below) specifically forbids the ability to take snapshots, which is a good way to reduce their attack surface whilst using our system.
  3. Network access: Again, a specific control to Amazon, which can be mapped to your favorite provider. If you're using Amazon then you would naturally want to use their Security Groups (firewall) to block public access to your RDP and SSH interfaces.
Notice the difference?

Whilst cloud does has its security controls, the vast majority of our efforts go into implementing and maintaining security using familiar techniques that have nothing to do with cloud computing. If you're using the cloud then forget about cloud security. Go back to basics and learn about CIA and follow the OWASP Top 10 guide. Whilst cloud has valid security concerns, the vast majority of security compromises in the cloud will still end up due to a failure with the basics: Poor access control, vulnerability to command injection (eg. SQL) and inadequate logging and monitoring.



Sample key permissions from one of our customers (notice how they block our ability to take snapshots):

{
  "Statement": [
    {
      "Action": [
        "ec2:AttachVolume",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateKeyPair",
        "ec2:CreateSecurityGroup",
        "ec2:CreateVolume",
        "ec2:DetachVolume",
                "ec2:DescribeImages",
                "ec2:DescribeInstances",
                "ec2:GetConsoleOutput",
        "ec2:GetPasswordData",
        "ec2:RebootInstances",
        "ec2:RunInstances",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:TerminateInstances"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Thursday, February 3, 2011

IaaS and PaaS to disappear by 2012

Cloud computing comes with its own unique acronyms, which can at times make it a confusing space to work in. The two key acronyms people know are:

  • Infrastructure as a Service (IaaS): The provider gives you on-demand access to compute infrastructure, with console access (RDP or SSH) to a server that you completely own. Application administrators can request as many servers as necessary to meet the scalability needs of their application. IaaS is typified by the Amazon Web Services cloud.
  • Platform as a Service (PaaS): In this case the provider gives you on-demand access to infrastructure, but does not give access to the underlying console. Programmers can request as much compute capacity as is required to run their application. The underlying technology will distribute and run the application on as many servers as is required. PaaS is typified by Microsoft Azure and Google AppEngine.
IaaS is your familiar application deployment environment, where a program needs to be installed and configured to run on the box, necessitating a mix of programming and server administration skills to succeed. Conversely, the PaaS concept tries to abstract away the underlying hardware, such that programmers can simply load their application and see it run auto-magically in the cloud.

IaaS and PaaS are different operating models, and selection between them is frequently a matter of skills, technical feasibility, development language preference and simple belief in the model's ability to succeed.

IaaS and PaaS to combine

The separation between IaaS and PaaS is somewhat arbitrary. It just so happens that Amazon got into the IaaS business as a way to re-sell hardware capacity that sits idle for much of the year (most of the hardware exists to absorb the load of the Christmas shopping period). Google got into the PaaS business as a sensible extension of their skills in building highly scalable web applications on commodity hardware and opensource software. Microsoft... Well, Microsoft got into PaaS as a way to ensure that their technology (.NET) remains competitive as people move to the cloud.

But cloud computing is now maturing. And as it matures, people request more flexibility, somewhat blurring the lines between IaaS, PaaS and general application delivery services. Take a look at Amazon's recent offerings (last 2 years): CDN, SimpleDB, DNS and Email Services. These are not just solutions to deploy more server hardware, but rather they are ancillary services that help applications work more effectively in the cloud. In fact, the most recent announcement from Amazon is Elastic Beanstalk, a solution built specifically to help developers to migrate their Java applications to the cloud -- sounds like PaaS, no?

What's next?

With the release of Amazon BeanStalk you can see that Amazon is truly going to mix IaaS and PaaS, and go head-to-head in competition with Google and Microsoft. And to remain viable the two big PaaS vendors will need to extend some of their services into Infrastructure offerings. After all, application developers do frequently need OS level controls to deliver their solutions (for example, our product LabSlice needs to use the Windows Task Scheduler for daily reports and cleanup tasks). In short, by 2012 you will see that cloud computing becomes a mishmash of hardware and application services, and that the unnatural boundaries of IaaS and PaaS will disappear.

My bet for 2012
  • Amazon to go head-to-head with Microsoft and Google. New solutions from Amazon will be aimed at developers who don't want or need access to Amazon's underlying infrastructure, and just want their application to work in the cloud.
  • Microsoft and Google to give more access to the underlying operating system. Certain switches and features will start to appear that will give developers access to the underlying OS.
In short, by 2012 the concept of IaaS and PaaS will disappear, and IT professionals will discuss the more generic feature offerings of each cloud vendor.

Monday, January 31, 2011

3 quick ways to reduce your Amazon EC2 cloud charges

The biggest difference between standard web hosting and cloud-based hosting can be seen when you get the monthly bill. A standard web host, like GoDaddy, will charge you a flat monthly fee and give you access to a single, fixed server. Whereas a cloud-based host, like Amazon EC2, will charge you at a granular level for each compute asset you use, whether it's bandwidth, CPU or storage. This can lead to a confusing monthly bill (ever tried to use Amazon's "simple" cost calculator?), but also to opportunities to save money by being more astute with your resource utilization.

I have now been running my business on EC2 for 6 months, and was able to cut my monthly charges by almost 80%. How? Just follow these 3 easy steps:
  1. Be prudent with what you consume. Cloud providers will charge you for exactly what you use. So unlike with standard hosting, it actually pays to be frugal and to use less. Consume less and pay less. You will see an immediate reduction in your EC2 bills if you:
    • Ensure your server is being frugal with bandwidth. Cache images client-side with long expiry times, gzip the content you publish and use CSS sprites for image delivery. Just enabling these 3 attributes on your server can save huge amounts of bandwidth and this will be reflected in your costs.
    • Use smaller servers that cost less per month. Most developers come from the mindset that the infrastructure is fixed, and therefore you should select infrastructure that will last you several years. But the advantage of cloud computing is that you can upsize your servers on-demand. Use the smallest, weakest server you can find, and scale it up only when you start to max out your CPU capacity (use Amazon Cloudwatch to notify you of high CPU loading).
  2. Lock in your servers. If you are using Amazon EC2 then you are likely using it for the flexibility of scaling your front-end infrastructure. More customers -- no problem, just add another front-end server to take that load. But certain assets, like your database server, will likely be untouched for years, needlessly accumulated on-demand Amazon charges. Move your fixed assets from on-demand pricing to Amazon's reserved instance pricing. This simple pricing change, enabled by a tick-box in the EC2 console, can save you almost 50% on your annual server costs.
  3. Re-evaluation your application needs. Many developers migrate existing in-house solutions and continue running them in the exact same state in the Amazon cloud. But cloud penalties are heavy when costly licenses are involved (ie. Windows SQL Standard is significantly more costly than SQL Express, which is itself more costly than Amazon RDS). Those licenses you own in-house for MSDN don't migrate with you to the cloud, so make consideration for a re-architecture as part of your move.
Note that LabSlice now offers consulting services for EC2 migration: http://LabSlice.com/Contact.


Wednesday, January 26, 2011

Would a cloud by any other name sell as well?

My last blog entry 'does Gartner understand cloud computing' generated a lot of interest, especially in the twitter-o-sphere. This was no surprise, as opinions about this space tend to be very mixed. More so, I suspect that there is frustration with vendors, as your average 'web application' gets rebranded as a 'cloud application' and pitched to IT managers as the coolest thing since SOA, Agile Progamming, UML, <other technology hype>. Senior IT professionals really just want to understand what cloud is, without the hype and without any sales pitch.

So to be fair to Gartner, I thought I should take an attempt at my own definition of cloud computing:
"Cloud computing is defined as a self-service environment for the immediate provisioning of platforms and applications, with billing being based on granular usage consumption metrics."

Take a look at the key attributes: self-service, immediate, granular billing. These attributes are really the main difference between cloud computing and any other technology. It's the reason why having a web server is so 2000, while running a server on Amazon's platform is so 2010: Amazon allows you to spin up images by yourself, makes them immediately available and will bill you for CPU, bandwidth and storage on an hourly basis. These limiting attributes are also the reason that cool new technologies can be implemented, such as the LabSlice virtual training environment - pull down training images on a need-be basis and pay solely for usage of the machine on an hourly basis. Very different from the old model of purchasing servers, deploying them in-house and then paying on an ongoing basis for hardware maintenance, usage and upgrades.

The next time a vendor pitches you a cloud solution, ask them the following:
  1. Does your your product offer self-service functionality to each and every one of our employees?
  2. Is your solution immediately available to be used by each and every one of our employees?
  3. Do you offer granular billing, so that we can pay you solely for what we consume?