The traditional data center starts to disappear when going serverless. It’s a very elastic model—one where services spin up and down, always in response to the demand.
Much less time is spent logged in to a server, and instead, DevOps engineers spend most of their time writing API code to connect all the dots in their products. The fact that Linux runs everything underneath is sort of lost in the equation. There is less of a need to know or even care.
As one would expect, container technologies have helped accelerate cloud adoption.
Think about it. You have these persistent containerized application images that within seconds are spun up or down as needed and balanced across multiple nodes or data-center locations to achieve the best in quality of service (QoS). But, what if you don’t want to be bothered by all the container stuff and instead care only about your application along with its functions? This is where Amazon’s Lambda helps. As I mentioned in Part I, with Lambda, you don’t need to be concerned with the container.
Just upload your event-driven application code (written in Node.js, Python, Java or C#) and respond to events, such as website clicks, within milliseconds. Lambda scales automatically to support the exact needs of your application.
DEEP DIVE
As for the types of events (labeled an event source) on which to trigger your
application, or code handlers, Amazon has made it so you can trigger on website visits or clicks, a REST HTTP request to its API gateway, a sensor reading on your Internet-of-Things (IoT) device, or even an upload of a photograph to an S3 bucket. This API gateway forms the bridge that connects all parts of AWS Lambda. For example, a developer can write a handler to trigger on HTTPS request events.
Let’s say you need to enable a level of granularity to your code. Lambda accommodates this by allowing developers to write modular handlers. For instance, you can write one handler to trigger for each API method, and each handler can be invoked, updated and altered independent of the others.
Lambda allows developers to combine all required dependencies (that is, libraries, native binaries or even external web services) to your function into a single package, giving a handler the freedom to reach out to any of those dependencies as it needs them.
Now, how does this compare to an Amazon AWS EC2 instance? Well, the short answer is that it’s a lot more simplified, and by simplified, I mean there is zero to no overhead on configuring or maintaining your operating environment. If you need more out of your environment that requires access to a full-blown operating system or container, you’ll spin up an EC2 virtual instance. If you need only to host a function or special-purpose application, that is where Lambda becomes the better choice. With Lambda, there isn’t much to customize—and sometimes, less is good.
Storage
If you recall from Part I, in the cloud, multiple local volumes are pooled together across one or more sites and into a larger set of storage pools. When volumes are requested in block, filesystem or object format, they are carved out of those larger pools. Let’s look at some of these AWS offerings.
Elastic File System
The Amazon Elastic File System (EFS) provides users with a simplified, highly available and very scalable file storage for use with EC2 instances in the cloud. Just like with
DEEP DIVE
anything else offered by Amazon, the storage capacity of an EFS volume is elastic in that it can grow and shrink dynamically to meet your application’s needs. When mounted to your virtual machine, an EFS volume provides the traditional filesystem interfaces and filesystem access semantics.
To create a new EFS volume, select EFS from the main AWS dashboard and then click on the “Create file system” button. You’ll be directed to a screen where you need to configure your new filesystem. To simplify things, let’s select the same Security Group used by the EC2 instance from the previous example.
Next, give your filesystem a name and verify its options.
Once confirmed and created, you’ll see a summary that looks similar to Figure 8. Note that the filesystem will not be ready to use from a particular location until its “Life cycle state” reads that it’s available.
Figure 6. Creating a New Filesystem and Assigning It to a Security Group
DEEP DIVE
Figure 7. Setting a Name and Configuring Options
Figure 8. Filesystem Summary
DEEP DIVE
Using the same EC2 instance, install the NFS packages from the distribution’s package repository:
$ sudo apt-get install nfs-common
Before proceeding, you need to add NFS to your Security Group. This applies to both inbound and outbound traffic.
From the console of your virtual machine instance, mount the NFS filesystem:
$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=
↪1048576,hard,timeo=600,retrans=2 fs-05cb43ac.efs.us
↪-west-2.amazonaws.com:/ /mnt
Verify that the volume is mounted (note: in the last line below under Filesystem, the name is truncated so the output would all fit; that entry Figure 9. Adding NFS to Your Security Group
DEEP DIVE
should read fs-05cb43ac.efs.us-west-2.amazonaws.com):
$ df
Filesystem 1K-blocks Used Available Use% Mounted on udev 499312 0 499312 0% /dev
tmpfs 101456 3036 98420 3% /run /dev/xvda1 8065444 1266640 6782420 16% /
tmpfs 507268 0 507268 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 507268 0 507268 0% /sys/fs/cgroup tmpfs 101456 0 101456 0% /run/user/1000 fs-05... 9007199254739968 0 9007199254739968 0% /home/ubuntu/efs
And there you have it! An EFS volume is now connected to your EC2 instance, and you’re able to read from and write to it like any other filesystem.
S3
The Simple Storage Service (S3) supplies applications a front end to store and retrieve millions if not billions of data content from buckets at massive scale.
Traditional filesystems aren’t capable of cataloging such a large listing of data and, in turn, serve that data within a reasonable amount of time. Object storage solves that.
It isn’t a filesystem but instead a high-level cataloging system. When you PUT a file into your bucket, you do so with a tag ID. Then when you GET that file from the same bucket, you request it by the same tag ID.
At a high level, you don’t see how the data is stored or managed, and technically, you shouldn’t care. Each object storage solution has its own methods by which they save object content, and sometimes it’s as simple as saving each individual object as a file under a nested directory structure and on top of a traditional filesystem but then not making this visible to the end user or application. The application will access this data or bucket by using a REST API and communicating to the bucket’s endpoint over HTTP.
Amazon’s S3 API has become somewhat standard, and other object storage solutions
DEEP DIVE
maintain compatibility with this API alongside their very own. The motivation hopefully is to migrate those same AWS S3 users over to that other object storage platform.
Glacier
Amazon’s Glacier offers its users an extremely secure, durable and low-cost (as low as
$0.004 per Gigabyte per month) alternative to data archiving and long-term backup hosted on their cloud. It is a way for most companies to ditch their age-old and very limited local file servers and tape drives. How often has your company found itself struggling either to reduce the consumption or add to the capacity of their local archive system? It happens a lot more often than you would think. Glacier alleviates all of that headache and concern.