If you’re just joining this column, it is one aspect of a response to the gap between how development and how operations view technology and measure their success – it is wholly possible for development and operations to be individually successful, but for the organization to fail.
So, what can we do to better align development and operations so that they can speak the same language and work towards the success of the organization as a whole? This article series attempts to address a portion of this problem by presenting operation teams insight into how specific architecture and development decisions affect the day-to-day operational requirements of an application.
I’m starting a new series this week about containers. In this first article we start by reviewing Amazon Web Services (AWS) and discuss why it is a game changer!
Introduction to AWS
Several years ago, Amazon introduced a set of services under the umbrella of Amazon Web Services (AWS). AWS provided a low cost set of services that included things like the following:
- Elastic Cloud Compute instances (EC2): these are virtual machines that run in Amazon’s cloud with a monthly charge by the hour
- Simple Storage Service (S3): provides developers with secure, durable, highly-scalable object storage that can be used with a monthly charge by the gigabyte
- Simple Queue Service (SQS): a fast, reliable, scalable, fully managed message queuing service with a monthly charge by the request/message
- Relational Database Service (RDS): a scalable relational database that runs in the cloud with a monthly charge based on hourly usage and storage capacity
- DynamoDB: a NoSQL database that supports document and key/value models and single digit millisecond latency; DynamoDB is charged based on reads and writes
And there are lots more, especially in all of the tooling to support these services.
Having tried to build a company in the early 2000’s I was well acquainted with the cost of servers and setting up a proper server environment, so when I heard about the ambitious efforts of AWS I was flabbergasted. In practical terms, AWS means that new companies can compete head-to-head with large companies, without having deep pockets, and existing companies can launch test initiatives, without needing to secure large amounts of funding.
AWS allows you to start up a set of EC2 instances, deploy applications to them, connect to a hosted database and leverage SQS for messaging, all for maybe a couple hundred dollars a month. And, if your ideas are well received and you start making money, you can scale up by adding additional resources (more EC2 instances or bigger EC2 instances).
Before getting into the details of AWS, it would be worth a quick excursion to discuss what is meant by “elastic” when we say “Elastic Cloud Compute”. In this vernacular, elastic means that your environment can grow and shrink depending on usage. For example, if you need 10 servers to satisfy your load or if you need 100 servers to satisfy your load, you can dynamically adjust your environment.
This does require some care in properly designing applications to run in an elastic cloud, but if you design your applications properly then you can not only manage your user load, but you can also manage your expenses. Amazon charges you based on the number of hours an EC2 instance is running so if you know that you have periods of low activity then you can scale your environment down to save money and then scale back up when user demand increases.
Amazon Machine Images (AMI)
This article series is about containers, so we’re going to focus primarily on Amazon’s EC2 services. EC2 allows you to search for a machine image, or Amazon Machine Image (AMI) in Amazon terms, which is preconfigured virtual machine. One of the most common places to look for AMIs is in the Amazon Marketplace:
If you peruse this web site, you’ll find all varieties of Linux servers and distributions and a select set of Windows images, but more importantly you’ll find images preconfigured with software that you might want to use. For example, if you choose Software Infrastructure → Application Servers then you’ll see options such as:
- LAMP stack (Linux, Apache, MySQL, PHP)
- MEAN stack (MongoDB, Express Web Framework, AngularJS, Node.js)
- Cold Fusion
You can also find preconfigured infrastructure applications like Cassandra, Solr, MongoDB, and more. The point is that companies have taken great care to preconfigure, and in some case sell, AMIs, which allows you to get an environment up-and-running fast.
If you want full control over your AMI, you do have the option of building one from scratch, or you can find a base operating system image, such as a Fedora or Ubuntu image, and then customize it to your liking. Once you have it customized, Amazon provides a mechanism to allow you to take a snapshot of that instance to create a new AMI from that snapshot.
This allows you to start from an image at the granularity you’re comfortable with and customize the image to do exactly what you want – and then start from that image in the future.
For example, one of the things that I have done in the past was to start from a Fedora base image, install Java and Tomcat, and setup a service to automatically start Tomcat when the operating system starts. I snapshotted this image and used it as a starting point for setting up my applications.
Here was my process:
- Start this image
- Deploy my Web Archive (WAR) file to Tomcat
- Create an application-specific AMI for this component of my application
With this image I could start one, ten, or even one hundred instances to satisfy user requests – it made scaling easy. This was a simple strategy before the Amazon Marketplace had so many preconfigured options to choose from!
It is important to note that AMIs do not maintain their state between restarts. The image can be thought of as a template or even as the state of a virtual machine at a point-in-time. The act of starting an AMI is, in reality, creating an instance of that AMI, see figure 1. You can use that instance, its local storage, and it services, but as soon as you shut it down, that instance is gone.
If you later restart that AMI, its state will still be the original point-in-time that it was captured. Or stated another way, it will not maintain the state of your running services and local storage.
Figure 1 AMI Instances
With this limitation, how do you run software that depends on maintaining state, such as a database? The answer to this is that you need to add persistent storage to your AMI instance. Amazon defines a type of storage called an Elastic Block Storage (EBS). You can add an EBS volume to your AMI instance and then configure your applications to write to that volume instead of the local file system.
When you shutdown an AMI instance and create a new instance, you can simply reattach and mount that volume to the new instance and continue with your stateful data. This is shown in figure 2.
Figure 2 Leveraging an EBS Volume for your stateful data
As you might surmise, this model is a bit different from traditional virtual machine management, but is consistent with the container paradigm:
- Containers define the template or point-in-time state of a virtual machine
- Starting a container creates an instance of that container
- If you need persistent storage, then that storage needs to be attached to the instance
- You setup/configure your instance and then add it to your load balancer for load distribution
This change in paradigm from dedicated virtual machines that maintain their state to containers and container instances has afforded us flexibility and the ability to create and elastically scalable deployments.
We’ve gotten a good start here, and now that we have a fundamental understanding of how we are going to do things, the next step is to kick things into action! Join us for the next post where we deploy our new AWS application framework and see how easy it is once we have our conceptual understanding of what we need to do.