Storage
Mobility
Protection
Analysis and control
TOPICShare
Subscribe to our blog
Thanks for subscribing to the blog.
January 7, 2015
Topics: AWS3 minute read
In the beginning there were mainframes…. Then along came zones… and some people decided that everyone should have their own hardware. This trend continued until one day, we went back to the mainframe idea. Applications went from being tied to a single piece of hardware to floating in the magical ether of the cloud. Once again, life made sense?
When we consider this trend of virtual servers, it is important to think about how the tech world is evolving around us. Traditional servers would take weeks to months to provision and build but now, we are talking about ecosystems in minutes. I want to dedicate this part of the series to talk about these virtual servers. More importantly, I will discuss how AWS helps you create rapid server farms.
Amazon Elastic Compute Cloud
The best place to start is to define the virtual server. Amazon calls their virtual servers (machines) Elastic Cloud Compute (EC2) but don’t let the name confuse you. A virtual server is basically the combining of virtual objects to create a server. Instead of buying a chassis, motherboard, processors, etc, a virtual server leverages chunks of existing physical hardware. Ok, bare with me, I am getting there.
AWS makes it very easy to pull from the vast catalog of configurations. What type of system would you like; the amount of RAM; the size of the boot device; need an extra NIC? These are options as you walk through the Instance deployment wizard. The interest aspect is that it is very simple to plug in or remove components. Entire servers can be upgraded from a single core with one NIC to 16 cores and twelve new IP addresses... with just a simple reboot.
There are several important factors to remember when building your EC2 instances:
- Flexibility comes at a cost – there are base prices for instances but changing the configurations can become costly. AWS charges for most resources by the hour but don’t forget about ingress & egress of the network (We will dive into that in a later part).
- Servers aren’t always meant to be persistent – the reality is that servers are a dime a dozen and applications can be rolled out quickly. Many administrators create elaborately automated deployments so that they simply have to click a button to replace a server.
- High Availability can be a challenge – redundancy of your environment can become very tricky. AWS block storage (Elastic Block Storage – anyone notice a trend here?) is dedicated to a single EC2 instance. This is very challenging for the Enterprise Admin because we are use to creating shared file system clusters. Applications must be tuned to replicate the data across multiple systems.
- Backups require some thought – Amazon’s position on how to protect your applications is to leverage a combination of their EBS snapshots but store your important data backups in S3 (Simple Storage Service). There are some really great applications out there that help you copy data from your EC2 instance into an S3 bucket (Don’t worry, we will go into more detail on S3 later). This model is very similar to the old way of backing up to a NAS share in the datacenter.
So the real question is how do we tackle this new concept of ephemeral virtual servers? What is the difference between EBS and S3 and when do you use it? In my next entry, we will take a look at how storage evolves in this cloud ecosystem.
Other articles in this series
