The Serverless Framework is a powerful ‘open-source’ library that allows developers to seamlessly build and integrate applications into various cloud platforms (PAAS) such as Amazon Web Services, AWS.
Following the (stable) release of Serverless in 2017, AWS have built their own tool to deploy resources into their platform; AWS SAM a.k.a. Serverless Application Model, which was initially released in 2018. It is important to note at the time of reading this, SAM may be a valuable alternative tool for to your upcoming project(s).
You may be asking yourself, why bother using Serverless or the Serverless Framework to deploy client applications the cloud?
- No self-managed Infrastructure
- reliable up-time
- infrastructure as code
- responsibility and accountability
Let’s break down each benefit a little…
No self-managed infrastructure
Firstly, using the cloud can save you provisioning and maintaining a physical server or using a shared hosting service for a slice of memory on a server.
Why not let AWS handle all of the server configuration and maintenance? At the end of the day the business and your team of developers just want to be able to run the application and we all love anything that streamlines the process.
The cloud also offers you exceptionally high SLAs (Service Level Agreements) compared to traditional server providers. Where a traditional server might be down for a period of time during maintenance or unexpected issues, AWS S3 are confident you’ll receive an uptime of 99.9% or higher each month and offers up to 100% Service Credits (refund) if it fails to match their anticipated uptime. Read more here.
Serverless cloud services like AWS S3 are also known as ‘pay for use’ services, and allow you provision the exact number of resources needed for your particular use case. Meaning you can also save a massive cost for using such pay per use serverless services over traditional server infrastructure.
Serverless enables you to build AWS CloudFormation templates to describe what resources you want to deploy into the cloud and uses the AWS CLI to deploy these resources.
With just one “Serverless Deploy” command your changes could be deployed and live within seconds and with confidence that the resources being deployed to AWS conform to the AWS CLI and templates defined by AWS CloudFormation themselves.
All of this configuration can be done as ‘infrastructure as code’ and takes some of the burden away from the ‘Ops’ in ‘DevOps’ teams.
AWS best practices recommend deploying applications using IAC to help with the Operational Excellence pillar of the ‘Well-Architected Framework’.
Responsibility and Accountability
Having the developers create the resources they need to build applications removes the additional barrier of ‘waiting for Ops’ that many modern organisations face. They’ll no longer have to wait for hardware or resources to be provisioned before being able to test or deploy features.
It also gives the developers responsibility over what they are deploying into the cloud and allows them to fully own a feature or service and I have only seen this to grow developers in the right way and create a stronger software team.
Okay, so in summary by using the Serverless Framework and AWS Cloud we’ve got zero server provisioning and maintenance, massively reduced application costs and an all-round robust way of deploying software giving developers exactly what they want; responsibility to do what they need without any barriers.
The term micro-client is becoming more and more popular as the industry pivots into microservice architectures. Rather than having one big, coupled client application why not decouple your client applications, giving you the benefits of microservices within your clients as well as your back-end services!
Sounds great, right! But how do we configure these resources, manage the routing between clients and manage create and updates to the AWS cloud…
Microclients come together nicely with using a ‘Mono-repo’ code base structure and can be nicely integrated into CI/CD pipelines using GitHub /source-control tags or labelling.
The How… 🤔
S3 buckets, CloudFront distribution
AWS S3 is a great choice and an extremely cheap solution for hosting static content websites and a popular choice for the widely used ReactJS technology developed by Facebook. You can configure these buckets with policies to secure direct access to buckets via IP-Addresses, referrer headers and more.
AWS CloudFront being a CDN service offers complete integration with S3 and can help manage the routing traffic to correct buckets and serve content to your end users. One alternative is to manage the routing externally to AWS via CloudFlare who now offer serverless workers that can be used to configure and serve objects from your S3 buckets.
As mentioned, and the purpose for this article is to show you a use case and the ability of the Serverless Framework to deploy your microclients into the AWS cloud.
Thankfully due to the open-source nature of the Serverless Framework there are two main ways we can deploy our clients into the AWS cloud:
- Write the custom CloudFormation in the serverless framework ourselves to deploy static websites and policies into AWS S3
- Or use one of many open-source and well known Serverless framework plugins to do most of the configuration for us.
In this example we will use, option 2, the serverless-finch plugin to deploy our websites into the AWS cloud.
Note: Serverless Finch Plugin automatically configures your S3 bucket for Static Web Hosting. If you’re looking into advanced use cases and bucket hosting and custom routing you will need to custom CloudFormation (option 1)
Getting Started 🚀🤓
To demonstrate the microclient deployment, first create a client directory with two microclient projects you wish to deploy.
In this example each client is simply a “create-react-app” sample application.
In each client’s package.json file we can add two simple scripts that will assist with deployment and will handle the serverless commands to deploy the website.
"predeploy": "npm run build",
"deploy": "serverless client deploy --verbose --no-confirm"
Ensure we have serverless and serverless finch installed and added to the package.json by running
npm i serverless
npm i serverless-finch
Our predeploy script runs “npm run build” and ensures that when we deploy, we have the latest build of the client application and we have the assets ready for deployment.
The deploy script runs “serverless client deploy” which tells serverless to use the serverless-finch plugin to deploy our application. BUT first we must set up a serverless configuration file, do this by adding a serverless.yml file to the microclient.
The custom resource block is where we tell serverless-finch what to deploy. In this case we call the S3 bucket after the service name itself defined on line 2. We then tell it that we want it to deploy the build folder, which “npm run build” creates for us after packaging the react application up.
Finally, ensure you have AWS credentials set up and attempt to deploy the application by running one simple script:
npm run deploy
Success, the client has been deployed to AWS S3 and default configuration, policy and CORS rules specified for us without having to worry.
Your website will now be accessible using the S3 website url:
With ease, Serverless has packaged and deployed our website for us. If we had multiple clients, we could run multiple commands through a CI/CD pipeline to seamlessly deploy them all in one process.
As you have seen the Serverless framework could be a powerful tool that allows you to deploy microclient websites to the AWS cloud. The setup is easy to do and documentation can be found on the Serverless framework website and on the plugins NPM webpage (links below).
We’ve looked at very high level some of the benefits of using Serverless against traditional or complicated clustered techniques and we can clearly see with only a few commands and little effort we have two clients up and running in minutes.
I Hope you find this blog useful and makes you consider using the Serverless framework for your next project!
Happy Coding! 🚀🤓
Reach me on LinkedIn here: https://www.linkedin.com/in/robertbulmer/