AWS & Serverless Architecture
This is a beginner’s guide to serverless architecture and AWS. It discusses what these terms actually are and explains how they are used. It does not go into use and deployment, but please check back for a future post on these topics.
What is “Serverless Architecture”?
For those who have only ever known a world in which an application can be “serverless”, it can be hard to pinpoint what exactly this means as it is such a common structure these days. It also can be hard to pinpoint because, in actuality, the name is not really an accurate descriptor. “Serverless” implies that the architecture is without a server, when really it just means that the server and all maintenance, provisioning and scaling that goes along with it, is not the responsibility of the app owner. Rather, the app owner has deployed the application using something like AWS, Azure, or Heroku (which also actually runs on AWS), which manages all things server and receives a fee for their services.
Using a serverless architecture has proved to be tremendously beneficial to the tech world, especially as new applications and platforms are in the initial phases. Just a few of the benefits are:
- Ease of deployment: Anybody with an internet access can get their app up and running on Heroku, which leverages AWS under the hood. This alone is incredible. No need to get and maintain a server. With GitHub integration, it is even as easy as automatically redeploying when new code is pushed to your master branch. Serverless architecture brought down a huge barrier, making it infinitely more accessible and affordable to build and deploy an application.
- Ability to scale: Serverless architecture also brings down the greatest barriers to scaling an app. If an app goes viral, there is no need to scramble and build more servers to handle the traffic. It’s just a matter of changing the service package with the provider. Better yet, this scaling can be done incrementally, which brings me to my next point…
- Efficient usage: This goes somewhat hand in hand with the ability to scale. Essentially (for all of my fellow econ nerds out there) we are talking about economies and, really, diseconomies of scale. Serverless architecture essentially removes the weight of diseconomies of scale in the highest level sense. With some packages, you sign up at a certain price and then still only pay for what you actually use. The servers aren’t just sitting idle and waiting to be used by one application, and this efficient usage allows for competitive and incremental pricing.
In the tech world (and the rest of the world, too), cost effective + easy + high quality = pretty d*** popular.
If you are looking for a more simple analogy and watch Silicon Valley, think of the infamous box:
READ — If Classic American Authors Were Software Engineers
What is AWS?
In their own words:
Amazon Web Services (AWS) is the world’s most comprehensive and broadly adopted cloud platform, offering over 175 fully featured services from data centers globally. Millions of customers — including the fastest-growing startups, largest enterprises, and leading government agencies — are using AWS to lower costs, become more agile, and innovate faster.
A cloud platform supports the serverless architecture that we discussed above, as well as an abundance of other services for more traditional infrastructures. AWS offers a wide ranging variety of cloud solutions, allowing different teams to build a highly customizable infrastructure that suits their unique needs. Two products that I have used and love from the AWS suite are ElastiCache and Elastic Beanstalk, but I think most would agree that Lambda is truly at the forefront of the AWS ecosystem. Other services include database options (ie DynamoDB, Aurora, Relational Database Service), storage options (S3), authentication and social auth (Cognito), and more.
AWS Lambda
Lambda is the bread and butter of AWS’ serverless architecture. With Lambda, server management is handled down to scaling even being automated. Lambda is unique in that it is function/event based. Your code runs as it normally would, but in addition to this, you are able to run backend functions in response to different events throughout the AWS ecosystem, such as a user uploading a photo to an AWS bucket or creating an account. Because of this, applications typically need to be built to run on AWS Lambda.
The infrastructure to support this type of complexity in production is extensive to say the least, and would have been untenable for many in the past. Lambda supports up to 1000 concurrent executions automatically, production logging using CloudWatch (an awesome feature that I highly recommend familiarizing yourself with at the start of your AWS journey), and easily integrates with other solutions in the AWS family.
Diving Deeper Into AWS
You can check out the full AWS documentation here, which is helpful when first getting familiar with these terms and this structure. It can be overwhelming at first, because of the sheer volume and interconnectedness of the system. The more you learn, the more the knowledge will click at an exponential rate.
Thanks for reading the Industry Experts publication!
Want to become a writer for the publication? It’s possible! Start by reading the guidelines. Our guidelines are simple to follow and will lead you in the right direction! As always, be sure to sign up below! Art downloads available at https://www.deviantart.com/paint-writer
