The good folks at Serverless, Inc. have released a beta version of their new full lifecycle tool, Serverless Components. I have used Serverless Framework in the past with great success, so I thought I would take a look at this new offering and try some spike solutions using it. The GitHub repository with my code can be found here.
An introduction to Serverless Components
Serverless Components were introduced in this blog entry. Serverless Components represent common cloud computing use-cases:
- hosting a static website
- providing a serverless API
- providing a real-time WebSocket-based communication channel.
Using Gatsby to generate a static website
I’ve been meaning to try out Gatsby and this Serverless Components spike solution seemed like a perfect scenario to use the two together. Gatsby has a CLI that helps scaffold out different Gatsby implementations, based on a starter template. I initially used the hello world starter template, but that was pretty underwhelming, though it did provide a good step in learning how the CLI works. I subsequently picked a more complicated starter template and quickly generated a new website.
For this spike solution, I did not go beyond generating the Gatsby website — I’ll find some time later to dig into Gatsby and hopefully write up what I find. Overall, I’m impressed with Gatsby CLI. It looks like you could build out very responsive websites quickly and hook them up to backend APIs very quickly with GraphQL. A great out-of-box experience.
Up and running with Serverless Components
Installing Serverless Components is pretty simple:
npm i -g serverless. I’ve used the Serverless Framework in the past and this is how you install that package, so I’m a bit confused how the Serverless Components is different. Perhaps Components are just how the Serverless Framework will be built in the future. Something to watch I guess.
Once you have Serverless Components installed, you can login with the serverless CLI:
serverless login. This takes you to Serverless Enterprise dashboard and attempts to take an Auth0 identity and associate it to a user in the Serverless Dashboard. I had issues here and could never seem to choose a username. I ended up punting on Serverless Enterprise set up all together. Your mileage may vary. The Serverless Components announcement blog post does mention that the integration of Serverless Components and the Serverless Framework Dashboard is something that will be forthcoming. So my experiences with the dashboard seems to be expected.
When I did finally run
serverless, I was prompted for my AWS access key ID and secret access key. I used an AWS named profile for this spike work, so I created a new administrator user in AWS IAM and generated a new access key ID and secret access key associated with that user. Never use your root user associated with your AWS account for provisioning cloud resources — always create separate IAM users for that task.
Another thing I did not have set up initially when starting this spike was a custom domain name for the deployed website. My initial attempt to upload a website failed since the domain name was not registered through Route 53, AWS’s domain name registrar. Once I had a cheap domain in hand, I was able to upload the Gatsby website, setting up the custom domain name and getting SSL configured. The following is the contents of the
serverless.yml file that I used for this spike solution:
website: component: "@serverless/website" inputs: code: src: ./public domain: www.messingwithserverless.com
It took about 45 seconds to create the website and get things configured the first time. Pushing website updates to an already configured website takes less than 15 seconds to complete. Very spunky performance. I’m super stoked about the custom domain and SSL configuration that Serverless Components wired up from information in the configuration YAML file. That’s really slick.
Overall I’m very impressed with Serverless Components, even with this beta. It looks solid in its current incarnation and really expands what the Serverless Framework can do for developers looking to build serverless applications across all the different cloud providers. Having a common and consistent CLI tool for provisioning resources and wiring things up on the backend is a boon to developer productivity.
I think it will be really interesting to see how Serverless Components competes with other Infrastructure as Code tools like Terraform and Pulumi. Those tools seem more general in scope and don’t have the focus on cloud computing use-cases like Serverless Components does. Those focusing on common cloud computing use-cases like putting up static websites or creating serverless functions behind a REST API might find Serverless Components much more approachable than something like Terraform. I’ve used Terraform in the past for some serverless work and it was kind of clunky with respects to deployment. It’s strong suit seems to be the provisioning part of the equation.
Finally, I must say I’m really intrigued by Gatsby and will definitely be checking that out more in the coming weeks and months. The Gatsby website is very snazzy and it looks like there’s a huge community forming around that offering. I could see how it could be useful for a lot of common use cases. Look for more blog entries around Gatsby in the future.