In physics, a quantum (plural: quanta) is the minimum amount of any physical entity (physical property) involved in an interaction. In kind, a quantum site attempts to be the minimum amount of physical resources required for a functional presence on the web. A quantum site is achieved focusing on using on-demand infrastructure: serverless.
It works much like any other website. A user navigates to a URL, the URL resolves via DNS, the request is sent to the resolved host, processed, and the response returned to the originator.
For a typical website, a web server (or farm) would be up and running, ready to serve requests at all times. For a quantum site, thanks to serverless, there is no web server (nor farm) running all the time. This example uses several Amazon Web Services (AWS) to make this happen. Before deploying this solution, verify the deployment account has each listed service activated:
- API Gateway
- API Gateway exposes
dev
andprod
stages of Lambda functions using Custom Domain Names, SSL, and Edge Optimizations.
- API Gateway exposes
- Certificate Manager
- Issues and manages certificates which secure the public domains.
- CloudFormation
- Deploys most of the required components of the quantum site, and to update it with code and asset changes.
- CloudFront
- Serves images and style sheet assets
- IAM
- IAM manages deployment rights and execution rights, used primarily by CloudFormation.
- Lambda
- Used to serve the quantum site, process form POSTs, and generally be the website.
- Route 53
- Used to resolve the public domain names to internal domain names and services like API Gateway and CloudFront. Specifically, the
A record
aliasing feature offered by AWS.
- Used to resolve the public domain names to internal domain names and services like API Gateway and CloudFront. Specifically, the
- S3
- Used to store the static assets for the CDN.
There are also a few serverless components, and plug-ins at play here:
- serverless-offline
- Used for running serverless locally to develop and test.
- serverless-plugin-bind-deployment-id
- Used for sequencing deployment components after the API Gateway deployment step because it uses a time-stamped identifier.
- serverless-s3-sync
- Used for synchronizing the local build/assets folder with the CDN S3 Bucket, per stage.
There are a couple of manual steps involved, things that can't yet be automated because they require verification steps:
- Domain registration (if one isn't already registered)
- Registration requires purchasing
- Hosted zone configuration in Route 53
- Requires domain ownership verification if the domain wasn't purchased via AWS and already configured in Route 53
- Public domain certificates
- Requires domain ownership verification
These steps are covered below in limited detail, as seemed appropriate for the scope of this example.
The contact
handler in this example also uses AWS Simple Email Services (SES) which requires additional setup and is entirely optional. It could be re-written to use SMTP, SendGrid, or other suitable email delivery solution.
- Have, or register, a domain name
- Have, or create, an AWS account
- Configure
~/.aws/credentials
for theaws-cli
- Detailed instructions on setting up the
aws-cli
are available in the AWS CLI Documentation. - Ensure these credentials are in a group with the following policies.
- AWSLambdaFullAccess
- AmazonS3FullAccess
- CloudFrontFullAccess
- AmazonAPIGatewayAdministrator
- AmazonRoute53FullAccess
- AWSCloudFormationDeploy
- This policy has the following actions allowed on all resources
cloudformation:CreateChangeSet
cloudformation:CreateStack
cloudformation:CreateStack
cloudformation:DescribeChangeSet
cloudformation:DescribeStackEvents
cloudformation:DescribeStackResource
cloudformation:DescribeStacks
cloudformation:DescribeStacks
cloudformation:ExecuteChangeSet
cloudformation:ListStacks
cloudformation:UpdateStack
cloudformation:UpdateStack
cloudformation:ValidateTemplate
iam:CreateRole
iam:DeleteRole
iam:DeleteRolePolicy
iam:PutRolePolicy
iam:UpdateRole
- This policy has the following actions allowed on all resources
- Detailed instructions on setting up the
- Login to AWS Console
- Enable Route 53 DNS. There may be manual domain ownership verification steps involved in this process, via email or DNS record creation. Be sure to read the steps along the way and ensure you can satisfy the verification requirements.
3. Setup a Hosted Zone for the domain name
4. To support the certificate request, create the root record in the zone:
.
- AnA record
pointed to an IP address- Provide this name in the
serverless.yml
file as the value of thebaseName
variable.baseDNSName: 'mydomain.com'
- Access Certificate Manager. There are verification steps required during this step. If you hosted zone in Route 53 is already verified you may be able to use automated verification integration provided in the UI processes on the AWS console. Look for buttons that say "Use Route 53" and be aware that you might have to expand collapsed UI elements to find these buttons.
6. Request a public certificate for:
- The root domain (mydomain.com)
- A SAN (Subject Alternate Name) wildcard domain (*.mydomain.com)
- Provide the ARN of the issued certificate in the
serverless.yml
file as the value of thewildcardCertArn
variable.wildcardCertArn: 'arn:aws:acm:us-east-1:000000000000:certificate/00000000-0000-0000-0000-000000000000'
- Deploy the solution to the development stage using
yarn deploy
and then view the deployment by opening a browser and navigating to https://dev.mydomain.com
Why does this even exist?
To demonstrate the ability to create a site which essentially doesn't exist until it's requested.
Why use lambdas for serving content?
To create a simple server rendered website.
Can this be done with an SPA/PWA?
Yes, the whole site could be served from the CDN and include scripts that call lambdas.
Is this simpler done with SPA/PWA
Subjective; SPA/PWA frameworks like Vue and React can be more complicated to setup, and bulkier for simple sites.
How much does it cost to do this?
One of my deployments of this solution is currently costing me $0.56 USD per month. Most of the services used here have AWS Free Tier offerings. The domain name cost varies and can be as low as $12 annually. The cost will be largely based on how much the site is used.
Where can I see a deployment of this solution?
You can see one of my original deployments of this at Carte Blanche Circus (https://carteblanchecircus.com)