This blog post comes from my little brain-box as I was writing another post about Disaster Recovery.  I was exploring the idea of having cloud resources in different places, but quickly realised that isn’t an obvious or easy concept.  So today we’re going to talk a little bit more about how the cloud works, under the covers.  The bits that are often hidden from view.  If we understand how this all works, we can architect better cloud solutions.

Clever Software And DataCentres

We already covered the broad idea of What is the Cloud but we didn’t talk about the actual datacentres, and how they work together.  That’s what we are going to investigate today.

When all is said and done, if you want to run some compute work, like a virtual server, or some software as a service, you need a computer somewhere.  These computers are called servers, and they are just highly specialised machines running in a warehouse called a datacentre.  All of these servers are connected together in a super high-speed network, and connected to other datacentres similarly filled with servers.

That’s the datacentre bit covered, but that’s not all the cloud is.  The management of all different client’s workloads and tasks across all of these machines is the really clever bit.  Machines break all the time, but that won’t stop your cloud servers, because your work will move to another server which still works.  Cool eh!

Where Are The DataCentres?

Ooh, now there’s a brilliant question.  You’ve earned a gluten-free biscuit.  No, seriously, take one, I don’t like them.

As usual, we’re going to focus on AWS because that’s our favourite flavour of cloud provider, and the one we know most about.  AWS publish the rough location of all of their datacentres, but we need to understand a couple more terms before we look at that list.

Regions

In AWS parlance, a region is usually a country, or a state in the case of America.  The point is, a region covers a very large area.

When you plan your cloud environment, you will be thinking about where your users might be coming from.  It’s that kind of thinking which helps us understand a region.  For example, here in the UK, we have one region known as eu-west-2, and it’s in London.  But if most of your customers or users are in mainland Europe, you might want to look at eu-central-1, in Frankfurt.

Each region is connected to all other regions using super-fast dedicated fibre-optic links, which AWS themselves manage.  There are multiple links between each region, so much like the Internet, it can’t be disabled by losing just one or two of these links.

Availability Zones

An availability zone, or AZ, can be thought of as one singular datacentre – although they’re more like campuses really.  Each availability zone is capable of serving all the services available within that region.  At this point, it is worth remembering that not all services are available in every region.

If you can have Elastic Beanstalk in eu-west-1, Ireland, then the service can be fully hosted from any one of the three availability zones within that region.  It doesn’t matter which one you pick, they’re all exactly the same in terms of cost, performance and reliability.

Multi-Availability Zone

Now we’re really getting into how the cloud works, or rather, how cloud architecture works.  Like I said, each availability zone has a complete set of services running out of it.  Each availability zone is one building, or set of buildings at the same location.  So what if it floods?  Well, I can assure you that no cloud provider would build a datacentre on a flood plane, but it’s a valid question all the same.  The answer might shock you: everything stops.

If you architected your environment to only run from one availability zone, and that availability zone becomes, well, unavailable, so does your environment.  This is often fine, and can be good architecture.  I can’t remember the last time eu-west-2 went down, so I run this website from there.  If the availability zone does go down, yeah, my website will too.  But I don’t take payments from the site, and it’s not terribly high traffic either.  My backups are offsite, and I practice Infrastructure as Code, so I can spin up my server manually in another AZ really quickly.  This way, I save money by only running one copy of my webserver.

But what if, unlike us, you must stay online to survive?  This is where the idea of building multi-availability-zone, or multi-AZ, architecture comes in.  If you can’t afford to be offline, you need a presence in more than one place, so that if one AZ goes dark, your environment doesn’t!  It can carry on and swap the load onto the AZ which is still functional.

Cross-Region Replication

I think you can see where this is going.  If multi-AZ means that we have assets in more than one availability zone, then cross-region replication means that we then replicate across multiple regions.

Why would you do this?  Well not many people do really.  You really have to be at a huge scale to need the security of replicating your data across continents; or do you?

AWS S3 has cross-region replication baked right in.  It’s just a few clicks, and a tick-box away.  You only pay for the storage you take up in the two locations, plus the cost of sending any changes you make over the AWS fibres connecting the regions.  You could be talking pennies for small files.  So let’s take an example of a cryptographic secret.  Maybe it unlocks your bitcoin wallet.  (Yes, I know, don’t keep it online anywhere.  Print it out, keep a copy at Gran’s house, yadda yadda).  You need to be certain that if a war breaks out in the region you have stored that data in, you can still access it.  If you can’t you lose your life’s savings, and all it would have cost you was a few pennies.

For big business, it can be more mundane than that.  Imagine if a service like Netflix went down in Australia because routing in the ap-southeast-2 region went haywire.  It just cannot be tollorated for a company of that size.  So services might be redirected to one of the American regions, Canada or Japan even.  The show, quite literally, must go on.

And That’s How The Cloud Works!

So now you know!  Next time you’re talking to a cloud architect, you will understand exactly what you’re paying for, and just how secure your data is based on the decissions you make.

Of course we’re always around to have a chat about decissions like this, and we are often called in to just sanity check other people’s environments.  Feel free to talk to us today.