Microservices at Stootie

Stootie is the first application for peer-to-peer services in France. A simple, fast and cheap solution to find a hand to fix a leak or move a sofa. We design and produce a technology platform for the general public in the form of applications (iOS, Android and Web) and private and partner APIs.

When I arrived at Stootie, I did an audit of this platform and I confronted it to the ambitions of our CEO, Jean-Jacques Arnal.

In less than 5 years, the organic growth of the company led all the different technical contributors to setup an API Platform.

This backend reached at the beginning of 2016 more than 450 endpoints and covered the totality of functional needs of the company: the product (Mobile and Web), the exposure of data to the moderation team and a graphic user interface for statistics with numerous indicators.

It had a known limit of traffic (around 400 req/sec) and had been designed for vertical evolution, always increasing the hardware capacity on which it was installed.

We were at this moment in a dead end, sure to succeed on the business part but strained by our current system, unable to evolve.

We stepped up our level of ambitions when preparing our 4th Series-A fundraising and initiated two pivots which transformed our company, both technical and organizational. I describe here the technical one.

Retrospective on software architecture

During the 90’s, developers where artisans, realizing unique piece of code, monolithic. When software have expanded, the base code became quickly jumbled, illegible, incomprehensible, and if we changed something on the left side, this might have consequences on the right side. Not really reliable and so expensive.

In the 2000s, the advent of Java and its first frameworks brought a first distribution of the code, splitting into Model View Controller (MVC), where the elements of a software were stored in different layers (lasagne code). This guaranteed a better independence of each layer and, in fact, its robustness and extensibility.

Unfortunately, companies have grown, globalizing this layered architecture model to sprawling levels, thus replicating spaghetti code within each layer of the model.

Since 2012, the microservices approach is convincing more and more companies whose agility to adapt their technical platform is critical to their business: Amazon, Google, Netflix, Spotify, etc.

Microservice vision is borrowed from the Linux philosophy: full of small tools and each tool has a single responsibility and realizes it perfectly.

This architecture involves cutting out all of our code in layers to have a set of small software dealing with one and only one feature.

This is the approach we have adopted at Stootie to meet our ambitions as the world’s leading collaborative economy platform.

Technological pivot

We decided to rotate in January towards a microservices architecture in the following ways:

  • The services in place can not stop evolving or functioning;
  • A microservice is always attached to a finite functional domain, thus reinforcing the DDD;
  • A microservice defines an interface contract that is stable over time;
  • A microservice belongs to one and only one technical owner;
  • A microservice is implemented on its own stack and one can only assume this stack when the appropriation of the need has been realized;
  • The tech owner has the freedom to choose the technologies he wants to use but must “prove” his stack to the rest of the team;
  • A microservice is developed only in a very short period of time, namely two weeks because in two weeks it is not possible to recreate spaghetti code in microservices;

These simple and precise rules allowed us to quickly set up a team where each member became a tech owner of one or more topics.

Sam Newman, in his book “Building Micro Services”, gives many feedbacks on the establishment of microservices. It includes a number of tips that we have applied that have saved us a lot of time:

  • When cutting the monolith, always start with the data;
  • Well weigh the pros and cons between the synchronous and the asynchronous (we have changed our opinion several times on some microservices);
  • Do not cascade synchronous microservices;
  • Use the CI / CD from the beginning of development and for each microservice;

He also defines an architecture model called Backend For Frontend (BFF), which corresponds to a gateway API between the outside of the company and the microservice ecosystem. We put it in place easily and created a complementary principle, the BFB — Backend For Backend — which corresponds to a façade interface for external services.

Basic lessons

After one year of testing and discovery of microservices, we have learned several fundamental lessons:

  • Define the functional areas to be reduced to autonomous minimum perimeters;
  • Everybody in the team is a Dev/Ops, let devs learn how your cloud works;
  • Migration means technical migration to the same identical functional scope (evolving is tempting and dangerous)

Conclusion

Should a startup migrate to a microservices architecture?

You have to be willing to do it and go all the way.

Keep in mind that this is costly in time because each feature is specific and requires custom engineering. The technical team spent 3 months developing the first microservice in order to implement a continuous integration / continuous delivery pipe on each technology. The next microservice has been released in one week. Exciting.

The results are there, we release a new micro services every 2 weeks and have never stopped delivering new functionalities in production.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.