Taking Ownership and Re-architecting @ FARFETCH
By
Helder Sousa
Developer driven by challenges, nature lover, cars enthusiast, by the way, did you see my Diesel wallet?
View All Posts
Introduction
At Farfetch, we really care about our applications. Just like we treat our beloved pets, we are always aware of their needs and problems. We take care of them and want the best for them, so we are always thinking about how we can make improvements.
This article talks about the moment when our team took ownership of an existing service. We took care of it as if we had adopted a pet puppy and saw a happy and bright future for it!
When we design a service, we think carefully about it: we gather all the requirements, we create realistic SLAs (service level agreements), we measure the throughput in production and at the end, we release what we agreed. On day one, we had a service which performed as it was supposed to, but like a pet, as the service grows, new needs appear. More food, more toys to play with, the need for a bigger room, more attention - until we realise that the pet we adopted isn't a puppy anymore. The truth is that over time, the requirements change and we are no longer able to answer them effectively just by refactoring and adopting new technologies.
If a business deals with urgent requests that need to be completed in a short period of time, software should be extendable, modular and maintainable. Time to market is crucial and we have to strike a balance between a quicker or deeper approach, so it’s time to think about re-architecting!
But what does Re-architecting mean?
Re-architecting refers to looking at something that we have already built and then considering how we can make it simpler to enable us to grow it. It is the process of restructuring the application in a way that makes it possible to scale, to be more extendable, modular and maintainable, according to business needs.
How do we know that the proper moment for Re-architecting has arrived?
As part of our daily routine, we start by analysing our application’s logs. This process involves doing some tasks like keeping track of some metrics such as CPU usage, memory consumption or average response times. When they are not quite as we wanted them to be, we start thinking about how things may get worse or break our service. We could deliver some new features, but that would just be postponing the problem.
Well, this is the perfect time to start re-architecting. The main idea is to get rid of the legacy stuff. At this point, we can still manage to save the health of our services by re-thinking and paying off technical debt.
How do we Re-architect?
In order to tackle the re-architecting problem, we tend to follow a few steps:
- Analysis - We gather information regarding the major issues over the past year, from incident reports to error logs and resource consumption charts or any other information that could potentially result in catastrophic failures.
- Brainstorming - Gathering ideas for new approaches is crucial when re-architecting a microservice infrastructure. In this phase, it’s important to include the Product Manager, who can attend the current and future business requirements and the architects who can validate our approaches, resulting in several meetings to iterate the problem until we reach a solution that pleases everyone.
- Negotiation - We present the outcome solution for re-architecting to our Product Managers and Managers so we can allocate time for the implementation. Most Product Managers and Managers can be sceptical about the need for this redesign, so it is important to explain in detail the reasons behind these needs and how it could evolve in terms of scaling and future requirements.
- Implementation - The fun part - we get to code our vision. It’s important to take one step at a time: changing small parts, using mocking to validate single components, do A/B testing with feature toggles and making sure we are able to revert to the previous solution [1] if something doesn’t go according to the plan. After all that is done, make sure the new architecture is serviced by a small amount of production data and traffic, also known as a Canary test approach, to validate and compare results.
- Presentation - Compare results against the previous architecture and present them to other teams, architects and product managers. Gather feedback from colleagues and, if needed, improve the newly implemented architecture preparing it for rollout.
- Roll out - Prepare the finished architecture to be deployed at a global level. At this point, the architecture should be in its highest degree of quality and stability and will replace the current production implementation thoroughly. Maintaining a rollback mechanism in place for a while is still important.
Conclusion
For the last six months, we have been evolving the architecture of our application. We found ourselves rocked by emotion, with fear in our minds! We were concerned about the big changes that were required and we were afraid of not meeting expectations. We were afraid of failure and even of innovation. Learning is a lifelong journey which always challenges us and our team grew in ways we didn’t expect. In the last few months, we’ve realised how we strive for knowledge, innovation and ownership and how that has impacted our team’s trust and cohesion. Aware of the responsibilities involved, we overcame them and now we are better. We understand the importance of our role and always try our best. And the results were better than we expected; better performance, more usability, stability, scalability and with only one cost - more responsibility. This process took a huge amount of time and effort from the team but the outcome was a success for our application and for Farfetch, and it was all worth it. We are sure this will lead to a bunch of new requirements from our stakeholders, but we are ready for it and we want it!
Finally, we hope that you have all enjoyed this article. If you are in a similar situation, maybe you can follow our approach and have success just like we did.
