My name is Nathan, and during my summer internship at Snapsheet, I had the opportunity to learn and work with AWS tools in the IT team.
For developers, server administration is that annoying barrier between the code and the running product. Coming from a development and Linux server administration background, I was familiar with this setup. And while managing a server can be fun, it can be tedious to manage large-scale applications.
As I started to use AWS, I realized its benefits for scalability and peer review of software stack design. Using AWS came with some downsides, which I had to weigh compared to the merits of traditional server administration.
Scaling: The Problem of Multiple Servers
For small applications, setting up a single server is no big deal! Installing GNU/Linux and setting up the application is no big deal! It is not feasible to set up new hardware, install OS, set up remote access, logging, and a firewall to scale an application as traffic grows and fluctuates.
Make it someone else's problem: * as a Service
The way to make scalable software is to make the scaling part someone else’s problem. First, Infrastructure as a Service (IaaS) providers take the responsibility of managing server hardware. A system administrator would still need to set up the operating system and associated programs but no longer needs to order, set up, and maintain the hardware.
Going further, AWS and other Platform as a Service (PaaS) providers increasingly take more server responsibility. They do this by managing the operating system and system software themselves. Using a service like Fargate, an administrator provides a container image and configuration, and AWS manages everything from the hardware to the container engine. Using Lambda, they handle even the runtime environment, leaving only the source code or compiled binary for an administrator to worry about.
This increasing shift of responsibility to a provider like AWS means that a developer can focus much more time on the programming instead.
CloudFormation: The Ctrl+C, Ctrl+V of Resources
As I was getting used to working with AWS, a resource I came to enjoy was CloudFormation which allowed me to set every aspect of my Lambda and S3 bucket’s settings in a file. The benefit I realized this provided was that the software requirements for the stack could be documented and peer-reviewed just like any other source code.
CloudFormation also provided a seamless way to create identical software stacks for production and development environments, allowing greater ease and accuracy in testing.
Doing Things AWS’s Way
The scaling and review benefits of AWS do have their downsides. Writing code in AWS comes with the caveat of writing code using their tools and their way. Unlike traditional Linux servers, where most software is standardized and interchangeable, AWS uses its own API, which developers will need to hook into to leverage some features, especially the further AWS’s responsibilities reach. For example, while writing a Lambda to listen to an S3 bucket, I hooked into their API to process the event and access the bucket when needed.
Which Service Again? The Complexity of AWS
I enjoyed working with AWS, but it was not without complexity. There were many questions and thoughts running through my mind. Do I want to use Lightsail or EC2 resources? Do I want to use ECS or EKS? Should I use my own EC2 instances to provision ECS, or should I use Fargate? Or would it be best to go with Lambda instead? There are countless options to suit your needs, but they can be overwhelming.
My experience at Snapsheet using AWS this summer demonstrated the benefits it can provide for enhancing peer review and ease in scaling. While it has complexities and drawbacks, and experience in traditional operating system management remains valuable, AWS makes sense for many developers and businesses. What are your thoughts?
Author: Nathan Harmon, Software Engineering Intern