Tag cloud computing

Entries 5 Total

Copy, Paste, Cloud

Mar 1, ’11 9:00 AM

One of my favorite features of EC2 is the ability to create virtual machine templates and re-use them to create fresh copies of a virtual machine. This is great but things rapidly get onerous when you’re trying to duplicate infrastructure.

Amazon recently unveiled a new service called AWS CloudFormation. There are currently many Amazon cloud offerings available: S3, Elastic Block Storage, EC2, and Elastic Beanstalk are just a few. AWS CloudFormation is more than just another member of the family: it ties them all together.

The idea behind AWS CloudFormation is to make it easy to create a collection of AWS resources and then deploy them the same way every time. AWS CloudFormation is similar to using Chef recipes to deploy software configuration. In this case we’re deploying an entire infrastructure stack to multiple virtual machines via a recipe. We can design our infrastructure on AWS. As our business grows we will be able to quickly and easily duplicate crucial parts of our infrastructure.

AWS CloudFormation makes it simpler to manage all of your infrastructure. Deployments of new infrastructure become a matter of pushing out a template. If there are problems with a deployment, the changes can be rolled back and a clean up happens to make sure you aren’t charged for anything that you’re not using.

Deployments

In a traditional IT department, there is a design, purchase, deploy cycle that can potentially take a very long time. In previous jobs, we’ve had to design the infrastructure based on obscure internal capacity planning metrics. Once we’d made predictions/guesses about our future growth, we would then wait for weeks or even months to acquire new hardware. Once we had the hardware, it might even sit around for days or weeks before we were finally able to provision, configure, and deploy the servers on the network. That doesn’t even include deploying our own software on the server.

On the flip side of that coin, by combining AWS CloudFormation plus Chef/Puppet, we can now push a new batch of servers out into the cloud in a matter of minutes and have them running in a few hours. Our software can be automatically installed and configured with Chef or Puppet. While we still need to write templates, once we’ve created and tested our templates for specific purposes (blog, database, community site, whatever), we’re able to fully automate deployments.

Scaling Out

AWS CloudFormation can also ease the pain of scaling out our applications.

Typically when we scale out an application, we’re starting from a monolithic application stack. All of the assets in our stack have been scaled up to a point where it’s cost prohibitive to keep scaling. At this point, we’d examine each layer of our application and determine the best place to add caching or scale out to use multiple application or database servers. As we keep scaling our stack, we need to add more load balancers, caching servers, and database read slaves until we’ve exhausted our options and have to revisit our application design.

Rather than engaging in the exercise of attempting to scale all of our customers at once, why don’t we start out by sharding all application resources at the customer level? While this increases the overall cost of operating our business, it makes it easy to scale elastically in response to a changing customer base. The busiest customers will get larger servers and increased performance that meets their needs. It also becomes possible to locate our data close to your customer in one of several Amazon zones.

For businesses offering software as a service, this makes a great deal of sense. They get an easy way to monitor usage per customer and can scale appropriately within known guidelines and with well known costs.

Wrap Up

AWS CloudFormation makes it possible to provision and deploy infrastructure using a set of templates. When you combine CloudFormation with Chef or Puppet, it becomes very easy to deploy infrastructure and then deploy additional configuration changes on top of the infrastructure. Ultimately, AWS CloudFormation makes it easy to quickly and easily deploy new infrastructure in response to changes in load or customer demand.

If you’re interested in some of the discussion around AWS CloudFormation, be sure to check out the Hacker News thread on the subject.

Comments (0)

What You’re Missing About Stateless Computing

Dec 29, ’10 9:00 AM

Once, long ago, men carved their knowledge into the walls of caves so that it would be available for all time. Unfortunately, their knowledge was tied to once place. Eventually, a forward thinking cave dweller thought about carving his knowledge into a clay tablet. He was savagely beaten to death and his family burned as witches. Eventually the other cave dwellers realized that it was probably a good idea to have a more portable way to store their knowledge and they too adopted this portable clay-based knowledge transfer system.

Fast forward to the tail end of 2010 and people are saying that Microsoft has got it wrong with the Azure VM role. People are already lambasting it as a laughable concept that’s needlessly complex to patch. I can’t argue with that, it is complex to patch, but there’s a reason for that complexity and it’s called stateless computing.

It’s like the switch from procedural/object-oriented programming to functional programming. When you first switch, you get pissed off that you can’t reassign variables and that functions can’t have side effects. You get used to that pretty quickly and start doing crazy things with tail recursion and other functional paradigms that ultimately save you memory. remove debugging headaches, and give you an incredible amount of computing stability.

