Intro 💡

It has been impossible to avoid all the chaos surrounding Twitter over the last year. From the acquisition of the company by an eccentric billionaire, to mass layoffs, to re-branding the entire company to the letter “𝕏”… it has been a wild ride for the social media giant that once was a little blue bird.

When I first heard that Elon Musk had decided to re-brand Twitter to “𝕏”, I thought it was purely a joke but a notification from the New York Times on my phone proved otherwise.

The very first thought that came to my mind was “How on Earth are they ever going to acquire the x.com domain?”. Surely this single letter domain is either already owned by another tech giant or restricted by the Internet Corporation for Assigned Names and Numbers, right? Well, navigating to x.com will show you that it is currently redirecting to Twitter (as of August 13th, 2023). This is where my adventure down the x.com rabbit hole began. 🐰

The majority of screenshots and source information in the rest of this article comes from the Internet Archive's WayBack Machine. The Internet Archive is a non-profit organization that has been archiving the internet since 1996. It is a great resource for looking at the history of websites and how they have changed over time.

The Internet Archive is an American digital library founded on May 10, 1996, and chaired by free information advocate Brewster Kahle. It provides free access to collections of digitized materials like websites, software applications, music, audiovisual and print materials. — source

The History of x.com 📜

Jumping right into the history of x.com, we can see that it was first archived in 1996. Let’s walk through the wild history of this domain to see all the different sites that have occupied its space.

1996

⭐ x.com is a personal site

The very first archived version of x.com shows that it was possibly owned by someone named “Dave” and that it was under construction.

1997

In 1997, it looks like x.com was still under the ownership of “Dave” but this year he added a third color to the site… green! It also features a red sphere featuring the x.com domain. “Dave” was probably quite aware at the time just how unique the domain name was to own and likely had no idea that his page would be archived for the next 27 years and one day be the home of Twitter.

1998

At this point, a new owner is using x.com as their personal site. Perhaps “Dave” and “Rob” were friends since “Dave” was mentioned in the previous version of the site. Either way, “Rob” is now the owner of x.com and quite possibly got a nice payout for being able to sell the valuable domain name in the following year.

1999

⭐ x.com is an online banking service

In 1999, an online bank by the name of x.com was founded by Elon Musk, Harris Fricker, Christopher Payne, and Ed Ho in Palo Alto, California (source). The bank needed a domain name so Elon Musk allegedly paid $1 million to purchase the domain name (presumably from “Rob”) (source).

During 1999, the site displays an “Under Construction” message without any details.

Early 2000

x.com was up and running in the beginning half of 2000. Navigating to x.com, users would be presented with a login/sign-up screen that sharply aligns with the design trends of the dotcom bubble era. Looking over on the right side of the page, you can see a bit of foreshadowing for the future of x.com… PayPal.

Late 2000

⭐ x.com is PayPal

In the latter half of 2000, x.com and Confinity merged together to form PayPal and so x.com became PayPal (source).

2012

⭐ x.com is landing page for eBay and PayPal products

PayPal is acquired by eBay in 2002

Flash forward to the year 2012 and x.com is now a landing page for eBay and PayPal products. eBay acquired PayPal in 2002 and between 2002 and 2012, x.com was mainly used as a fancy link to promote various services.

2017

⭐ x.com is a blank site with the letter “x”

Between 2012 and 2017, x.com just redirects to ebayinc.com. This all ended when Elon Musk decided to purchase the domain name back from PayPal/eBay because “it has great sentimental value” (source).

x.com stays in this state for nearly all of its time until 2023, with just a short break in 2018.

2018

⭐ x.com is used to promote hat sales

For a brief period of time in 2018, x.com was used to promote hat sales for The Boring Company by redirecting to the boringcompany.com/hat page (done by Elon Musk, the owner of the domain).

2023

⭐ 𝕏.com is Twitter (well, almost)

As of August 1st, 2023, x.com is now redirecting to Twitter as part of their re-branding effort to the letter “𝕏” (source).

In the near future, this will likely “flip around” and x.com will be the main domain for Twitter while twitter.com will redirect to x.com.

IRL Example 🏭

When thinking about how a “domain” can be the home to many different sites, projects, and companies, I keep thinking about how this is similar to the way humans occupy buildings in different ways over time. Only about a mile walk from me (writing this in London) is the Battersea Power Station. This is a perfect IRL (real-life) example of how a place can serve so many different purposes over the years.

Battersea Power Station was built in the 1930s and at its peak, it was producing a fifth of London’s power (source). It was decommissioned in 1983 and has since been used as a filming location for many movies and TV shows. It has now been completely redeveloped to be a mixed-use development containing apartments, cafes, restaurants, tons of shops, and even a hotel.

Conclusion 🏁

The history of x.com is a wild one. From a personal site, to an online bank, to PayPal, to eBay services, to a hat sale, and finally to Twitter… x.com has been a home for many different sites over the years.

If you found this article interesting, please consider giving me a follow, thanks!

This article was originally written and published by Grant Birkinbine (me!) at the following URL: https://blog.birki.io/posts/x-dot-com/

Intro

The most common way developers deploy their changes to production is the merge → deploy model. However, there is a significantly better way to ship our code to production. Rather than smash the merge button, cross our fingers, and hold onto our butts... we can hit merge with confidence that our change works exactly as we expect it to!

Introducing… the branch deploy model!

If you have already heard of the branch deploy model and are familiar with it, you can skip ahead to get to the part where we implement it with GitHub Actions

To really understand the branch deploy model, lets first take a look at a traditional deploy → merge model. It goes like this:

1. Create a branch
2. Add commits to your branch
3. Open a pull request
4. Gather feedback + peer reviews
5. Merge your branch
6. A deployment starts from the main / master branch

Now lets take a look at the branch deploy model:

1. Create a branch
2. Add commits to your branch
3. Open a pull request
4. Gather feedback + peer reviews
5. Deploy your change
6. Validate
7. Merge your branch

As you can see, the merge deploy model is inherently riskier because the main branch is never truly a stable branch. If a deployment fails, or we need to roll back, we follow the entire process again to roll back our changes. However, in the branch deploy model, the main branch is always in a “good” state and we can deploy it at any time to revert the deployment from a branch deploy. In the branch deploy model, we only merge our changes into main the branch once it has been successfully deployed and validated.

Note: This is sometimes referred to as the GitHub Flow

Key Concepts

Key Concepts of the branch deploy model:

• The main branch is always considered to be a stable and deployable branch
• All changes are deployed to production before they are merged to the main branch
• To roll back a branch deployment, you deploy the main branch

Okay, so by now you are hopefully sold on the branch deploy methodology. But how do we implement it? Introducing… IssueOps!

IssueOps

