The document discusses how platform engineering transforms businesses by evolving from monolithic architectures to multi-service frameworks, emphasizing principles such as self-service, automation, and enhanced collaboration. It highlights the challenges and benefits of implementing platform engineering, particularly in the context of Doctolib, where it enhances developer experience and improves product delivery. Key recommendations include adapting monitoring systems, reviewing deployment strategies, and treating internal platforms as products to better serve internal teams.

1. From monolith to multi-services
How a platform engineering
approach transforms your
business ?
October 2024, 8th

2. About me
Senior Engineering Manager
Arnaud Héritier

3. About you

4. Summary
01.
The Platform Engineering
Journey
The Software Landscape Evolution
From Agile to DevOps
Platform Engineering: Principles,
Benefits and Challenges
Platform Engineering
in Action at Doctolib
Doctolib, an overview
PEER: Our Platform Engineering
Department
From Monolith to multi-services: A
Platform Perspective
02.

5. The Platform Engineering
Journey
01
The Software Landscape Evolution
From Agile to DevOps
Platform Engineering: Principles, Benefits and Challenges

6. The Software Landscape
6
200
2
202
4
2013
2000 2020
2010
AWS launches
public cloud
(IaaS)
Docker
2008
Google
launches
Google
AppEngine
(PaaS)
2014
Kubernetes
Spring Boot
2020
Open AI
GPT 3
Today, we have incredible power and flexibility but we also face
overwhelming choices.
2015
CNCF
Cloud Computing
Everything as a service
Pay as you go
Containers,
the new delivery unit
for cloud area
Generative AI and
Large Language Models
(LLMs)
2019
Quarkus
1999
ASF

7. The Platform Engineering
Journey
01
The Software Landscape Evolution
From Agile to DevOps
Platform Engineering: Principles, Benefits, and Challenges

8. The Agile (r)evolution
● Agile methodologies are improving of teams are developing software
○ Extreme programming (90s’), focuses on development quality:
■ automated tests, continuous integration, …
○ Scrum (2000+), focuses on team effectiveness and delivering a
product that matches the customer expectations:
■ short iterations with several rituals (Sprint planning, Daily
Stand-up, Sprint review and retrospective, …), product
management embedded in the team

9. DevOps, Let’s break the wall
● Agile improved the development methodologies
● DevOps aims to improve the deployment by
breaking silos:
○ Promotes early collaboration
○ Give developers a better knowledge on ops
○ Apply development practices to ops (gitops)
○ Mesure impacts (DORA, SPACE, … metrics)
● Extended to all silos: Dev(SecQA…)Ops
● Change management is the key!
http://dev2ops.org/2010/02/what-is-devops/

10. DevOps challenges
● DevOps is not a tool, it’s a mindset
● Shift-left doesn't mean developers are five-legged sheeps
● Giving autonomy doesn't mean abandoning unified tools and practices.
● "You Build It, You Run It!":
○ YES but with the right structure to support it
This is where Platform Engineering comes in!

11. The Platform Engineering
Journey
01
The Software Landscape Evolution
From Agile to DevOps
Platform Engineering: Principles, Benefits and Challenges

12. The Rise of Platforms
● Product teams shouldn’t need to be expert on everything to build and
deploy their product.
● Platform Engineering focuses on building a platform with self-service
features which empowers product teams.
● It’s a product-focused discipline.

13. Key Principles
● Self-Service and Automation
○ Provide tools to handle recurring tasks
○ Reduce manual tasks
● Product mindset
○ The platform is tailored for your need and constraints
○ A global approach:
■ User experience, documentation, continuous improvement,
support, consulting.
○ And you have a BIG advantage:
■ Your customers are like you (developers, ops, data experts …)
■ Invite them to contribute! Embrace inner-sourcing.

14. Benefits of Platform Engineering
● Increased Product Team Velocity
● Improved Reliability and Stability
● Enhanced Collaboration

15. Platform Engineering challenges
● Don't try to productise everything
● Define clear rules / APIs / Responsibilities
● Don't become a bottleneck
● Make or buy? that is the question…

16. Platform Engineering in
Action at Doctolib
02
Doctolib, an overview
PEER: Our Platform Engineering Department
From Monolith to multi-services: A Platform Perspective

17. Our Missions
We power health
professionals and
enable them to
have a better
work life.
We help people
to be healthier
and have faster
and easier
access to care.
#1 #2