With the last paragraph in mind, let’s look at Azure VMs again – we can’t patch the VM directly. It’s stateless. What does a stateless VM buy you?

  • It’s easy to spin up additional, identical VMs. There’s no worrying if some master image is the same: it is.
  • It’s easy to back out incompatible patches – just remove the differencing VHD.
  • There are no side effects because of errant garbage living on the C: drive.
  • Security – if a virus infects your VM, just reboot.
  • Complex, time consuming patches can be applied once and quickly moved into place.
  • There’s a load balancer in front of every Azure instance. Operations must be idempotent, even when executed against different instances.

Managing state isn’t a component of your operating system in Azure, it’s a component of the storage tier. New paradigms require new ways of thinking. Sometimes a new way of thinking seems broken, wrong, or foolish.

If you’re looking to customize your Azure deployment stack without sacrificing the flexibility of using Azure, then Azure VM roles are for you.

If you’re looking for a replacement for your current VM Ware installation, Microsoft’s Azure VM roles aren’t for you. But while you’re fiddling around with VM settings, I’m going to be playing Scrabble. 

Comments (4)

Thoughts on Free Amazon Web Services

Oct 25, ’10 10:36 AM

Last week, Amazon announced that we could all get some free AWS if we signed up for a new account. Just what do you get for signing up? Take a look.

What you get with the AWS Free Usage Bundle

The First Catch

First off, this is only free for the first 12 months. After that you’re going to have to pay as you go.

In a way, this is like Microsoft’s BizSpark, but in the clouds. You get to ride a long for free, for a while. After that while, you’re going to have to pony up some money to keep riding. Nobody said it was free forever.

The Second Catch

Let’s say you start out with your free AWS account and you build an application to help manage your yarn collection. You write some code and you’re happily trucking along. One day you decide to share the link with a few friends who are also really into knitting. The next thing you know, everyone is using your yarn tracking website. This is great, right? It is great… until the bill shows up.

The free AWS only lasts for 12 months. Or until you exceed your service levels. Whichever comes first. Unless you have definite plans to monetize your service, you will need to carefully monitor your application load.

What Do You Really Get?

So what are you really getting for free? We all know that nothing is free, so what makes Amazon’s deal noteworthy?

The Server

You get a virtualized server with 613MB of memory. That barely sounds like enough to power your microwave, but in the world of Linux servers, that may be more than enough for your website. Even if it isn’t enough horsepower for your production application, it’s enough to develop in a realistic environment and deploy to your first round of beta users.

The Load Balancer

Once you’ve got more than a few users, you might need to move beyond that tiny 613MB server. Or you might shard your application out. Or you could use it to help you manage your fault tolerance. There are a lot of reasons to use a load balancer.

Amazon has been thinking of you and you get 750 hours of their load balancing service free. Per month. 750 hours is 31.25 days. You can’t use all the free that you get. It’s just that free.

There is a limit on the amount of free traffic that the load balancer will handle, but that should encourage you to keep your apps lean and mean, right?

Storage

Free storage! 10GB of Amazon Elastic Block Storage sounds like 10GB of free something or another that I don’t know about. Reading the documentation doesn’t clear this up. Basically, you get free magical storage that you can format however you want and attach wherever you want in your Amazon virtual server farm. You can even take point in time snapshots of these storage devices so you can revert your storage to a known good state. That’s pretty cool, eh? Try getting your SAN administrator to let you do that.

More free storage! Five gigs of Amazon S3 is a lot of S3 storage. I use S3 to host large files that I don’t want to upload through WordPress – video, PDFs, and presentations. It’s a great way to add a lot of hosting to your free or cheap hosting account. Likewise, it’s a great way to add storage to your free AWS instances and remove some load from your virtual server. On the down side, it does look like you’re going to pay for the traffic that your readers consume. But, hey, you already counted on that, right?

Even more free storage! 1GB of SimpleDB storage! SimpleDB is a distributed database with a few limitations. Despite the limitations, it’s a sold platform for developing web-based/cloud applications. You can access the database from just about anywhere and it should be available as long as Amazon’s servers are up and running. And you had better believe that Amazon is going to stay up and running.

Bandwidth

Surprise! You get 30GB of free traffic a month. Well, 15GB up and 15GB down. But it’s sort of the same. I think. Maybe? The point is that you get some free bandwidth. Bandwidth can get pricey which makes any amount of free bandwidth a good thing.

Implications For Your Design