The best way to define IssueOps is to compare it to something similar, ChatOps. You may be familiar with the concept ChatOps already but in case you aren’t here is a quick definition below:

ChatOps is the process of interacting with a chat bot to execute commands directly in a chat platform. For example, with ChatOps you might do something like .ping example.org to check the status of a website

IssueOps adopts the same mindset but through a different medium. Rather than using a chat service (Discord, Slack, etc.) to invoke the commands we use comments on a GitHub Issue or Pull Request. GitHub Actions is the runtime that executes our desired logic when an IssueOps command is invoked.

GitHub Actions!

How does it work?

This section will go into detail about how this Action works and hopefully inspire you on ways you can leverage it in your own projects.

The full source code and further documentation can be found on GitHub

Create this file under .github/workflows/branch-deploy.yml in your GitHub repository

Let’s walk through a GitHub Action workflow using this Action line by line:

It is important to note that the workflow we want to run IssueOps on is issue_comment and created.

This means we will not run under any other contexts for this workflow. You can edit this as you wish but it does change how this model ultimately works.

For example, issue_comment workflows only use files found on main to run. If you do something like on: pull_request you could open yourself up to issues as a user could alter a file in a PR and exfil your secrets for example.

Only using issue_comment is the suggested workflow type

These are the minimum permissions you need to run this Action

Sets up your demo job, uses an ubuntu runner, and checks out your repo - Just some standard setup for a general Action

Note: It is important to set an id: for this job so we can reference its outputs in subsequent steps — You can see a full list of inputs and outputs the Action takes here

The core of this Action takes place here. This block of code will trigger the branch deploy action to run. It will do the following:

1. Check the comment which invoked the workflow for the trigger: phrase (.deploy) defined here
2. If the trigger phrase is found, it will proceed with a deployment
3. It will start by reacting to your message to let you know it is running
4. The Action will post a comment with a link to the running Actions workflow for you to follow its progress
5. Deployment will be started and attached to your pull request — You’ll get a nice little yellow rocket that tells you deployment is in progress
6. Outputs will be exported by this job for later reference in other jobs as well

As seen above, we have two steps. One for a noop deploy, and one for a regular deploy. For example, the noop deploy could trigger a terraform plan and the regular deploy could be a terraform apply. These steps are conditionally gated by two variables:

• steps.branch-deploy.outputs.continue == 'true' - The continue variable is only set to true when deployment should continue
• steps.branch-deploy.outputs.noop == 'true' - The noop variable is only set to true when a noop deployment should be run

Example: You comment .deploy noop on a pull request. A noop deployment is detected so this action outputs the noop variable to true. You also have the correct permissions to execute the IssueOps command so the action also outputs the continue variable to true. This will allow the "fake noop deploy" step seen above to run and the "fake regular deploy" step will be skipped

That’s it!

If you wish to learn more about setting up this Action and all the configuration options available, you can view the Action on the GitHub Marketplace: link

Note: You can also find all code and a full workflow example with the link referenced above

Example 🎥

The example below demonstrates using the branch-deploy Action on a pull request

Conclusion

If you are looking to enhance your DevOps experience, have better reliability in your deployments, or ship changes faster, then branch-deployments are for you!

Hopefully you now have a better understanding of why the branch-deploy model is a great option for shipping your code to production.

By using GitHub + Actions + IssueOps you can leverage the branch deploy model in any repo!

Source code: GitHub

Further reading:

• https://blog.birki.io/posts/branch-deploy/
• https://github.blog/2023-02-02-enabling-branch-deployments-through-issueops-with-github-actions/

Branch Deployments With IssueOps and GitHub Actions was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before we begin

Full Disclosure: This article is not sponsored (or promoted) by Kubernetes, Kong, Terraform, GitHub or any other organization. The sole purpose of this article is support the opensource community. 🖥️

Intro 💡

Have you ever had a great idea for a web app that got you so excited you just immediately started hacking away on it? And then after a few hours, days, or months realize that the single VM instance it is running on doesn’t scale (at all). Additionally, you have no CI/CD pipeline, nothing is containerized, you have no load balancer, all your secrets are saved to disk, the VM config is all tweaked by hand, and backups are non-existent?

Sounds all too familiar.. Its probably a kick-ass project but the infrastructure isn’t fun to work with and really hinders your development. That is the core reason I started the journey into k8s and why I have written this article.

The purpose of this guide is for you to create your own Kubernetes cluster using Kong as an API ingress. This will be done with minimal setup and by running a single command to provision your infrastructure. After running through the deployment you will have a working base project that you can customize and configure exactly the way you need it.

Key Concepts

There are a few key concepts which should be understood before we begin. Below I will touch on a few points briefly about why I am using certain technologies for this project/guide:

Kubernetes:

• What is Kubernetes? You should check out this guide here to learn about Kubernetes if you are unfamiliar
• We want to use Kubernetes to allow rolling updates, zero downtime deployments, a containerized application, and many more k8s features

Kong:

• What is Kong? Kong is an API gateway which can be used as an ingress controller with Kubernetes. To read more about Kong check out this link here
• We want to use Kong as our ingress controller because it is incredibly performant, scales flawlessly, and has a wide array of quality plugins. In this guide we will use the Request Control and Let’s Encrypt plugins.
• Kong makes it easy to add new routes, enable caching, and loadbalance your applications

Terraform

• What is Terraform? Terraform is an IaC (Infrastructure as Code) tool for deploying resources. You can read more about it here
• We want to use Terraform to declaratively define all the resources we will be deploying for your Kubernetes cluster.
• It is very important that we use a tool like Terraform so you may automate the entire deployment process into a CI/CD pipeline

What you will create ⭐

• A Kubernetes Cluster running on Azure Kubernetes Service (AKS)
• A k8s ingress controller using Kong
• Grafana/Prometheus dashboards for viewing network metrics from Kong (ready to use out of the box)
• A sample NGINX application which serves HTTP requests (loadbalanced by Kong)
• A simple Flask backend that receives requests from NGINX and acts as a REST API
• (optionally) Enable TLS encryption on your external facing Kong ingress for security (using cert-manager!)

10,000 Foot Overview

Let’s look at a 10,000 foot overview of the infrastructure we are about to provision:

Breakdown of components seen above:

• External Load Balancer — The “entry point” which Kong creates and binds with to allow public traffic into your k8s cluster. This is essentially just a Azure LB tweaked to work with Kong
• Kong Namespace — This namespace contains all the components of Kong. Plugins, routes, and deployments are all contained in here. Kong acts as the proxy into the rest of our infrastructure for public connections
• Let’s Encrypt Namespace — This is an optional namespace that is used for enabling the ACME Kong plugin. By using this plugin you will automatically provision TLS for your external ingress with Kong.
• Monitoring Namespace — The monitoring namespace contains all the components for Grafana and Prometheus. This can either be accessibly publicly (using IP restriction) or via port forwarding tunnels with kubectl. Both options are scripted for ease of use in this project. The end result of this namespace is a fancy Kong dashboard to view inbound connections for your k8s cluster
• Frontend Namespace — This is where the sample NGINX application lives. A Kong route is established for everything (/) to be routed to the NGINX web server.
• Backend Namespace — This is where the backend Flask REST API lives. There is no route configured to this application from Kong. All requests made to the API go through the NGINX server. This is done through k8s services

