4 Yubl: Architecture highlights, lessons learned

 

This chapter covers

  • The original Yubl architecture and its problems
  • The new serverless architecture and the decisions behind it
  • Strategies and patterns for moving monolith applications to serverless
  • Lessons learned from this migration

In April 2016, I joined a social network based in London called Yubl. There I inherited a monolithic backend system written in Node.js and running on a handful of Elastic Compute Cloud (EC2) instances. The original system took 2.5 years to implement and had a long list of performance and scalability issues once it went live. With a small team of six engineers, we managed to move the platform to serverless over the course of six months. Along the way, we added many new features and addressed the existing performance and scalability issues. We reduced feature delivery time from months to days, and in some cases, hours. Although cost was not the main motivation for undertaking this transformation, we made a 95% savings on our AWS bill in the process. Let’s take a peek at the original Yubl architecture.

4.1 The original Yubl architecture

4.1.1 Scalability problems

4.1.2 Performance problems

4.1.3 Long feature delivery cycles

4.1.4 Why serverless?

4.2 The new serverless Yubl architecture

4.2.1 Rearchitecting and rewriting

4.2.2 The new search API

4.3 Migrating to new microservices gracefully

Summary