With a hard cap of 15GB on your traffic, you’ll want to make sure that you’re using images that are as compressed as possible, minified CSS and JavaScript, clean HTML source code, and lean protocols. You’ll want to be careful in development and make sure that you’re only pulling back the data that you need and nothing more, and that you make as few round trips to the server as possible. Of course, you were doing all of this before, right?

Putting it All Together

The free tier of AWS is a good introduction to working with AWS. It provides more than just a simple virtual machine, it provides an entire infrastructure to get you started. You can rapidly build out from a single to server to a large number of servers and still use most of these free services. If you don’t need something, you’re not going to pay for it. This is a lot cheaper of an option than buying your own hardware or trying to work within the confines of a hosting provider. This is your own virtual hardware to develop with as you please.

One more thing – Amazon may stop accepting new people into the magical free AWS tier at any moment. Act now, supplies are limited.

Comments (0)

Would the Fastest Cloud Please Step Forward?

Aug 2, ’10 8:32 AM

Not so fast, there, buddy.

CloudSleuth has released a new tool that allows users and customers to see how the different cloud providers stack up. As of 6:45 PM EST on August 1, Microsoft’s Azure services come out ahead by about 0.08 seconds.

0.08 seconds per what?

Turns out that it was the time to request and receive the same files from each service provider. Is this a meaningful metric for gauging the speed of cloud service providers? Arguably, yes. There was considerable variance across the different cloud providers, but that is also to be expected since there are different internet usage patterns in different parts of the world.

More importantly, using speed as a metric points out something much more important: As we develop more and more applications in the cloud, we will need new benchmarks to determine the effectiveness of an application. We can no longer just look at raw query performance and raw application response time. We need to consider things like global availability and global response times. In the past, we could get away with storing data on a remote storage server and caching commonly used files in memory on our web servers or in a separate reverse proxy server. Moving to the cloud makes it more difficult to accomplish some of this advanced performance tuning. Arguably, our cloud service providers should be handling these things for us, but that may not be the case.

With the proliferation of cheaper and cheaper cloud based hosting (did you know you can host basic apps for free with heroku?) the problems that used to plague only large customers can now bother smaller customers. As soon as you begin distributing data and applications across data centers, you can run into all kinds of problems. If you are sharding data based on geographic location, you may have problems when a data center goes down. Worse than that, because you’re in the cloud you may not notice it.

This isn’t meant to be fear mongering, I’ve come to the conclusion that the cloud is a great thing and it opens up a lot of exciting options that weren’t available before. But moving applications into the cloud caries some risks and requires new ways of looking at application performance. Latency is no longer as simple as measuring the time to render a page or the time to return a database query. We need to be aware of the differences between different cloud providers’ offerings and why performance on one provider may not directly equate to performance with a different provider.

Comments (0)

T-SQL Tuesday 4: Io, Io, it’s off to disk we go

Mar 9, ’10 7:47 AM

Fact: the earliest recorded use of cloud computing was ancient Greek porn

Io was a nymph. True story. Apparently, her father was some kind of river god. In modern times that means you’re likely to catch fire. Back in the days when the Greeks were in charge of things being a river god meant that you were somebody (the Greeks thought the earth was a giant brass plate floating a huge river, all of which was created by perverts who lived on top of a mountain). So, apparently Io’s dad was important.

Anyway, it is rumored that Io was attractive. So attractive, in fact, that Zeus, lord of the perverts, saw her taking a bath and got more than a little bit aroused. Zeus then behaved in a way that would end up in a savage beating and restraining order back where I come from – he pestered Io for nookie until her father drove her out of the house – probably because some horny lunatic who could shoot children out of his forehead was bothering his daughter. Io, being a bit strange in the head, relented. Or something. My records aren’t 100% clear seeing as how they’ve been written on pottery. The point is that Zeus turned into a giant cloud and turned Io into a cow (no, your hooves don’t make you look fat).

Somehow Zeus’s wife got involved and there was bondage involving a cow tied to a tree or something. Eventually Io gets turned back into a real live girl and gives birth to Zeus’s son. Which brought about an ethics probe into cross-species cloning.

Disk… disk… oh yeah I already mentioned that the ancient Greeks were clearly insane and thought that the world was a giant metal plate floating on a huge river name Oceanus all of it encased in a hemisphere with clouds and the sun and the moon and stuff painted all over the inside of the hemisphere.

What’s outside of the hemisphere? Shut up, that’s what. It’s turtles all the way down.

There’s a bit of humor thrown into your T-SQL Tuesday

Comments (6)

This site is protected with Urban Giraffe's plugin 'HTML Purified' and Edward Z. Yang's Powered by HTML Purifier. 226 items have been purified.