We value simplicity at Sunsave. In the engineering team, this means we prefer simple solutions. Sometimes this looks like choosing the tried and tested approach rather than the latest trend. Sometimes this means picking a tool that meets our needs at a given moment, knowing we'll want to revisit that decision down the road.

One of the choices we had to make early on was how best to build our marketing website. It was clear we needed to be up and running as soon as possible, despite our requirements still evolving.

With a small team, we needed to choose a tech stack that allowed us to get something launched fast. It also needed to let us make changes easily to support those evolving requirements. This is common wisdom in the startup world: prioritising speed of delivery and iteration.

We adopted AWS Amplify as the simplest solution that met these requirements and the decision paid off - we had people signing up through the website before we’d even officially launched.

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.

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

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? 

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.

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!

Whilst the entire process wasn't flawless, the result was a definite success. We’ve been able to build new features and services easily and quickly. We're no longer held up working around quirks. We’ve had no deployment scares! By following our guiding principles we now have a system that will continue to grow with us for a long time to come.

How we devised our guiding principles to build a system that's designed to stick with us for the long term.

Danielle Huntrods

Posts from Danielle Huntrods

Engineering at Sunsave: scaling for growth