With a couple projects under my belt, I’ve come to discover the magic (and sometimes, pain) of building a web app for a client in and out of the cloud.
The Non-Cloud Way
This is how I started out when I graduated from bootcamp
- Rapid prototype the features
- Figure out architecture
- Code the API routes
- Build a test page
- Hit the server
- Work on business logic
* granted this way does not take into consideration the methodologies involved (agile, kanban, waterfall)
I worked on a project where this made sense because we were working on a single feature within a larger web app. Deploying this web app to the cloud would not have worked out because they needed to own the servers and thus, the maintenance as well.
Because we needed to integrate the application into the client’s larger project, I was responsible for deployment. This was another headache (I mean, there’s a whole ‘nother side of engineering dedicated to this; its called DevOps!). The time spent deploying, rolling back changes, and maintaining servers took away time from improving business logic, which is the carne of the application itself
Enter the Serverless Way
I spoke about the magic that is Serverless recently for the Tech Tinx DTLA Show & Tell. You can check out my talk here.
I’m sure most of you are quite familiar with deploying to AWS, Azure, Google Cloud, or IBM. Its easy, super user-friendly, and comes with a wide-variety of resources any dev could use to deploy an application in minutes (simple-storage solutions that don’t require a JOIN, anyone?) But the joy of Serverless came to me on a project that had a very short turnaround.
Seeing that we need an entire backend for a front end that was functional, going with AWS made sense. But the user-friendly features of AWS made code control and deployment control nearly impossible.
All Hail the YAML File
The feature I like best about Serverless is that my AWS deployment is located in one friggin’ place.
Need to create an S3 bucket? Done. Need to define policies for your lambda to put stuff in the bucket? Done.
If you work in microservices like me, each microservice can have its own yaml file that can be deployed to AWS on its own!
Resolving Lambda and API Gateway Difficulties
Leslie Passante sums it best:
Your Lambda function is probably going to want to know the request path and method, the URL parameters, query parameters, and perhaps a custom header or a POST request body. None of that is available without a request template. Similarly, API Gateway doesn’t interpret a response from a Lambda function by default, so if your function returns an error, there is no automatic mapping to HTTP error response codes.
Serverless solves this by giving you the option to create a request and response template for your API.
The ability to define and use variables in deployment made me even more of a Serverless fan.
In my configuration file, I have defined variables that will be utilized in my microservice yaml file.
And here is my users microservice yml file that I will deploy to AWS. As you can see, the region and the resource names are populated from the config file.
This feature makes deploying to a dev, test, and prod environment that much easier.
Before jumping into Serverless, its important that you have a good understanding of the cloud service you are using, whether that be AWS, Google Cloud, or Azure. I know for myself, AWS IAM Policies in Serverless is one area I am trying to improve on. But once one gets the gist of the cloud service, go buck-wild with it!
- Great post that does a deep dive into AWS and Serverless by Leslie Passante
- Serverless framework
- Amazon Web Services
- For those looking for Google Cloud documentation on Serverless, there’s an open pull request to add them back in.