Prerequisites 🚩

You will need a few things to use this project:

1. Fork or clone the k8s-kong-terraform project!
2. An Azure account (this project uses AKS)
3. tfenv (for managing Terraform versions)
4. kubectl (for applying K8s manifests)
5. Azure CLI
6. A Terraform Cloud account to store your TF state remotely
   See the terraform-cloud docs for more info (required if you are using Terraform Cloud)
7. An Azure Service Principal for deploying your Terraform changes — Create a Service Principal
8. Your Azure Service Principal will need owner permissions to your Azure Subscription. This is due to K8s needing to bind your ACR registry to your K8s cluster with pull permissions - Assign Roles to a Service Principal
9. You will need to skim through the following files in the k8s-kong-terraform repo (that you cloned or forked) and edit the lines with (CHANGE ME) comments:

• terraform\k8s-cluster\versions.tf
• terraform\k8s-cluster\variables.tf
• terraform\k8s\k8s-cluster.tf
• Example: Updating values with your own unique K8s cluster name and pointing to your own Terraform cloud workspaces

Let’s begin!

Building the Cluster 🔨

Let’s try and build a K8s cluster with a single command!

This can take a few minutes to run.. stand by, cross your fingers, and hope the magic happens. If you experience any issues feel free to open an issue

$ make build

🔨 Let's build a K8s cluster!
✅ tfenv is installed
✅ Azure CLI is installed
✅ kubectl is installed
✅ terraform/k8s-cluster/terraform.auto.tfvars.json exists
✅ terraform/k8s-cluster/terraform.auto.tfvars.json ...
✅ terraform/k8s/terraform.auto.tfvars.json exists
✅ terraform/k8s/terraform.auto.tfvars.json contains ...
🚀 Deploying 'terraform/k8s-cluster'...
⛵ Configuring kubectl environment
🔨 Time to build K8s resources and apply their manifests...
✅ All manifests applied successfully
🦍 Kong LoadBalancer IP: 123.123.123.123
📊 Run 'script/grafana' to connect to the Kong metrics dashboard
✨ Done! ✨

Great! You should now have a fully running k8s cluster ready to use. Let’s test it out.

Either grab the IP above from Kong Loabalancer IP: <IP_here> or grab it from the Services and Ingresses section in your Azure account (under your AKS cluster). Throw that IP into your web browser and you should be presented with a screen something like this:

Clicking the Query Flask Backend button will generate an API call to the Backend Service which will return some information for you about the container and the environment’s context.

Success! We have our cluster up and running, Kong works, our frontend service receives requests, and our backend service can respond to API calls. Now that it is all up and working let’s walk through the make build command a bit because it just did a lot

The make build command explained

Here is a quick summary in order of operations of what the make build command just did

Note: The best way to understand what this command just did is to look at the source code (as always) If you don’t want to do that there is a summary just below.

make build summary:

1. Starts the script/build bash script
2. Checks to make sure all necessary dependencies are installed (az cli, tfenv, etc)
3. Checks to ensure the proper terraform.auto.tfvars.json files have been created and do not contain the example credentials
4. Enters the terraform/k8s-cluster directory to init and apply all the Terraform resources for the base k8s-cluster infrastructure. (Think the core cluster, ACR registry, etc)
5. Configures your local kubectl environment to use the new cluster we just created. Necessarily values are grabbed from the Terraform state of the k8s-cluster that was just created for authentication and stored in ~/.kube/config as usual.
6. Invokes the script/build-and-push-azure script to build the frontend and backend images and push them to the ACR registry created in step 4.
7. Enters the terraform/k8s directory to init and apply all the Terraform resources for the services and workloads which will be running on our k8s cluster (think the frontend and backend services).
8. Completes the script and displays a status message with the Kong LoadBalancer IP and some ✨

Grafana / Prometheus Dashboards 📊

If you want to view some request data about how much ingress traffic Kong is receiving for your shiny new web application all you need to do is run a single command:

script/grafana

This will create a port forward tunnel with kubectl (which is encrypted) directly to your k8s cluster. The script/grafana command will give you a link to click and your credentials for accessing grafana

Once you log in, you may have click around a bit to find your pre-made Kong dashboard. Example:

Note: port forwarding should not be used in production systems to access Grafana

This concludes the basic setup of the cluster! We can extend our stack further by using TLS or GitHub actions as a CI/CD pipeline for deployments. Those topics are more experiential and I have not polished them as much but they included below for your use.

Enabling TLS 🔒

This is a bonus / experimental section. It “works on my machine ™” but it will take a smidge of manual setup, knowledge of letsencrypt, DNS, etc.

What you need first (pre-reqs):

• A domain name (www.example.com)
• A way to configure DNS records for your domain (route53, AzureDNS, etc)
• A working DNS cluster that has been built with make build (above) - Copy down your Kong Proxy IP

Steps

These are a mix of steps and an outline of the make enable-tls helper script

1. Execute the following command: make enable-tls
   This will invoke a bash script which will swap around some files, prompt you for some input, and inject said input into K8s manifests via sed. It is recommended to say yes (y) to everything and enter the information requested (make sure to read all the prompts!)
2. When prompted, create DNS records that point to your K8s cluster. You will need an A record that points to your Kong LoadBalancer ingress and a CNAME that maps to the A record at a minimum (more details presented from the script)
3. When prompted, edit each listed K8s manifest file to your liking. This part requires you to have a bit of K8s knowledge (not much though) in what you need to use and where. Each manifest file is commented to help you along!
4. The end of the script will run a full deployment of the cluster
5. It will take a few minutes for everything to settle and for your TLS certificates to be provisioned. Happy encryption!

I will not begin to explain how this all works under the hood. It took me a bit of time to grasp. The ultra short version is as follows:

A Kong Plugin for lets-encrypt is enabled and automatically requests and renews certificates for the domains you provided. It does this via a HTTP challenge with your Kong public load balancer and the DNS records which you pointed to your Kong ingress IP.

If you are inclined to learn more, here are some good resources:

• Kubernetes cert-manager podcast
• Official cert-manager documentation

GitHub Action for CI/CD 🚀

This is another bonus / experimental section

