Appendix 3: Amazon Web Services

Does Amazon Web Services - Amazon's cloud computing platform - also deserve my "big tent" designation? Perhaps not. By any metric I can imagine, this is a tent that's far too large to pitch anywhere in the known galaxy. We're going to need a bigger metaphor.
What's this AWS all about? Here's how I describe it in my Learn Amazon Web Services in a Month of Lunches book:
Suppose you didn't want to purchase, build, and house all the expensive hardware you'd need to properly support your new e-commerce website. Perhaps you're not sure how successful the project will be, so investing heavily in server, cooling, and routing equipment doesn't make sense. But if you could rent just enough of someone else's equipment to match the fast-changing ups and downs in demand on your site and pay only for what you actually used, then it might work.
Is there anyone out there who might rent you this kind of stuff? Yup. They're called cloud computing providers. And Amazon's Amazon Web Services (AWS) is by far the most feature-rich and (generating nearly $12 billion in revenue in 2016) successful player in the market.
According to the research firm Gartner (http://mng.bz/31dr), AWS "has the largest share of compute capacity in use by paying customers - many times the aggregate size of all other providers in the market... It has the richest array of IaaS and PaaS capabilities. It provides the deepest capabilities for governing a large number of users and resources. It continues to rapidly expand its service offerings and to offer higher-level solutions."
AWS has proven itself capable of providing a secure and reliable hosting platform for both mission-critical (e-commerce, enterprise intranets) and compute-intensive (big data analytics, development environments) applications. Given its depth, if your project can be virtualized in one form or another then, according to Gartner, AWS is "the safe choice."
Ok. So how does it work? Well that depends on what you want to accomplish and how much time and energy you're willing to invest up front.
You see, it would be fairly simple to precisely replicate your on-premises infrastructure using AWS resources with a relatively soft learning curve. Basically, anything you can do on your own bare metal servers, you can do on AWS. Sometimes, it's even possible to create an archive of your application and databases and transfer them to the cloud with a single command.
But you won't always get the best bang for your buck that way. To really squeeze very ounce of value out of the AWS compute and database instances you provision, you'll usually need to reshape your application to take advantage of the cloud's built-in scalabilty and elasticity. Digging deeper, you might find that you don't even need compute or database instances, but can, instead, run your app in "thin air" - serverless.
This chapter won't even try to teach you how to do all that - read my Manning book Learn Amazon Web Services in a Month of Lunches book for all that stuff. Rather, I'll try to introduce you to the architectural principles that drive successful AWS workloads.
Read on.

Migrating workloads

An application server, when everything's said and done, is nothing but an application server. Slap some RAM, storage, a network interface, and an operating system on top of a healthy CPU and hit the power switch. Should you really care where it all happens to live?
An AWS account provides you with all the virtual compute instances you could want through their Elastic Compute Cloud (EC2) service. As figure 9.1 shows, you get to choose the pre-installed operating system you want to provision - or create your own custom machine images. You will also be able to set an instance type (the hardware profile you want to run), network environment, storage resources, and firewall settings (called a security group). Total time from start to launch: ~30 seconds when going with default values.
Select a pre-installed operating system image for a new AWS EC2 instance you can subsequently launch

Select a pre-installed operating system image for a new AWS EC2 instance you can subsequently launch

Once your server is running, you can access it remotely - usually via SSH - and set about getting your application going. Keep an eye on things during the testing/transition period to see what might need changing.
Simple servers really aren't at all difficult to build. But optimizing more complex infrastructure is a bit of a science.

Refactoring and optimizing cloud workloads

Figuring out how to effectively tweak your cloud-based resources requires a solid understanding of two sometimes misunderstood concepts. This should help:
Elasticity is a system’s ability to monitor user demand and automatically increase and decrease deployed resources accordingly. This quality is a big part of cloud computing’s secret sauce, as it’s what lets you design and deploy an application. You can be confident that the cloud provider will invisibly provision or retire resources according to need, ensuring that you never get stuck with the bill for unused services.
Scalability describes the way a system is designed to meet changing demand. That means the underlying design supports rapid, unpredictable changes. As an example, software that’s scalable can be easily picked up and dropped onto a new server - possibly in a new network environment - and run without any manual configuration. Or, in other words, the composition of a scalable infrastructure can be quickly changed in a way that all the old bits and pieces immediately know how to work together with the new ones.
To function as true cloud-native applications, your code needs to understand the automated nature of its environment and be able to instantly adapt to changes.
On AWS, this might include deploying your servers behind an Elastic Load Balancer (ELB). The balancer directs incoming requests to instances running in as part of an Auto Scaling group. The group, in turn, automates the process of modifying the number of running instances up and down to meet demand. Figure 9.2 shows the Policy page, part of the Auto Scaling configuration process. Here you define events you want to trigger the launch of a new instances. In this case, when existing servers reach 80% CPU capacity, another one will be started.
A scaling group will automatically launch or retire pre-configured instances according to changing demand

A scaling group will automatically launch or retire pre-configured instances according to changing demand

Serverless workloads

Serverless? What can you do without a server? Nothing, actually. But rather than renting an entire virtual server instance they way you would through EC2, in the "serverless" world you rent just a second or two of time on one of AWS's own servers. Since the mechanics of the whole thing are less visible, we call the process "serverless."
The primary AWS implementation of serverless computing is called Lambda. It currently lets you create functions in Node.js, C#, Java, and Python. Lambda is deeply integrated with a wide range of AWS services - both as triggers to invoke and Lambda function, and as resources to be used as part of a function.
The AWS Lambda intro page. That Run button will actually fire up a live function

The AWS Lambda intro page. That Run button will actually fire up a live function

The idea is that events happening in other AWS services can be configured to trigger the quick execution of a function using only the bare minimum of cloud resources needed to spawn an action. The classic example to illustrate the way it works is the old generate-a-thumbnail-from-an-image-file trick; and really, who doesn't need to generate thumbnails from images every now and then?
Here's how it goes: whenever a customer of your online image storage business saves a photograph to your S3 bucket, a Lambda function springs to life, creates a small thumbnail version of the image, saves it to a second bucket, and associates the two images so the thumbnail will appear as a link to the original in website displays. You don't need to run (and pay for) an entire EC2 instance 24 hours a day just in case someone's wedding photos show up. Instead, you run exactly what you need, exactly when you need it.

Wrapping it all up

So that's serverless computing, AWS, big tent technologies...and the whole range of tools and tricks for successfully achieving all of your learning goals. My bit's done now.
But I invite you to pick up where I've left off. Do you see something I've missed or a mistake, large or small? Please let me know. The internet is only as useful as all of us together decide to make it.
Know someone who might like this book? Please pass it along - either a digital or printed version. Want to share your thoughts about the book? Consider writing a review on Amazon.
And be in touch. Don't be a stranger.
David Clinton
bootstrap-it.com
office@bootstrap-it.com