Reading AWS Serverless in Action (2)

This is the second instalment of my posts about AWS Serverless in Action; the first one is here.

We are now on chapter 2 and at last we get to do some “real work”. We get to build a working serverless application, in this case one that allows you to upload videos and have them transcoded to different formats. As a computer vision engineer that’s a facility that makes a lot of sense but I can see that many people might wonder why this particular domain – it’s a bit niche. It makes sense, I think, because it allows a very simple application to be put together from just 3 services:

• S3
• Lambda
• Media Convert

Pretty much any AWS application is going to use S3 storage at some point and Lambda is very much the core service for serverless. But just on their own it’s difficult to come up with a compelling first application. Media Convert is a very simple and self-contained service that can be spun up pretty quickly.

So that all makes sense as far as I’m concerned. For me the important part of this chapter was the focus on the frameworks that can be used to deploy serverless applications. The chapter mentions 3 (Serverless Application Model, Serverless Framework and Chalice) and settles on Serverless Framework. That’s interesting to me as I have been aware of a couple of these (SAM and Serverless Framework) but haven’t yet felt compelled to use them in my own applications yet.

Many non-Serverless AWS practitioners will be familiar with and use Infrastructure as Code tools like Terraform or AWS’s Cloud Formation. When you first get to work with AWS most people will use the console or maybe the command line to create resources but will quickly realise that more control and repeatability can be had from scripting tools. What I want to know from chapter 2 and indeed the whole book is why I should move to a serverless-oriented framework in preference for tools I already know how to use.

Whilst the example application in chapter 2 is quite lightweight, you can at least see Serverless Framework in action. What seems clear to me is that where your serverless application is going to involve a lot of small functions (and that’s kind of the point of serverless) then you need good support for writing and deploying the source code for each Lambda function. When using CloudFormation I’ve tended to have my own little function packaging scripts that include and zip package dependencies and push to S3. The zip is then referenced in the Cloud Formation. Severless Framework automates a lot of this for you. Sounds good.

One last thought. The focus of the chapter so far as programming languages is concerned is Javascript and node.js/npm. At least where AWS Lambda is concerned Node.js and Python are the 2 primary frameworks. I’m pretty comfortable with both these languages but if pushed I probably plump for python. Will the book be just focussed on Node or will we see some Python as well. Time will tell…

Reading AWS Serverless in Action (1)

It’s been quite a while since I last posted. In fact the last time was May 2017! So maybe it’s time to get back into the swing with some thoughts on AWS.

I’ve worked with AWS for more years than I can remember. In the early years that was mostly EC2 and S3 but in the last year I’ve been using a much wider range of Amazon’s vast offering. In particular I’ve been setting up and running systems using “Serverless” architectures. I thought it would be interesting to see what I might have learnt earlier if I’d had a good book. As a Manning author I naturally thought that Serverless Architecture on AWS (2nd edition) was a good place to start.

The book itself isn’t due to be published until 2021 but is being released in parts through Manning’s early access program (MEAP). So here’s the plan: I’ll set aside some time to go through a chapter or two each day and post my thoughts and reflections. I’m writing this just as we are about to go into another lockdown in England and so I should have some spare time on my hands! I’ll commit to doing this throughout November. If you have any feedback, questions or thoughts drop me a line in the comments.

So chapter 1: As usual for books of this type this is really a scene-setter chapter getting readers up to the same page and discussing some of the jargon that many will already know. In particular what is serverless? The authors give a definition that requires 2 things to be present 1) served as a utility 2) only incur cost for usage. The key here is offerings like Salesforce meet the first but not the second.

Related to this is the discussions of Functions-as-a-service (FAAS) for which AWS offers Lambda functions. Sometimes FAAS/Lambda gets conflated with serverless. Serverless is a superset of these technologies, one obvious example being AWS’s FARGATE which is a serverless container (as in Docker) environment.

Possibly the most useful section of the chapter is section 3 which looks at how and when to go serverless. In particular the authors recommend avoiding a ‘lift-and-shift’ approach, something I would heartily agree with. If you are looking to make this call and want to understand the options and pros and cons, checkout this section.

Finally I checked out the 2 appendices. Appendix A listed out some of the technologies that might be used in a serverless approach and presumably they will be talking about them later in the book. It was encouraging to see both AWS’s hosted API offerings, API Gateway (REST) and AppSync (GraphQL), discussed. I’ve enjoyed using AppSync/GraphQL over the last couple of months so hopefully there will be something on that.

Appendix B covers some of the nuts and bolts of AWS that you really have to have nailed down before jumping in feet first. I’m talking about 1) security 2) costs. As I found when encountering any new cloud service it doesn’t take long before you have to understand the security model to make best use of cloud. AWS has a reasonably straight-forward model but it does have a few oddities.

It also won’t take long before you find costs biting. It’s good to get a hang of how the various costing models work in particular what free-tiers are available: it’s not uncommon to happily be working with a technology that seems very cheap until you tip over the free-tier level!

I’ll post my thoughts on chapter 2 in the next posts.