18. Our Tech team
people working in the
tech/product teams
800+ Multi-product
domains
Platform
Patient
Care
Cooperation
Clinical
Product-centric
domains
Patient
Relationship
Management
Security Data & AI
Architecture Tech & Product Operations
Technical Program
Management
Financial

19. Our Stack

20. The Rails Monolith
● 2.5 million lines of code (in 10 years).
● A basic/boring architecture with a large PostgreSQL database.
● But we have some pain points:
○ 90,000+ tests, 20% end-to-end (Capybara/Selenium) leading to
challenges in test quality management (flakiness), feedback loop
duration, and cost optimisations (test selection).
○ Keep the main branch green
○ Ownership distributed across 70+ teams and complexity to manage
the common codebase.
○ No feature segregation to meet varying compliance and certification
needs.

21. Let’s move to micromulti-services
● Improve developer experience and efficiency.
● Allow us to rebuild parts of the product from scratch.
● Apply better development patterns (e.g., Domain-Driven Design).
● Adopt new technologies (like Java/Kotlin).
● Offer greater deployment flexibility.

22. Multi-Services challenges
● Maintaining a unified customer experience.
● Providing tools and automation for multiple languages/frameworks.
● Ensuring compatibility between services.
● Delivering a smooth deployment/release strategy (including feature
enablement).

23. Platform Engineering in
Action at Doctolib
02
Doctolib, an overview
PEER: Our Platform Engineering Department
From Monolith to multi-services: A Platform Perspective

24. PEER
Platform, Engineering Enablement, Reliability
Platform
Reusable
components
Scaffolding
Engineering
Enablement
Release
Management
Quality Management
Automation Platform
Developer
Experience
Reliability
Infrastructure
deployment
and
maintenance
FINOPS

25. PEER assets
● Production Platform: Primarily Kubernetes with various backends,
monitoring & observability, errors, logs management .
● CI and CD systems. All product teams are able to handle the deployment
of the monolith (by default it's done 3 times per day)
● Development Toolbox: Internal Developer Platform (Backstage),
Qualimetry platform (SonarQube), in-house test execution platform, test
selection system, ephemeral environments.
● Shared components: Design System, Feature Flag Management,
Authentication & Authorisation.

26. Platform Engineering in
Action at Doctolib
02
Doctolib, an overview
PEER: Our Platform Engineering Department
From Monolith to multi-services: A Platform Perspective

27. Cultural Changes
● Monolith: Platform teams could enrich the codebase to provide
services/features.
● Multi-services: Abstraction is different. Provide reusable
services/components for diverse projects and technologies.
● No shortcuts! We shouldn't do anymore on product teams behalf!
● Knowledge is no longer centralised. Structure and document it effectively
(service catalog, resources).
Give a man a fish, and you feed him for a day.
Teach a man to fish, and you feed him for a lifetime.

28. Platform features to update
● To support the transition to multi-services some features have to be
updated
○ Monitoring & observability must be adapted to allow traceability
across services.
○ Shared services like Feature Flag Management, Design System,
Authentication and Authorisation services must be extracted from
the monolith and reusable by any service
○ Release and deployment strategies have to be reviewed to allow all
teams to deploy their services autonomously.

29. Platform features to add
● To support the transition to multi-services some features must be added
in the platform:
○ Scaffolding to initiate projects with common patterns
○ Scorecards, maturity models, to track the evolution of the different
services
○ Contract testing (PACT) to validate the compatibility between
services.
○ Repository manager to exchange internal libraries and components.

30. Conclusion

31. Internal Platforms
● Internal platforms are not new, but they're essential now.
● Internal platforms must be managed as products.
● Your customers are your internal product teams.
○ Listen, gather feedback, collaborate, and deliver what they need
most.

32. An Internal Platform
● Reduces cognitive load on product teams, accelerating development and
delivery.
● Improves product reliability and resilience with dedicated platform
experts.
● Accelerates development and delivery through tool and knowledge
sharing.
● Reduces security, regulatory, and functional risks through governance
and standardization.
● Enables cost-effective use of (cloud) services while maintaining control
over the developer experience.

33. Platform Engineering is a discipline
● It can be implemented with Platform Teams, but it's bigger than that.
● No magic solutions, no "one size fits all."
● Apply best practices to your specific context.

34. Don’t hesitate!
Any question?
Doctolib is hiring in France, Germany, and Italy!
https://careers.doctolib.com/

35. Thank you