Building Bastion

The story of building a back-end as a service hosted on your own cloud account

Sometimes it is best to go ahead and build something on your own to satisfy your creative itch (AKA DIY). I wrote this article to explain our motivation behind building Bastion (from my perspective) and the challenges we’ve faced on the journey.

When I teamed up with Adam, Pavlo and Reilly, we didn’t have an exact idea of what to build apart from some concepts we wanted to explore as part of this project.

This was my first transatlantic effort. Reilly and Adam are based in Boston and Pavlo lives in Connecticut.

Interestingly, 5 hours difference worked perfectly where I had enough time in the mornings to focus on coding before meeting up to collaborate on various parts of the project. Finally, in late April we released the alpha version of Bastion.

Why BaaS #

Back-end as a service(BaaS) is a polarising product amongst engineers. Some believe that you should never use it if you are a “real software developer”. This could be true, but it is an interesting challenge to build a reliable system that could serve as the backbone of a web app.

When we teamed up, we all knew that we wanted to build something that involves managing cloud infrastructure using an IaC (Infrastructure as Code) framework such as CloudFormation or Terraform.

Building a BaaS is a perfect challenge as it requires building all the minimum features required to manage a modern web app such as databases, authentication, object storage, networking, custom functions, etc.

It also requires sufficient tooling to be present for admins/users of the BaaS product, allowing them to debug, deploy, and teardown their services.

Certain security measures have to be in place like network isolation between services, and network policies to control traffic.

Lastly, it is a product! It needs to function and have pieces that allow users/admins to interact with their services and more importantly, to control the entire infrastructure.

Early Decisions #

To keep things simple, we decided to build this product for AWS only. It was going to be a self-hosted product that was bootstrapped via a CLI tool.

After the base infrastructure is deployed on the user’s own AWS account, a web dashboard becomes the control panel for your services. To avoid schema/data migrations we decided to use a document store.

Challenges #

1. User Authentication #

We decided to use session cookies against the JWT which is the industry standard to reduce application complexity. This helped us focus our energy on other challenges instead of dealing with session invalidation.

Bastion’s compute and database instances are located behind an application load balancer. We decided to use SSL offloading on the ALB to avoid dealing with the complexity of issuing certificates to app servers. However, this blocks secure cookies from being carried over to the app servers. We’ve enabled trust proxy on servers to resolve this.

2. Networking #

In a scenario where multiple app servers and their corresponding DB servers are deployed on different subnets, routing becomes complicated really fast. A load balancing/service mesh solution is required to control this. In scenarios where applications are frequently created/torn down managing these rules becomes tricky.

Instead, we used a service discovery approach where container tasks are created with a custom name and these are used for DNS resolution. This helped us avoid using extra infrastructure and the complexity of load balancing/app mesh since our use case was relatively simple.

3. Cloud Code Functions #

One of the key features of BaaS solutions is to ability to inject custom code so that business logic different from data manipulation can be executed. This is often needed when interacting with 3rd party APIs like payment systems.

We developed a system where users/admins can upload their custom code as a zip file. Bastion then creates a Lambda function from the zip file and deploys it into the same subnet as the application tier.

Conclusion #

I hope you liked this article. We worked on Bastion full-time for a couple of weeks in April 2022. There are a few things we keep on our radar as future improvements since we decided to stop working on it full-time. For these and many other details, take a look at our in-depth case study.