Once your stack is fully up and running, you can use GitHub Actions to deploy changes to your cluster. I have documented the repository secrets which you need to add in order to get in the project repo here (along with the rest of the docs). You can then use the .github/workflows/deployment.yml file in the repo to run your CI/CD pipeline.

There are some other workflows baked in as well for your use like tfsec, misspell, and first-interaction.

Conclusion 🏁

This write-up is essentially a brain dump of my learnings with building a Kubernetes stack from the ground up. I wanted to use pure Terraform to manage the state of the project, have TLS for the public ingress, and a simple application that will be easy to switch out and build upon for the backend. I certainly learned a lot along the way and hope if you are reading this you did too (even better if you now have your own k8s cluster to deploy applications upon)!

GitHub Repository: k8s-kong-terraform

Contributing 👩‍💻

All are welcome to contribute to this project! If you have a suggestion feel free to fork and open a pull request :)

k8s-discord 🟣

I have another sister project called k8s-discord which takes a similar approach and deploys a Kubernetes cluster for building Discord slash command applications. It is not as polished as this project but if that interests you feel free to check it out as well.

Thanks for reading!

Monitor, Alert, and Display all your Fastly metrics in Real-Time!

Full Disclosure: This article is not sponsored (or promoted) by Fastly, New Relic, or any other organization. The sole purpose of this article is support the opensource community.

About 💡

Fastly-Tempo is an opensource project that allows you to stream real-time aggregated metrics from Fastly into New Relic and other monitoring services.

This is based off the New Relic blessed way to get your Fastly metrics into New Relic Insights, packaged as a Docker container image for ease of use!

This project is opensource and hosted on GitHub.

Getting Started 💻

Getting started and using the Fastly-to-Insights project is incredibly easy! In fact, it can be used by running a single command.

Before you get started, make sure that you have a Fastly API Key and a New Relic Insert Key.

Then run the command below:

docker run \
  -e ACCOUNT_ID='yourNewRelicAccountId' \
  -e FASTLY_KEY='yourFastlyKey' \
  -e INSERT_KEY='yourNewRelicInsertKey' \
  -e SERVICES='ServiceId1 ServiceId2 ...' \
  grantbirki/fastly-tempo:latest

Grab the image from DockerHub 🐳

Boom! You should now have metrics from all your specified Fastly services streaming in real-time into New Relic.

The next step is to create some dashboards to visualize this data.

Dashboard Creation 🗺️

To start visualizing your data, you will need to create a dashboard.

I have created a pre-made template which can be imported through a simply copy & paste in the New Relic UI. For more instructions on importing a dashboard through JSON, see New Relic’s documentation.

Tip: Make sure to “find and replace” “accountId”: 1234567 in the JSON template to your own New Relic accountId. Also ensure to set your dashboard permissions appropriately.

Steps:

1. Save the JSON dashboard template available here
2. “Find and Replace” “accountId”: 1234567 with your own New Relic accountId
3. Import the dashboard to your account through the New Relic UI — docs

Congrats! You should now have some pretty slick dashboards to visualize your Fastly metrics in real-time.

Dashboard Examples:

Exported Values 🧮

There are over 100 values are are exported from the Fastly-to-Insights project for your to create dashboards on, visualize and set alerts for. Here is the complete list of usable values:

service
num_requests
num_tls
num_http2
num_logs
num_pci
num_video
ipv6
pipe
uncacheable
shield
shield_resp_header_bytes
shield_resp_body_bytes
otfp
otfp_shield_time
otfp_deliver_time
otfp_manifests
otfp_shield_resp_header_bytes
otfp_shield_resp_body_bytes
otfp_resp_header_bytes
otfp_resp_body_bytes
bandwidth
resp_header_bytes
header_size
resp_body_bytes
body_size
req_body_bytes
req_header_bytes
bereq_header_bytes
bereq_body_bytes
billed_header_bytes
billed_body_bytes
status_2xx
status_3xx
status_4xx
status_5xx
status_200
status_204
status_301
status_304
status_400
status_401
status_403
status_404
status_500
status_501
status_502
status_503
status_504
status_505
status_1xx
waf_logged
waf_blocked
waf_passed
attack_req_body_bytes
attack_req_header_bytes
attack_logged_req_body_bytes
attack_logged_req_header_bytes
attack_blocked_req_body_bytes
attack_blocked_req_header_bytes
attack_passed_req_body_bytes
attack_passed_req_header_bytes
attack_resp_synth_bytes
hits
hit_ratio
miss
pass
pass_time
synth
errors
restarts
hits_time
miss_time
tls
tls_v10
tls_v11
tls_v12
tls_v13
imgopto
imgopto_resp_body_bytes
imgopto_resp_header_bytes
imgopto_shield_resp_body_bytes
imgopto_shield_resp_header_bytes
object_size_1k
object_size_10k
object_size_100k
object_size_1m
object_size_10m
object_size_100m
object_size_1g
recv_sub_time
recv_sub_count
hash_sub_time
hash_sub_count
deliver_sub_time
deliver_sub_count
hit_sub_time
hit_sub_count
prehash_sub_time
prehash_sub_count
predeliver_sub_time
predeliver_sub_count

Writing Custom Queries (NRQL)🔎

You can use any of the values above with New Relic’s Query Language to create your own visualizations and reports.

Here are several examples using NRQL to create a few sample visualizations:

Further Documentation 📚

For further documentation on how this project works, building your own images, and enabling more features, check out the GitHub repo!

Contributing 👩‍💻

If you like this project and want to support its development, you are free to do so! There are plans to expand Fastly Tempo to additional backends such as Graphite, Splunk, and Datadog.

JavaScript version 🔗

This project was forked and developed in Python from the Fastly-to-Insights project. Checkout the original version written in JavaScript by New Relic engineers.

Conclusion ⭐️

CDN’s are generally Tier 0 services that need robust and continuous monitoring. Fastly provides great real-time metrics available via their API or consumption. Using Fastly-Tempo, you can build out a centralized dashboard for real-time alerts, monitoring and service visualization for Fastly using their API. If you followed along, you should now have a data pipeline to visualize all your Fastly services and monitor their performance. Enjoy! 🎉

Before we begin

Full Disclosure: This article is not sponsored (or promoted) by Fastly, Terraform, GitLab or any other organization. The sole purpose of this article is support the opensource community. 🖥️

Intro 💡

Over the past year, many organizations have gone through a transitional phase to adopt faster, smarter, and more developer friendly technologies. For many companies, this involved migrating their entire CDN (Content Delivery Network) to Fastly. For these organizations it can also be the prime opportunity to adopt Infrastructure as Code (IaC) methodologies and a robust pipeline for Continuous Delivery.

Key Terms:

