Startups, ne laissez pas votre tech être un problème.
Initialement posté sur : https://www.wecraftapps.com/blog-startups-ne-laissez-pas-votre-tech-etre-un-probleme
Chez We Craft Apps nous sommes un Product Studio, nous développons pour nos clients des solutions Web et mobiles.
Quel que soit le stade du projet: POC, MVP ou la réalisation d’un produit plus mature, notre mission c’est d’aider nos clients à réussir leurs projets numériques.
En 8 années d’accompagnement, on a croisé pas mal de monde, des grands groupes étonnamment agiles, des startups qui n’en sont pas, des industriels, des organismes publics, des projets réussis et d’autres qui n’ont pas rencontré leur public.
S’il est difficile de se prononcer sur le core-business de chacun, nous avons un avis sur l’approche technique à avoir qui constitue, selon nous, l’une de nos valeurs ajoutées.
Certitudes
It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so. — Mark Twain
Nous rencontrons une multitude de profils de porteurs de projets et la plupart connaissent finalement assez mal la technique. Ce constat n’est aucunement une critique, sinon nous n’aurions pas lieu d’exister, pour autant, il arrive quelquefois, que des porteurs de projets viennent nous rencontrer avec des idées un peu trop précises sur les technos et architectures à mettre en place. Qui pourrait les blâmer de s’intéresser, de faire des recherches ou encore de faire confiance à un ami ? Seul souci, ils finissent par construire des certitudes dans un domaine qu’ils ne connaissent pas.
Et ça, c’est le début d’un problème.
Il m’arrive notamment de croiser certains points de préoccupation de la part des créateurs de startups, que je trouve très en décalage avec la maturité de leur produit, ou avec ses nécessités technologiques actuelles.
Par exemple : une architecture en micro services, la performance, le NoSQL (cette liste est en réalité beaucoup plus longue et peut contenir toutes technos/archi à la mode sur le moment 🥳)
En général ma réponse tient en quelques mots : “vous n’en avez pas besoin, vous essayez d’anticiper des problèmes qui n’existent pas encore”.
Mais alors, pourquoi tant de certitudes ?
En résumé ça donne quelque chose comme : les géants (GAFAM, grosses scale-up, etc…) utilisent ces solutions, ils sont successful, alors, pour être successful, moi aussi j’utilise la même sauce.
Uber, Pinterest, Slack et Instagram
Prenons le temps de regarder vraiment les choses avec quelques exemples en provenance d’Uber, Pinterest, Slack et Instagram. Avouez que le lineup est pas mal.
Uber
Chez Uber il y a eu une transition d’architecture en 2015, voilà ce que raconte Gergely Orosz de chez Uber :
[…] Uber went from monolith to SOA in 2015. This SOA followed a microservice-based architecture. And different engineers have been sharing what they’ve learned along the way: the steps it usually takes to build a microservice, addressing testing problems with a multi-tenancy approach or how and why teams use distributed tracing. […] All of these can serve as inspiration: but the end of the day, you need to make decisions in your environment that you think will work best. Anyone copying the likes of Google, Uber, Shopify, Stack Overflow or others when they’re not even similar in setup will be disappointed.
☝️ N’essayez pas de résoudre des problématiques que vous n’avez pas, une architecture en micro-service soulève énormément de nouvelles problématiques par rapport à un monolithe. Voyez ça comme des problèmes en moins si ce n’est pas nécessaire pour vous.
En 2011, les serveurs étaient en feu chez Pinterest, voila ce que raconte Marty Weiner :
In 2011, we hit traction. By some estimates, we were growing faster than any other previous startup. Around September 2011, every piece of our infrastructure was over capacity. We had several NoSQL technologies, all of which eventually broke catastrophically. [..] We intentionally ran away from auto-scaling newer technology like MongoDB, Cassandra and Membase, because their maturity was simply not far enough along (and they were crashing in spectacular ways on us!). Aside: I still recommend startups avoid the fancy new stuff […] Trust me. I have the scars to prove it.
☝️ Il faut replacer ce témoignage dans le temps, et comprendre que la problématique n’est pas fondamentalement de travailler avec du NoSQL ou pas, mais davantage d’avoir un recul par rapport à l’émergence de nouvelles technos : faire attention aux technologies un peu trop hypes, un peu trop miraculeuses, faire attention au marketing autour d’une techno/produit.
Slack
Fin 2016, Keith Adams alors chief architect chez Slack, partage des détails sur son architecture :
Slack consists of a sharded LAMP stack; webservers, memcache, and a fleet of mysql instances […] Users care that persistence works and they don’t lose data, not what the storage system is.
☝️ Cette phrase de Keith Adams témoigne de la simplicité avec laquelle il est parfois possible d’aborder les choses. Également, vos utilisateurs finaux ne sont pas intéressés par comment marche techniquement votre système, ils veulent juste que le service pour lequel ils payent marche.
Mike Krieger, co-fondateur d’Instagram raconte dans un article de 2013 :
As we’ve scaled Instagram to an ever-growing number of active users, Postgres has continued to be our solid foundation and the canonical data storage for most of the data created by our users. […]
☝️ Cette phrase est issue d’un article particulièrement intéressant sur l’usage de PostgreSQL chez instagram. Un choix simple, non hype, qui avec un peu d’imagination et un usage un peu avancé permet d’aller plus loin que ce qu’imagine, malheureusement, la plupart des utilisateurs de solutions alternatives.
Ne pas perdre son temps et son argent dans des sur-complexités inutiles
🙌 Ces acteurs du numérique méritent d’être regardés mais uniquement avec un recul suffisant pour mettre en perspective à travers le temps leurs évolutions. Il faut davantage regarder le point de départ que celui d’arrivée.
Pour insister sur cette mise en perspective, quand Gergely Orosz parle d’Uber en 2015, le NYTimes titre : Uber Valuation Put at $62.5 Billion et c’était aussi l’année des 1 billion rides. Plus vraiment le MVP d’une startup.
Êtes-vous déjà à cette étape ?
D’ailleurs, comprenez que si vous souhaitez tout penser par le prisme de l’hyper scalabilité, day 1, vous allez principalement réussir à faire deux choses : ralentir vos développements et multiplier le coût de votre solution par au moins 10.
Résultat des courses, votre time to market est naze et de toutes les manières vous n’avez pas cet argent.
Un maximum de valeur ajoutée avec peu de features
Le meilleur conseil que je puisse donner en général aux startups que j’accompagne c’est de délivrer un maximum de valeur ajoutée avec peu de features, mais des features différenciantes.
Pour ce faire, il ne faut pas perdre son temps et son argent dans des sur-complexités inutiles côté stack, infra ou architecture.
Plus votre stack technique est “boring”, moins vous aurez de chances de vous crasher à cause de celui-ci.
Les sujets concernés sont véritablement nombreux. Pensez-vous qu’une startup qui peine à trouver des clients doit ériger Kubernetes en première prio ? Malheureusement certaines pensent que oui et je suis confronté régulièrement à ce genre de discussions (nous avons d’ailleurs la chance en France d’avoir d’excellents acteurs du PaaS 🚀).
Au quotidien, j’essaie d’insuffler cette vision pragmatique à la fois dans l’aspect pédagogique auprès du client mais aussi du côté technique auprès de mon équipe.
- une architecture suffisamment simple pour pouvoir réfléchir rétrospectivement et évoluer vers plus de complexité quand c’est nécessaire,
- des bonnes pratiques et du code suffisamment propre pour que le projet soit reprenable et évolutif,
- une utilisation de solutions SaaS quand il n’y pas besoin de souveraineté,
- une utilisation systématique de PaaS.
