Scaling Via APIs
25 April, 2018
I started working for Trustpilot as an engineer when it was still a small startup. It didn't have any tech founders, so the first part of it was built by consultants, and then young, fairly inexperienced engineers, including me, were brought in to continue building code. We ended up with a big monolith, and as our company grew our services didn't scale. Just as bad, while the monolith continue grow bigger and more complex it became even more difficult to get new engineers onboarded.
We didn't have time to waste, we needed to hire, so we continued to hire aggressively. I started research to figure out how to solve the two problems, and eventually decided to start implementing microservices and APIs to a knowledge stack. We did this in an untraditional way. Usually, people start doing this by building a very flexible API. However, we decided to build one API to rule them all. It wasn't flexible, but was able to be built very quickly, and within a few months we had encapsulate our monolith with APIs. This then allowed us to tell of our teams to only use APIs to build new features while we set a few teams aside to migrate the old monolith out to microservices. As part of this we also set the foundation to be able to example re-write or re-plaform small pieces of the product without having to cover it all at ones. It enabled us to put focus on the areas that had the biggest problems first.
Look for opportunities where you can solve organizational issues with architecture. By doing this, we were able to separate our codebase into smaller, more manageable services with less complexity. We managed to build a setup were engineers become productive faster, enabling us to grow with the demand and to have independent teams that had the control of the technology needed to for their services to work best. Note: Were I have seen it very effective combining architecture and organizational challenges, it's not the case when combining feareus and re-platforming/re-architecture. Properly the most important engineering principle in my book is never to combine adding features and re-platforming at the same time. Seperate those two I have experienced always to deliver faster.
Pierre Bergamin, VP of Engineering at Assignar, outlines some useful tips for decoupling releases from deployment and increasing deployments by a huge factor, speeding up reverts and planning releases in a better way.
VP of Engineering at Assignar
Murali Bala, Director, Software Engineering at Capital One, outlines how he applied a root cause analysis to fix a recurring outage of their website.
Director, Software Engineering at Capital One
Tim Olshansky, EVP of Engineering at Zenput, explains all the challenges of migrating legacy software to the cloud emphasizing the importance of identifying the riskiest things first and applying small, incremental changes.
EVP Engineering at Zenput
Viacheslav Bessonov, Chief Technology Officer at Algalon Capital, describes the advantages and disadvantages of three different infrastructures and how he made the final decision on which one was best for his company.
Chief Technology Officer at Algalon Capital
Alessandro Pintaudi, Product Management Director at Payfit, talks about how teams need to focus more time on building the right things and how to keep doing it with scale.
Product Management Director at PayFit
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.