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.
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
monolithic prototype in production • Almost no monitoring • No analytics • Almost no automated testing • Reminder: It will almost never stay a prototype, think about it.
into smaller autonomous units • Break down teams into smaller autonomous units • Automating what can be automated • Continuous Integration and Continuous Deployment
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
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
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.
(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.
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
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 different view on your data