From Monolith to Microservices

Slide 1

Slide 1 text

From Monolith to Microservices September 2015 01 Johann Romefort

Slide 2

Slide 2 text

About Johann • 15+ years in IT • 7 years in San Francisco doing Startups • in Germany for 1 year • Tech Evangelist @Stylight • Overuse of Meme pictures 2

Slide 3

Slide 3 text

Before I got to Stylight..

Slide 4

Slide 4 text

I built Monoliths for a living 4

Slide 5

Slide 5 text

Sounds cool! What is Monolith and how do I build one? 5 • It’s when you whole system is one big application that can fit on one server! • They are much easier to build than distributed applications! • You generally build one without even thinking about it • By the time you realize that you have one you’re in trouble.

Slide 6

Slide 6 text

Are monoliths thaaaaat bad? 6 • Not if you just want to do a throw away project or a prototype. • Only if you promise that you won’t keep adding to the monolith and eventually put it in production • For simple apps they are probably best • and remember: Distributed apps are hard

Slide 7

Slide 7 text

On being a CTO for a hot startup in San Francisco…

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

My ﬁrst year as a CTO 9 • Put a monolithic prototype in production • Almost no monitoring • No analytics • Almost no automated testing • Reminder: It will almost never stay a prototype, think about it.

Slide 10

Slide 10 text

Slide 11

Slide 11 text

I crashed Techcrunch

Slide 12

Slide 12 text

Codebase after a year • Fails from everywhere • Fixing one part lead to more bugs • Developers scared to touch it 12

Slide 13

Slide 13 text

Deploys become HELL • Most likely they mean  being down for a few hours • A lot of time a rollback is necessary • it feels like russian roulette 13

Slide 14

Slide 14 text

Hire a QA Manager • Create a Staging env • No deploy unless it’s tested • Feared by the devs, hated by the CEO 14

Slide 15

Slide 15 text

Add an “Ops guy” • Create the build • Prepare the deploy • Locks everything so dev  can’t play around with prod • Wake up when server is on fire • feared by the dev as well. 15

Slide 16

Slide 16 text

Impact on dev • Frustrated of slow release process • Chain of command too long • Feeling powerless • Low trust & autonomy 16

Slide 17

Slide 17 text

Impact on product • Frustration of not executing fast enough • Frustration of having to ask for everything (like metrics) • No autonomy • Don’t understand the engineers 17

Slide 18

Slide 18 text

Big Bang Refactoring! • Rewriting everything from scratch • Developers love this idea. • Do the right thing: Don’t do it • Unless you can • Unless you really have to - it happened to me :) 18

Slide 19

Slide 19 text

What you should do instead 19 • Break down application into smaller autonomous units • Break down teams into smaller autonomous units • Automating what can be automated • Continuous Integration and Continuous Deployment

Slide 20

Slide 20 text

Stylight - Make Style Happen

Slide 21

Slide 21 text

We help people ﬁnd a style they like 21 • Search engine for style: we aggregate products from a lot of stores • Digital magazine for inspiration • in 15 countries • 200+ employees • 3 offices • 6000 brands • 360 partners shops

Slide 22

Slide 22 text

Historical Architecture @ Stylight 22 Backend Frontend products transfer SEO QA Machine Learning Feed import API Webapp Ranking bizdev One big app with one big database One big app with one big database

Slide 23

Slide 23 text

Cross functional teams

Slide 24

Slide 24 text

What is a cross- functional team? • Autonomous team • Diﬀerent set of skills but working together • Own metrics and KPIs • Own software / DB • But new challenges… 24

Slide 25

Slide 25 text

Stylight aims to become a Teal organization 25 • Each unit is autonomous • a unit is generally 5 to 10 people (so called- pizza team) • it mimics a living organism

Slide 26

Slide 26 text

30 seconds meditation on Conway’s law: 26 organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations — M. Conway[2]

Slide 27

Slide 27 text

Moving to a service-based architecture 27 • Monoliths don’t work well in cross-functional teams • Monoliths don’t work well for complex system either • We extracted main components from the Core, mostly defining their boundaries by teams

Slide 28

Slide 28 text

28 Architecture evolution @ Stylight Backend DB Frontend DB products transfer SEO QA Machine Learning Feed import API Webapp Ranking bizdev

Slide 29

Slide 29 text

Moving to a Microservices architecture

Slide 30

Slide 30 text

Our architecture is evolving toward full micro services, mimicking our org 30 30 SEO QA Machine Learning Feed import API Webapp Ranking bizdev

Slide 31

Slide 31 text

Microservices - an example 31

Slide 32

Slide 32 text

Monolith vs Microservices - Storage 32

Slide 33

Slide 33 text

Monolith vs Microservices - servers 33

Slide 34

Slide 34 text

Why is it hard? 34 • Subject to the the 8 fallacies of distributed computing ————————-> • Full devops model: Good tooling needed • Needs to be designed for resiliency • Harder to test Fallacies of distributed computing • The network is reliable. • Latency is zero. • Bandwidth is infinite. • The network is secure. • Topology doesn't change. • There is one administrator. • Transport cost is zero. • The network is homogeneous.

Slide 35

Slide 35 text

Why is it worth it?

Slide 36

Slide 36 text

From an engineering perspective 36 • Easier to do CI/CD (we deploy 10 times / day) • resilient to failure (one service down does not bring the whole system down) • Easier to refactor • Easier to understand - you don’t need to know  the whole system to get things done.

Slide 37

Slide 37 text

Impact on dev • Autonomy • Not afraid to try new things • Confident in codebase • Bugs don’t have to linger around until there’s a release 37 Impact on Product and Bizdev • Iterate faster on features • Can make, bake and break hypothesis faster • Product gets improved incrementally everyday

Slide 38

Slide 38 text

Where we’re heading…

Slide 39

Slide 39 text

Pets vs Cattles, or Scaling up vs Scaling out

Slide 40

Slide 40 text

Pets • Have cute names • Tuned and groomed • Take them to the vet when they are sick • when it comes to server: Scale up 40

Slide 41

Slide 41 text

Cattle • Cattle is given a unique random id • They are identical to others • Got ill? Kill it and get another one. • when it comes to server: Scale out 41

Slide 42

Slide 42 text

From Stateless to Immutability • Immutable systems are easier to reason about • Immutable data • Immutable infrastructure 42

Slide 43

Slide 43 text

Messaging Queue as a database 43 • Each event in the system is writing into a time organised immutable log • Let you embrace immutable data where your database is transformed into materialised views • Let you replay your log in case of failure or if you need a diﬀerent view on your data

Slide 44

Slide 44 text

Docker 44 • Container technology • Eliminate discrepancies between dev, staging, prod • helps to create immutable units easy to deploy and scale • Fits devops paradigm

Slide 45

Slide 45 text

CoreOS • Immutable File System • Auto-update • Run on Bare Metal or VMs • Minimal footprint OS • Tailored for container deployments 45

Slide 46

Slide 46 text

www.stylight.com follow me : @romefort follow Stylight Tech : @codetailors