Engineering at Sunsave: scaling for growth

Growing pains

Soon, our team grew and our needs became a little more complex. Rather than one person deploying code once a day, we now had three people deploying several times a day. We often found ourselves slowing down as we worked around a quirk or tried to make the platform do something it wasn't really intended to. We struggled against this inflexibility. We also started to find issues with the safety of deployment pipelines and a lack of control over platform and language choices.

A few months after launch, our colleagues had setted on their workflows and their requirements were becoming clearer. The company had ambitious plans for growth. Now was the time to investigate alternatives to our current tech stack.

Requirements

We had some set requirements and some guiding principles. Otherwise, we tried to keep our minds open.

Our requirements were:

• Make use of our own and future colleagues’ experiences. To support this, we chose Node for the back-end. It has a rich ecosystem, and a large community. Between us we have many years experience in it. For similar reasons, we opted for React and NextJS on the front-end. Finally, we were already running on AWS and were comfortable and productive with it.
• Focus on delivering value. Some of us enjoy tuning build scripts or managing infrastructure, but that doesn’t get new features out to our customers. Whatever we chose should have sensible defaults and built-in force multipliers. For instance, we've found Typescript to be a force multiplier for its ability to remove a whole category of errors. A solution here would include things like built-in Typescript toolchains.
• Security. Our planning had pointed to a simple micro-service architecture being the best fit. This left us with some implications around security. VPCs seemed an obvious solution to keep our external surface area as small as possible. At the same time, we wanted to avoid having to set up a lot of networking and infrastructure so we could stay focussed on delivering perceptible value. A solution here would do the heavy lifting to create a secure network but be agnostic on platform. This would also let us configure our infrastructure as code to ensure we can keep track of changes and roll things back if they go wrong.
• Customers and colleagues shouldn't notice a thing. As we build both internally and externally facing products, there is no “good time” to perform a migration, so we need a solution that has a downtime of zero seconds.

These were our guides as we began to focus in on the more concrete decisions we’d have to make. Is there a back-end Node-based framework that meets our needs? How about relational or non-relational data stores? How will we manage and deploy our applications?

Decisions, decisions

Rather than defaulting to solutions we’d used in the past, we spent time researching, modelling, diagramming, and spiking. We already had a functional system, and had a good idea of our domain and how its entities related. Diagramming these out helped us uncover potential models and architectures. Tools such as ERDPlus and the C4 model were very helpful in this stage.

We explored tradeoffs between a relational and non-relational database approach. The cost and speed benefits of a non-relational approach were enticing. But to both model our domain and take full advantage of these speed benefits required a large degree of complexity, and we worried that this would be a barrier for new engineers joining our team. In the end we chose simplicity - tried and tested Postgres.

We researched a variety of Node back-end frameworks. Our final choice NestJS didn't start as the frontrunner - at first glance, certain aspects seemed more complex than ideal. We explored its features, matched against our requirements and those of its competitors, and we discovered that the apparent complexity allowed for a great deal of flexibility. In the end it won out due to its impressive feature set and extensive documentation.

We were now moving away from Amplify which had provided a fully-managed serverless stack and had to decide how to serve our applications. As we were sticking with AWS, we had many options, each with a plethora of acronyms. Keeping in mind our focus on delivering value, we wanted a solution that allowed us full control over our application architecture, but managed networking and security for us. In the end we chose ECS on Fargate.

Being fully managed, it handles networking and scaling complexity for us. This lets us focus on our application logic. It’s also container-based, which means that if our infrastructure needs change in the future, we can easily move to a different solution. We chose to manage all of this through an infrastructure as code solution called AWS Copilot. It's not as high-profile as alternatives like Pulumi or Terraform, but so far it's hit the sweet spot between flexibility, reliability, and simplicity.

Delivery

We’d researched, modelled, and made our decisions. Now it was time to deliver. We had a small team and couldn’t afford to block feature development whilst carrying out this migration.

But we were confident that another of our core principles could ensure a smooth transition - 'prefer simple solutions'. We like to tackle complexity through ‘shifting left’: planning and researching before writing any code. It’s easier to change code that hasn’t been deployed, and it’s even easier to change code that hasn’t yet been written.

The first step was to capture the current state of our tech stack. This would help us spot any areas where the migration might get a little tricky. Things like moving away from the all-in-one authentication functionality Amplify provided. To keep things simple, we didn’t change any functionality during the migration.

Once we’d captured the current state and noted any areas of uncertainty, we started to plan our approach. We broke everything down and mapped it to our new service architecture. Focusing on the back end, we coded and deployed each new service, adding thorough test suites at each stage. These sections were built, deployed, and tested independently, without impacting our live systems. Throughout, we were still planning and delivering new features.

After a few months - during which we'd also delivered a new photo upload flow for the account - our back-end was ready to go. We rebuilt the front-end in a canary build, migrated to our new back-end APIs, and updated our suite of end-to-end tests. Despite being a big-bang swap, our planning paid off here, with only two minor issues cropping up.

After thorough internal testing we were confident the new front-end was ready to go live. We migrated our existing data to the new database, and flipped the switch. To our end users, the transition went completely unnoticed — exactly as intended!