Something that amuses me is the fact that 80% of so-called “Introduction to AWS” stuff is mainly geared at EC2. While I don’t have any problem with it, I think they’re missing the main point in Cloud as a full stack platform, which is to manage more and maintain less.
Let me explain this further: I’m a huge fan of NoOps, even before the name was coined. What we’ve learnt from using AWS Services like S3, Dynamo, and the SNS/SQS Sisters, is that managers actually LOVE not having to consider additional servers to maintain. But how did we get to this point?

In the Beginning…

My first official job, back in 1999, was to maintain servers for an ISP. Back then, I had to directly manage several services into a single machine. Virtualization only became a reality around three years later, but was still relegated to desktop. At that time, managing resources was a pain, since we had quite a “fixed” platform, with few features to help.
This also meant that replacing services, in fact, needed a new server and that also required a very detailed plan to move services around.

Four Years Later, on another ISP

Four years later, we started to have VPS services. That brought a shift: Having a set of smaller servers running under a Hypervisor, and having automated backups, brought us less costs and more manageability. At that time, we could have more environments and stage upgrades and deployments. In fact, we ran three servers; one for Staging and the others for doing failover.
If you look at a specification of a machine around 10 years ago, and compare it with some AWS Instance Types, you’ll notice that CPU processing and memory are quite equal, but storage is cheaper.

My First Law for Virtualization

It is just a personal observation, but it is worth a point to enunciate it as a law:
Since 2000, mostly all kinds of server-side services kept stable amounts of memory. This is based on empirical evidence, of course. However, this led to something interesting. Since the memory requirements are stable, but machines get bigger, what to do? Exactly, and so the next wave began

The Appliance

Once costs were reduced, and requirements settled, it became natural to think about appliances.
An appliance could be defined as a Virtual Machine built in order to focus on only a single service. As such, it became easier to create multiple instances of the same server, and now failover and replication became concerns. At the same time, redundancy was no longer a huge problem. It also addressed the need for different environments.

The Cloud

Cloud was just the next logical step once we reached Virtualization. Basically, this means the provisioning, on demand, of resources while mixing some Appliance Concepts, in particular:

• Appliances are Setups (either Physical or Virtual) optimized for offering just a single service
• It can add Vendor value-added features, like a Tuned Environment, as well as Managerial Add-ons (A Console, Agents)
• They’re meant to be easy to upgrade and/or thrown away

NoOps Offerings

Let’s try to build a common taxonomy for NoOps Offerings. This is empirical evidence, and I haven’t seen a common definition somewhere else, so let’s try and build a model:

• Fully Managed Service: The Service is a Black Box, and you have a console for managing it. Almost all of AWS Offerings are based on this model, including S3, SNS, SQS, SimpleDB, DynamoDB. You pay by several combined metrics (number of requests, storage used, unique hours);
• Turnkey Blackbox Appliance: It’s a Base Virtual Machine, but you’re not supposed to log in to it (although you can, save notable exceptions). Most of the AWS “Elastic” Family of Services (Elastic Beanstalk, Elastic MapReduce, and ElastiCache), as well as part of the AWS Marketplace Offerings. You pay basically by the normal EC2 Hours + a premium value-added fee. You are likely to have a Console;
• Turnkey Appliance: It’s a Base Virtual Machine, and you can actually log in to it. You’re responsible for most of the tasks (and most likely No Console Services), and you pay the normal EC2 Usage Fees. Examples include the base Amazon Linux, and the Internet Gateway for Amazon VPC. Some OSS Vendors might also offer versions of those kinds of Appliances, but in most of the cases, you’re bound into only a few Cloud Providers;

This model is not limited to AWS Products only. For instance:

• Fully Managed: PiCloud are fully managed services
• Turnkey Blackbox: The Cloud Database from EnterpriseDB, is such an Example
• Turnkey Appliance: The Ubuntu VMs are offered in this model

Choosing a NoOps Approach

NoOps is great when your core skill is based on developers, but this is not an excuse to adopt it right away. Some concerns about NoOps adoption will be discussed in the next part of this series. Stay Tuned.
About the Author

Aldrin Leal, Cloud Architect and Partner at ingenieux
Aldrin Leal works as an Architect and QA Consultant, specially for Cloud and Big Data cases. Besides his share of years worth between the trenches in projects ranging from Telecom, Aerospatial, Government and Mining Segments, he is also fond with a passion to meet new paradigms and figure a way to bring them into new and existing endeavours.
Contact Aldrin
This post was cross posted on Newvem.com