• CDN: A “Content Delivery Network” (CDN) is a geographically distributed network of servers to deliver web content to users. Think images, html, JavaScript, and API responses. Fastly is the CDN used in this article.
• IaC: “Infrastructure as Code” is the process of managing and provisioning infrastructure through machine-readable definition files, rather than physical configuration or interactive configuration tools. We will use Terraform as our tool for IaC in this article.
• CI/CD: “Continuous Integration and Continuous Delivery” is an engineering principal for the building, testing and deployment of applications. We will be using GitLab CI in this article.

The Open Source Fastly-Framework

The entire framework for this article and project can be found on GitHub. The source code also contains a lot of docs pages and in-line documentation for usage. Full Link: https://github.com/GrantBirki/fastly-framework

Benefits

There are many benefits to using these three technologies together — here are just a few:

• Using Git as a version control system for all Fastly changes
• Eliminate code reuse through shared VCL files, Snippets, and Terraform configuration blocks
• Test your services through a CICD pipeline before deploying them
• Integrate with ChatOps for deployments (Example: Slack)
• Quickly create new services from templates with make service - Using Jinja and Python
• Adopt Infrastructure as Code methodologies with Terraform
• Promote a peer-review culture through merge/pull requests
• Create your own pipeline stages for robust testing, alerts, approval, and much more

Let’s dive in!

Prerequisites 📝

Here are the prerequisites you will need to follow along with this article:

• A Fastly account — Free!
• A GitLab account — Free!
• An AWS account if you wish to use Terraform Remote State — Free tier eligible
• You own domain — Replace all occurrences of example.com in this guide and the framework repo with your domain.

Fastly ⏰

I may be a little biased and have only had the opportunity to work on a couple of CDNs but I must say, Fastly is awesome. Don’t just take it from me, here are other companies that use Fastly:

GitHub, Imgur, Reddit, Stripe, New Relic, The New York Times, Kickstarter, Yelp, Shopify, BuzzFeed, Kayak, USA Today, The Guardian, and many more

As the name states, Fastly is fast, especially when it comes to deployment times. When you make a change to a service in Fastly, your changes are deployed globally in under 60 seconds. Other CDNs that are out there have ~10 minute deployment times. With Fastly, you are now able to build, test, deploy, and validate a service before other CDNs can even activate a service!

Not only is Fastly fast but it is also developer centric. This means that everything you can do in the Fastly console, you can also do via the Fastly API or with Terraform.

Let’s break down Fastly for understanding and then explain how we can leverage Terraform to build Fastly services:

• Fastly is a CDN. This means there are servers all over the world serving requests for Fastly Services.
• Fastly serves requests based on domains. We give Fastly a domain and it listens for requests to this domain: www.example.com
• Fastly fetches content from backends. We provide Fastly with a backend (ex: S3 bucket with images) and Fastly will serve content from these backends to clients.
• Fastly uses VCL. Varnish Configuration Language is the code we write to fine tune how Fastly responds, caches, and processes requests to our domains and backends.

Example of a Fastly Service

A Fastly service that listens for incoming requests all around the world to www.example.com.

1. A request comes in to www.example.com/cookie.jpg and Fastly begins processing.
2. Fastly executes the service’s VCL code which we uploaded.
3. The VCL code states that all requests with .jpg file extensions should go to a static S3 bucket to get assets.
4. Fastly checks its cache for this image before requesting it from the backend. Fastly determines the image is not in it’s cache.
5. Fastly requests cookie.jpg from the S3 backend.
6. Fastly responds to the client with cookie.jpg
7. www.example.com/cookie.jpg renders on the client’s browser.

To accomplish the example above, we need to build a Fastly service, define the domains to listen on, backends to fetch data from, and VCL to process requests. Luckily with Terraform, we can define all this as code!

Now let’s check out how you can get started writing some Infrastructure as Code and build a Fastly service and configure these components with Terraform!

Fastly Service with Terraform ⚙️

The snippet below shows how you can make a simple Fastly service with Terraform:

resource "fastly_service_v1" "fastly-service" {
  name            = "www.example.com"
  activate        = false
  version_comment = "Hello World" 

domain {
  name    = "www.example.com"
  comment = "Example Domain"
  }

backend { 
  name          = "S3_Example"
  address       = "example.s3-website-us-west-2.amazonaws.com"
  override_host = "example.s3-website-us-west-2.amazonaws.com"
  port          = 80
  }

vcl {
  name    = "main"
  content = file("fastly.vcl")
  main    = true
}

}

This example would build a basic Fastly service that serves requests to www.example.com from a S3 website backend.

You will need to replace all occurrences of example.com with your own domain

Note: you will need to create the fastly.vcl file listed above and place it into the same directory as you are running your Terraform commands. The fastly.vcl file needs to contain the Fastly boilerplate as a starting point. Simply paste the boilerplate into your fastly.vcl file. For reference you may view the example service folder for using Fastly + Terraform + the adapted VCL Boilerplate in the framework here.

Building a Fastly Service

Once you have Terraform installed, a valid fastly.tf file, and a fastly.vcl file (with the boilerplate) you are ready to build your service!

1. cd into the same directory as your files listed above
2. Get a Fastly API key from your account page and set it as an environment variable like so: export FASTLY_API_KEY="<your_key_here>"
3. Run terraform init
4. Run terraform plan
5. Run terraform apply

Check the Fastly console to see your new service!

Note — If you are having any difficulties with this step please refer to the following documents as guides:

• Fastly Terraform Provider
• Fastly Developer Guide
• Learning Terraform
• Getting Started Framework Documentation

Building a CI/CD Pipeline 🔨

So far we have seen the core components of a Fastly service and how we can create one with Terraform by hand. However, in the real world we do not want a bunch of engineers making changes by hand, with no version control, and without a process to make changes uniformly. This is where pipelines come into play.

Intro

A CI/CD pipeline is a series of steps that must be performed in order to deliver a new version of a service. They are repeatable, automated, and reliable ways to release and deploy code.

There are several big players in the space of CI/CD:

• GitLab-CI
• GitHub Actions
• Jenkins
• CircleCI

This project is using GitLab-CI for the CI/CD pipeline. However, you can use any CI/CD platform you like and follow the Fastly-Framework as a guide for what you can create.

Create Your Repository

The first step to creating a CI/CD pipeline is to create a Git Repo where our code and configuration will live. Since we are using GitLab in this article we can create a repo there.

If you haven’t cloned the Fastly-Framework yet, please do so now:
git clone https://github.com/GrantBirki/fastly-framework.git

• Create a new repo in GitLab

• Clone your new repo locally:
  git clone https://gitlab.example.com/<username>/fastly.git
• Copy the Fastly-Framework contents into your new GitLab repo locally:
  cp -r fastly-framework/. fastly/
• Create a new branch:
  git checkout -b "initial-fastly-build"
