Top Banner
Monoliths and microservices Bozhidar Bozhanov
23

Monoliths and Microservices

Jan 12, 2017

Download

Software

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Monoliths and Microservices

Monoliths and microservicesBozhidar Bozhanov

Page 2: Monoliths and Microservices

Vanity slide• Senior software engineer @ TomTom• http://blog.bozho.net• http://techblog.bozho.net• http://twitter.com/bozhobg• some other stuff...

Page 3: Monoliths and Microservices

General architecture

Source: Microsoft

Page 4: Monoliths and Microservices

Monoliths• single deployment• single runtime• single codebase• interaciton between classes is most often

syncrhonous• most often every layer is in a separate

package

Page 5: Monoliths and Microservices

Microservices• many small modules with specific functionality• more than one codebase• every microservice is a separate deployment• every microservices has its own DB• communication with

web-services/protobuf/thrift/…• ensures module independence

Page 6: Monoliths and Microservices

Monoliths vs microservices

Source: Martin Fowler

Page 7: Monoliths and Microservices

Downsides of monoliths…?• “spaghetti”, “big ball of mud”• you need a full redeploy• programmers often violate the layer

boundaries• classes often “leak” their implementation• hard to work with multiple teams• hard to manage

Page 8: Monoliths and Microservices

Benefits of Microservices..?• modelled around the business domain• deployment automation culture• hides implementation details• decentralization• option to use multiple languages• separate deployment, separate monitoring• isolating problems

Page 9: Monoliths and Microservices

Source: Martin Fowler

Page 10: Monoliths and Microservices

Downsides of monoliths..?• “spaghetti”, “big ball of mud”

• if you write bad code, architecture doesn’t matter• you need a full redeploy

• so? It’s automated anyway• programmers often violate layers

• see. 1• classes “leak” their implementation

• see 1

Page 11: Monoliths and Microservices

Benefits of microservices..?• all of them can be achieved with a monolith• modelled around the business domain

• yes• deployment automation culture

• nothing stops automated deployments of a monolith• hides implementation details

• OOP 101

Page 12: Monoliths and Microservices

Benefits of microservices..?• separate deployment, separate мониторинг

• monitoring of classes/components/layers with tools like statsd

• isolating problems• when has a single exception broken your server?• if a whole machine dies – you have an HA cluster• graceful degradation - feature toggle in monolith

Page 13: Monoliths and Microservices

Microservices...downsides• network overhead• transaction coordination

• you don’t have transaction? Congratulations.• need for duplicating common data

• and keeping it in sync• complicated deployment pipeline• dependencies

Page 14: Monoliths and Microservices

Microservices...should we?“…don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services” Martin Fowler

Page 15: Monoliths and Microservices
Page 16: Monoliths and Microservices

“the design thinking and decomposition strategy required to create a good microservices architecture are the same as those needed to create a well structured monolith” Simon Brown

Page 17: Monoliths and Microservices

The middle way

Source: Simon Brown

Page 18: Monoliths and Microservices

How to write monoliths• package by layer (small projects)

• with sub-packages by component• package by components

• logically the same as microservices, without the cons• one or several projects with module dependencies• project jigsaw - modules

• good OOP• interfaces, encapsulation, composition, etc.

Page 19: Monoliths and Microservices

More best practices• Continuous delivery, automation• High availability• Log collection• Monitoring

Page 20: Monoliths and Microservices

Microservices use cases• multiple teams• short-lived, spawned workers• memory or CPU intensive parts

• to ease development

Page 21: Monoliths and Microservices

Но като цяло...• common sense• добри практики• качествен код• не се доверявайте на “модерното”• не се “наархитектурчвайте”

• a.k.a. KISS• загубите може да са повече от евентуалните

ползи

Page 22: Monoliths and Microservices

Sourceshttp://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.htmlhttp://www.codingthearchitecture.com/2013/07/03/aligning_software_architecture_and_code.htmlhttps://michaelfeathers.silvrback.com/microservices-until-macro-complexityhttp://techblog.bozho.net/in-defence-of-monoliths/http://martinfowler.com/bliki/MicroservicePremium.htmlhttp://martinfowler.com/articles/microservices.htmlhttp://martinfowler.com/articles/microservice-trade-offs.htmlhttp://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/

Page 23: Monoliths and Microservices

Thank you!