One of the best benefits of cloud computing is that it enables companies and individuals to focus on differentiating factors. You don’t have to spend as much time solving common problems like logging, authentication, scaling, and the like. Instead you can actually spend your time and resources solving a problem in your unique way.
One of the trends in this space is moving toward serverless computing. Being serverless doesn’t mean that your code doesn’t run on servers but rather that you don’t have to care about them. You just hand your code and a little configuration to the cloud and it just runs. It spins up and tears down running instances of your code as needed. As I heard in a talk by a Netflix engineer, we need to start treating our servers like cattle instead of like pets. If you are naming your server, it is a pet.
Each cloud has their own flavor of serverless for mobile and web applications that offer authentication, storage, hosting, functions, and databases. Each come with their own management console, client side libraries, and CLI. For Google Cloud (GCP) their solution is called Firebase. For Amazon Web Services (AWS) their solution is a combination of Amplify and AppSync. For the most part these frameworks present a combined interface that utilize the raw services offered in each cloud.
Over the last few months I’ve had the opportunity to work with both GCP’s and AWS’s implementations of serverless. Let me just start by saying that I love using both but each has its own pros and cons. What I am going to share is a brief overview of each and how they worked out for an example application.
For the sake of comparison, let me describe the basic application requirements from a development perspective:
- Isolated environments (dev, test, prod).
- Infrastructure as Code (IaC) for consistent, versioned environments and ease of creating new ones.
- Serverless authentication, hosting, and database.
- Multi-tenant, multi-role authorization.
- Automated deployments (CI/CD).
- User management console (so we can deffer building one).
In the next two posts I’ll describe the offerings of each cloud and in the final one I’ll provide a comparison. Click below to read on:
Erik is an agile software developer in Charlotte, NC. He enjoys working full-stack (CSS, JS, C#, SQL) as each layer presents new challenges. His experience involves a variety of applications ranging from developing brochure sites to high-performance streaming applications. He has worked in many domains including military, healthcare, finance, and energy.