• Add, Stage, and Commit all files:
  git add -A && git commit -m "Initial Fastly Repo Commit"
• Push your changes into GitLab:
  git push --set-upstream origin initial-fastly-build
• Check back into GitLab. You should see your branch and have the option to create a Merge Request now:

• View the Merge Request and the CI/CD pipeline which was automatically created:

You will notice that the pipeline starts to run right away in the Merge Request above. However, it fails on the first stage. This is expected as we have not yet configured the pipeline… yet.

Configuring Pipeline Stages

The first step to getting our pipeline to actually run successfully is to configure pipeline stages.

For this section we will referencing the .gitlab-ci.yml file frequently. It can be found in the Fastly-Framework here.

• Edit the .gitlab-ci.yml file to configure the CI/CD Stages you wish to use.

stages:  
  - repo-check 🗺️
  - plan 📝
  - test 🧪
  # - metrics build-and-push 📊 (optional)
  # - approval 📯 (optional)
  - apply ⚙️
  - deploy 🚀
  - rapid-rollback 🔄
  # - metrics deploy 📊 (optional)

All the stages listed as (optional) above may be removed:

approval 📯 is used for ServiceNow automated change requests. More info can be found here.

metrics build-and-push 📊 and metrics deploy 📊 are used for aggregated metrics collection and publishing to New Relic. More info can be found here.

For the sake of simplicity, this would leave us with the following stages once the optional ones are removed:

stages:  
  - repo-check 🗺️ #(runs on merge_requests)
  - plan 📝 #(runs on merge_requests)
  - test 🧪 #(runs on merge_requests)
  - apply ⚙️ #(runs on master branch)
  - deploy 🚀 #(runs on master branch)
  - rapid-rollback 🔄 #(runs on master branch)

To see what each stage does, please see the Pipeline documentation in the Fastly-Framework. As a helpful tip, you can see where each stage will run above: merge_requests or merges to the master branch

Note: If you delete the optional stages above please also delete their related references later on in the .gitlab-ci.yml file. For example, if you are not using the approval stage, make sure to delete the block below (it should already be commented out anyways):

Build our Default Pipeline Image

Now that we have our initial stages setup, we can begin configuring the basics of our pipeline. First off, we will need a default image for our pipeline. This image will need the following dependencies:

• Terraform
• Python
• AWS CLI (If using a remote S3 backend for Terraform) — suggested
• CURL

To create this image, you can view the code/ci/docker folder of the Fastly-Framework for instructions. This folder also contains a Dockerfile to easily build the image.

Once you have built the image, you will need to push it up to GitLab’s container registry so the pipeline can easily access it.

Run the following commands from the code/ci/docker folder:

docker login registry.gitlab.com
docker build -t registry.gitlab.com/<account>/<repo>/<image>:<tag> .
docker push registry.gitlab.com/<account>/<repo>/<image>:<tag>

The exact <path>/<repo>/<image>:<tag> to your image my differ depending on what you name it and your registry’s org structure. No matter what you name it you just need to ensure that the default: image: line in your .gitlab-ci.yml points to this image.

stages:
  ...
  ..
  .

default:
  image:
    <GitLab URL>/<repo>/<image>:<tag>

Now our pipeline will be able to access this image and it will use it as the default for all jobs and stages unless another image is specified.

Configure Pipeline Variables + Terraform State

The pipeline needs two types of authentication in order to run. It needs to be able to authenticate to Fastly via an API key to deploy changes, and it needs to be able to authenticate to a remote backend like AWS for Terraform state.

Both of these variables/credentials can be configured via the GitLab console. Steps for doing so in the GitLab console can be found here.

For Fastly, this authentication is very straightforward. Simply follow these steps to create an API token with Fastly.

• Add the API token for Fastly to GitLab CI variables as a key:value
  pair:
  FASTLY_API_KEY: <value>

For Terraform Remote State authentication, this can be done in a variety of ways and you will need to configure this on your own. A common workflow is to use AWS as a remote state for Terraform with S3 and DynamoDB. There are many ways to authenticate to AWS and a simple/common one is to use static IAM user credentials (there are safer methods but this is just an example). You could add your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as GitLab CI variables. Then when plan 📝 , test 🧪 , and apply ⚙️ stages run, credentials are automatically set as they are present as environment variables. To see how this works you can checkout AWS documentation here.

If you go with this method above, it should just work. If you do any method requiring AWS tokens, or use a service like Vault you will need to edit the following files (below) and add your custom logic to get necessary remote state credentials.

code/ci/plan/plan.sh
code/ci/test/test.sh
code/ci/apply/apply.sh

It is highly suggested to use a Terraform Remote State. This framework uses the assumption that you have Terraform remote backend configured using AWS S3 and DynamoDB. To set this up, please reference the following guide.

If you do use this method, you will need to make a few additional edits:

Reminder: Make sure to be replacing example.com with your own domain in all occurrences.

• Enter the services/ folder
• Enter both folders www.example.com and nonprod.example.com and make the same following edits to the config.tf file

terraform {
  backend "s3" {
    bucket         = "example-terraform-state-bucket" # set to your own S3 bucket name
    key            = "fastly/services/www.example.com/terraform.tfstate" # change www.example.com
    region         = "us-west-2" # put your desired region here
    dynamodb_table = "terraform-lock"
    encrypt        = true
  }
}
provider "aws" {
  region = "us-west-2" # put your desired region here
}

• Make very similar edits to the code/ci/test/test.tf file

terraform {
  backend "s3" {
    bucket         = "example-terraform-state-bucket" # set to your own S3 bucket name
    key            = "fastly/services/test-servicename/terraform.tfstate" #ID0001 - #Do NOT change this line
    region         = "us-west-2" # put your desired region here
    dynamodb_table = "terraform-lock"
    encrypt        = true
  }
}

provider "aws" {
  region = "us-west-2" # put your desired region here
}

The edits you make to these files will be directly related to how you setup your Terraform Remote State in AWS.

All three files you just made edits to should have the same bucket and region . Each file will have its own key as that will be the unique path to your state file for each Fastly service you are building with Terraform. The only oddball is the test.tf file. This is because the test 🧪 stage of the pipeline works a little differently… It works by creating an ephemeral Fastly service. This is so that you can validate the VCL you are uploading before you actually make changes to your own service to avoid tainting your Terraform state. It also allows you to write custom tests against this ephemeral service. The test 🧪 stage essentially just creates your service with a unique “test” name and then instantly delete it (unless you write custom tests in before deletion). The ephemeral test service name will look something like this in Fastly for its short existence: $CI_COMMIT_SHORT_SHA-TEST<domain> . This is set through the test.sh file, the bash sed command against the test.tf file, and the domain block name = “${var.FastlyEnv}<domain>" in each services/<service> folder.

Whew! We just covered a lot there… Let’s summarize the Variables + State section:

• Set an environment variable named FASTLY_API_KEY with your Fastly API key through the GitLab UI.
• Setup credentials that the pipeline can access and authenticate with for your Terraform Remote State (Ex: AWS access/secret keys).
• Edit each fastly.tf file for each service in your services/ folder to point to your Terraform Remote State locations.
• Edit the code/ci/test/test.tf file in a very similar manner to the previous step. Follow the #comments in the file.

Trigger and Run the Pipeline

Now that we have configured our .gitlab-ci.yml file for our pipeline, the next step is to trigger our pipeline and test it to ensure all the pieces work!

You should still have the same Merge Request/Pull Request open from when we first pushed our code up to GitLab/GitHub. If you don’t, follow the steps above to create another MR. If your MR is still open, let’s make a new commit with our changes and push it up!

On every commit to our open Merge Request, GitLab will re-run all jobs that reference the merge_requests requirements. Example:

only:
  refs:
    - merge_requests

However, it will only run merge_requests jobs if all other criteria is met. If you take a look at the .gitlab-ci.yml file, you will notice that we try to build two Fastly services: www.example.com and nonprod.example.com . Taking a look at the plan stage for www.example.com in our yml file we can see the following job defined:

plan:www.example.com:
  stage: plan 📝
  script:
    - sh code/ci/plan/plan.sh
  only:
    refs:
      - merge_requests
    changes:
      - services/www.example.com/*
      - code/logs/log_format.json
      - code/snippets/*
      - code/terraform/*
      - code/vcl/*
  artifacts:
    untracked: false
    expire_in: 1 days
    when: always
    paths:
        - "services/*/*plan*"

Lets break down what this job is doing:

• Running a job called plan:www.example.com
• The job is attached to the plan 📝 stage
• The job will execute the code/ci/plan/plan.sh script
• The job will only run on merge_requests
• The job will only run if changes are made in any of the following locations: services/www.example.com/* , code/logs/log_format.json , code/snippets/* , code/terraform/* , code/vcl/*
• The job will produce an artifact and save it for 1 day. Note: The artifact that is being saved is the plan file that is created after running terraform plan

Now that we know the criteria for triggering this job lets push up another commit to our merge_request . The only change we need to make is add a newline or perhaps a #comment to any file services/www.example.com/* . This will make the pipeline think that a “change” has occurred in our service and trigger related pipeline jobs. For this example, I will add a single newline to both services/www.example.com/fastly.tf and services/nonprod.example.com/fastly.tf .

This will trigger the pipeline to build or push new versions of these services to Fastly. Lets check our pipeline status in GitLab:

Our merge_request pipeline has passed! 🎉

Let’s merge our change now to the master or main branch and trigger our deployment pipeline!

After clicking merge in the GitLab UI we can see our deployment pipeline is immediately kicked off:

Now if we check our deployment pipeline we will see that the apply ⚙️ stage has kicked off right away:

Remember, you can check out the pipeline.md docs to get more info on a pipeline stage.

Apply ⚙️ — The apply phase pushes up an inactive service which you can review in the console. This is useful for a final review before deploying to production.

Let’s view the Fastly service which the apply ⚙️ stage has created for us in Fastly:

It is always good practice to take a look at the service and its associated version in Fastly before triggering the manual Deploy 🚀 stage. In Fastly, this can easily be done by clicking on “Diff versions” in the UI. An example of how to do this can be seen below:

Note: Since we are pushing up our first ever service with this pipeline it will be Version 1 and we will not be able to run a “Diff” on the service. Keep this in mind though when running your next pipeline.

Now let’s move onto the deploy stage…

Deploy 🚀 — This phase activates the service via an API call to Fastly.

Click on the job for the service you want to deploy. You can also click the top “play” button to deploy all services at once (risky — You should always run your nonprod services first).

Once our nonprod service is deployed and it looks good we can deploy prod (www.example.com):

Yahoo! Our deploy pipeline has successfully passed and our Fastly services are activated! 🎉

Note: The Rapid-rollback 🔄 stage at the end of the pipeline is manual and is for rolling back a service if the deployment causes issues:

Rapid Rollback 🔄 — This phase is a break glass option to rollback the change made to a service. It should be used only if needed. Documentation Link

This means that if you have made it through the Deploy 🚀 stage you have successfully pushed out your first Fastly change with Terraform and a CI/CD pipeline. Congrats!

Summary ⭐

We just covered a ton of info and if all went well, you now have a working CI/CD pipeline to consistently deploy Fastly services in an automated fashion. Let’s summarize what we just did to connect some neurons:

Fastly

• Created a fastly.tf file with our general domain and backend info
• Created a fastly.vcl file with the Fastly VCL boilerplate
• Used Terraform commands locally to build a Fastly service

Pipeline and Terraform

• Built a GitLab repository using the Fastly-Framework
• Built a default image with Docker to run pipeline jobs
• Pushed our default image to the GitLab container registry
• Setup Terraform Remote State using AWS S3 + DynamoDB or a comparable method — Related Guide
• Set FASTLY_API_KEY and AWS credentials as environment variables for our pipeline jobs
• Point each services/<service>/config.tf file and code/ci/test/test.tf config file to your Terraform Remote State
• Create a new branch and merge request to trigger our pipeline
• Merge our change with the main or master branch and run the deployment pipeline
• View our shiny new services in Fastly!

Conclusion 🎇

Pipelines, Infrastructure as Code, and Automation are here to stay. Being able to leverage these technologies for consistent, fast, and reliable deployments is incredibly powerful. These benefits can be amplified when using critical services like Fastly that are the entry point for entire domains. Whether you are an organization of 10 people or 10,000 people, you can benefit from all that CI/CD methodologies have to offer.

I hope you enjoyed this article, learned a thing or two, and got a useful intro into the world of CI/CD with Fastly. If you haven’t already, please checkout the open source framework of this project on GitHub. There is a lot more documentation, code examples, and notes in the repo to help you get a working pipeline stood up with Fastly + Terraform.

❤️ Opensource

This project is 100% opensource and free for anyone/everyone to use. All contributors are welcome. Feel free to open pull requests, leave comments, or fork this project for your own use.

Intro 💡

The pandemic shifted the way customers interact with their favorite cafes almost overnight. Restaurants had to adapt to serve their customer’s digitally in a world where food and people always went hand in hand.

Eltana had already been focusing on its digital customer experience for a while now with online pickups, preorders, and catering. This ultimately helped Eltana be well positioned for a huge shift in customer behavior during COVID-19. By having a solid digital presence and foundation, Eltana was able to pivot and quickly adjust for a drop in physical customer interactions and a sharp increase in online sales. For Eltana, there was a key area that they needed to conquer to succeed. That area was online delivery.

The Problem 💥

The challenges that Eltana (and many other restaurant businesses) faced was online sales. Eltana needed a way to shift from in-store transactions to a hybrid online business to succeed. They needed to make this shift rapidly and work with their existing infrastructure and staff. This article will explain how I designed and implemented an online ordering and delivery routing engine on top of Eltana’s existing infrastructure with zero licensing, zero monthly fees, and with entirely serverless infrastructure.

Eltana’s Requirements:

Eltana needs to be able to do large deliveries each day. Eltana has their own delivery vans and drivers which they use to fulfill large event and group orders (think birthday parties, corporate events, etc.) so they have the equipment and staff to handle bulk orders already. Now they need the code to process, route, and ultimately get bagels to customers.

• Customers need to be able place an order online
• Orders need to be routed in the most efficient manner
• Delivery drivers need to be able to follow this route via a phone or tablet
• Bakers need item totals so they can prep before orders go out
• No added licensing, hardware, monthly costs, or overhead

The Solution ✔️

The solution included several components and met all the requirements stated above:

Tech Stack:

• Python
• AWS
• Lambda
• Google Maps
• Here API
• Square API

Square Online Store 🥯:

The Square Online Store is a front end service which customers interact with to place their orders. They place an order for the “Neighborhood” they are apart of and then their order is delivered in that neighborhood batch. Store available here 🔗.

Routing Engine ⚙️:

The Routing Engine (Engine from here on out) was truly the bread 🍞 and butter 🧈 of this project.

What does it do?

At a high level, the Engine inputs customer orders and outputs them in an routed list. This allows delivery drivers to efficiently deliver their bagels in the morning.

Let’s dive in!

• The inputs for the engine are customer orders 💁
• The output of the Engine is a Delivery Manifest 📃

The inputs are collected when the Engine runs. These inputs are customer orders which include name, address, items, and any notes the customer left for delivery.

{
  "orders": [
    {
      "id": "7227c0c1-198f-3719-a32d-d99a61d33589",
      "neighborhood": "WEST-SEATTLE",
      "address": "1234 1st Avenue N",
      "city": "Seattle",
      "state": "WA",
      "zip": "98101",
      "name": "Indiana Jones",
      "phone": "+1 123-456-7890"
    }
  ]
}

The outputs are one or multiple Delivery Manifests which are emails containing all routed orders, their details, and spreadsheets for order preparation. Real world example below — Note: customer data and revenue have been obfuscated.

How The Engine Works ⚙️

The Engine can either be triggered manually through the management web app (more on this later) or via a scheduled ⏰ Lambda trigger. The Lambda trigger goes off every night at 11:00pm PST. Either way, the trigger provides the Neighborhood for which orders are to be routed. For example, if triggered via the web app, a manager provides a Neighborhood to collected and route all orders within. This way all orders for West Seattle can be routed together for delivery the next day.

Once triggered the Engine searches for all orders within the supplied Neighborhood from Square’s Order API. These orders are collected and stored in memory.

Once all the orders for a given “Neighborhood” are collected the Engine translates all the addresses into coordinates, sequences those coordinates via an algorithm that searches for the fastest route, and then populates that route into a usable Google Maps URL 📍 for the delivery drivers. The Engine then kicks off an automated email with the routing sequence and all relevant order data. This email is referred to as the Delivery Manifest as seen in screenshots above.

High Level Diagram 🗺️

Management Console — Web App 👨‍💻

For ease of use, Eltana’s managers are also able to trigger Manifests with a few clicks via a custom web app. This allows for Manifests to be regenerated if orders come in late, if unexpected errors occur, or in case they want to tweak the routing algorithm (shortest vs fastest).

Upon clicking GENERATE 🚀 a manager can expect a Manifest to land in their inbox in less than 60 seconds.

Costs 💸:
Since this entire project is based off of Serverless technology that is within the “always free / free tier” of AWS there are zero monthly costs associated with this project’s infrastructure. In addition to that, there was no added licensing or service fees. This is because the Square Online Store and API are free for businesses that use their POS solutions already. Here API is also free under 250K requests per month for commercial use (which Eltana is well under).

Measuring Success 📈

Cool, so that’s a lot of tech. But does it work?

In order to see if this investment in technology is actually worth it we need to measure the outcomes before and after. Luckily, we have data to back us up!

Pre-COVID Era

In the era before COVID, Eltana was accepting its own online orders through Formstack for pick-up and delivery. The delivery orders were more geared towards group catering and events, while the pick-ups were for typical customers on the go. This data goes all the way back to 2018.

Number Crunching Time

The year prior to COVID-19 (Feb 2019 — Feb 2020) Source: Formstack data export

• Total Online Orders: 195
• Total Bagels Sold Online: 2465

COVID-19 era (Feb 2020 — Feb 2021 time of writing) Source: Square Online Store data export

• Total Online Orders: 8,100
• Total Bagels Sold Online: 115,173

More Numbers COVID-19 era…

• 4053.85% increase in online sales
• 4536.75% increase in online bagels sold
• 9340 bagel spreads sold
• 10.52% cart conversion rate (All time) — Last 30 days 15.65%
• 6.83% true conversion rate (All time) — Last 30 days 10.49%

How about sales?

Not only were sales strong right from the start, they continued to stay strong and are even increasing gradually from the beginning of 2020.

So back to our opening question…

Cool, so that’s a lot of tech. But does it work?

Yes, yes it does!

We can see that from the start of Eltana’s Online ordering platform, sales are strong and they continue to stay strong. Conversion rate is also out performing for the restaurant category as well. On top of all that… we see a whopping 4536.75% increase in bagels sold through online channels and at the end of the day, that’s all that really matters. Success! 🍾🎉

Summary

What problems have we solved?

• Customers are able to easily place an order online
• Orders are routed in their most efficient manner for delivery drivers
• Delivery drivers are be able to follow this route via a phone or tablet
• Bakers have item totals so they can prep before orders go out
• No added licensing, hardware, monthly costs, or overhead
• Eltana can still utilize existing infrastructure: delivery vans, Square POS, prep kitchens, and employees
• Eltana is able to prep, route, and deliver to distant neighborhoods with 300+ orders 🎉

PS if you want to check out the Online Store where the magic happens, here is the link www.eltanabagels.com

Closing Thoughts 🥯

This year, the pandemic has proven concretely that being able to adapt rapidly is a requirement for success. This is especially true when it comes to technology. Technology can no longer be an afterthought, especially for businesses that have not traditionally relied on it as a core part of their businesses. Investing in technology doesn’t have to be difficult or scary either, in Eltana’s case it was an enhancement to their pre-existing work flows that allowed them to fulfill more orders, do so efficiently, and with zero monthly costs.

Technology can be your best friend, so embrace it.