Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
The 7 Deadly Sins of Microservices
Search
Tareq Abedrabbo
November 27, 2014
Technology
7
1.2k
The 7 Deadly Sins of Microservices
MuCon 2014
Tareq Abedrabbo
November 27, 2014
Tweet
Share
More Decks by Tareq Abedrabbo
See All by Tareq Abedrabbo
Not a SO(A) Trivial Question!
tareqabedrabbo
0
49
Designing APIs for Data Driven Systems
tareqabedrabbo
0
52
Things I wish I'd known before I started with Microservices
tareqabedrabbo
0
650
Building a Scalable Event Service with Cassandra: Design to Code
tareqabedrabbo
1
450
The Ubiquitous Graph
tareqabedrabbo
0
190
The 7 Deadly Sins of Microservices
tareqabedrabbo
0
590
Building a Scalable Event Service with Cassandra: Design to Code
tareqabedrabbo
0
60
Time Series and Events: Storage and Querying Strategies with Cassandra
tareqabedrabbo
0
270
Building a Scalable Event Service with Cassandra
tareqabedrabbo
1
120
Other Decks in Technology
See All in Technology
Ask! NIKKEIの運用基盤と改善に向けた取り組み / NIKKEI TECH TALK #30
kaitomajima
1
420
Fintech SREの挑戦 PCI DSS対応をスマートにこなすインフラ戦略/Fintech SRE’s Challenge: Smart Infrastructure Strategies for PCI DSS Compliance
maaaato
0
430
AIをプロダクトに実装するならAPIで分離しよう 〜タクシーアプリ『GO』のアーキテクチャ実例紹介〜
74th
3
150
AIエージェントについてまとめてみた
pharma_x_tech
20
14k
トラシューアニマルになろう ~開発者だからこそできる、安定したサービス作りの秘訣~
jacopen
2
640
ビジネスと現場活動をつなぐソフトウェアエンジニアリング~とあるスタートアッププロダクトの成長記録より~
mizunori
0
170
Bounded Context: Problem or Solution?
ewolff
1
210
5分で紹介する生成AIエージェントとAmazon Bedrock Agents / 5-minutes introduction to generative AI agents and Amazon Bedrock Agents
hideakiaoyagi
0
200
室長と気ままに学ぶマイクロソフトのビジネスアプリケーションとビジネスプロセス
ryoheig0405
0
180
テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践 / Test Architecture Design in Practice
ropqa
3
530
第13回 Data-Centric AI勉強会, 画像認識におけるData-centric AI
ksaito_osx
0
340
DeepSeek on AWS
hariby
1
210
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
34
3.1k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.4k
How STYLIGHT went responsive
nonsquared
98
5.3k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Designing for Performance
lara
604
68k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Automating Front-end Workflow
addyosmani
1367
200k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
A better future with KSS
kneath
238
17k
Transcript
The 7 Deadly Sins of Microservices Tareq Abedrabbo - MuCon
2014
About me CTO at OpenCredo Author, developer, open-source committer, with
a long term interest in service-based architecture
Disclaimer Any resemblance to existing projects, overrunning or axed, is
purely intentional!
What are microservices?
Microservices Design Principles Tools Decoupling Separation of concerns Encapsulation Engineering
Practices Spring Boot RabbitMQ Hystrix Automation Scalability Fault-tolerance Continuous Delivery Testing Dropwizard Config Management
Why microservices anti-patterns?
1. The Enterprise-OSGI-Application-Service-Bus Building the wrong thing
There is no unique way to implement microservices
Don't build what you don't need - think about your
goals and your non-goals
Questions to ask: - What languages do I need to
support? - What libraries? - How dynamic and flexible does my implementation need to be?
Communicate goals and non-goals. Keep it simple.
2. Porcine Cosmetics Failing to adopt a contract-first design approach
Why do we need service contracts?
Abstraction
Encapsulation
Composition
Always start by designing the contract of your service (CDD,
it is like TDD but for microservices!)
Seriously, we've known this for 10 years!
3. Message in a Bottle Assuming the wrong communication protocol
Typically, microservices use http or lightweight messaging to communicate. Messages
can be binary or human-readable
Don't enforce one particular communication pattern before understanding what you
really need
Do I need: - Simple request/response paradigm? - Message persistence?
- Reliability? - Asynchronous notification?
Distinguish between services: external vs internal core vs supporting
4. The Single Domain of Failure Introducing a shared domain
model
Designing a shared domain model is common in a monolithic
architecture (it is even a best practice!)
Things domain models are used for: - drive business logic
- map business entities to the database - manage input & output
The shared domain model fallacy: we are in full control
of the context and the boundaries of the application
A shared domain model breaks encapsulation and introduces coupling between
services
Shared dependency on volatile binary artefacts makes deployments really hard
Define the domain in terms of service interaction, not service
implementation
Resource-oriented design
5. The Distributed Monolith Defining inappropriate service boundaries
A distributed monolith is an application that externalises its internal
services indiscriminately
Internal application components don't always make good microservices
Internal application services: - often have the wrong granularity -
can have interdependencies - or a dependency on a shared domain
Microservices are not a remoting abstraction
Design services that have business meaning and clear boundaries
6. The Horseless Cart Neglecting Macro System Concerns
Microservices: micro vs macro (macro is often missed)
Macro things to think about: - updating, deploying and scaling
services independently - functional, performance and regression testing - system-wide behaviour, including failure scenarios
Design for a distributed system (runtime introspection, fault-tolerance, latency, failure,
etc...)
Introduce continuous delivery and automated testing form the very start
7. The Sausage Factory Disregarding the Human Factor
In microservices world, developers need to have good understanding of:
- Messaging - Scalability, fault-tolerance and resilience - Integration and remoting And potentially learn a few new technologies and tools
Monolithic architecture is a rabbit hole!
Microservices do not make up for the gaps in your
developers' skills
Invest in your developers
–Melvin Conway “organisations which design systems […] are constrained to
produce designs which are copies of the communication structures of these organisations.”
Corollary organisations that operate in silos cannot benefit from a
microservices architecture
Microservices do not fix broken organisations
Collaboration on a microservices project between: - devs and ops
- techies and business - and across teams
The essence of microservices is collaboration
In conclusion
Microservices: it feels a little bit like quantum mechanics!
Hopefully, we can now begin to have pragmatic answers to
questions such as: - How do I design a (micro)service? - How big or small should a service be? - Should a microservices be reusable?
Links Microservice anti-patterns: http://bit.ly/ microservices-antipatterns OpenCredo: http://www.opencredo.com/blog Twitter: @tareq_abedrabbo Personal
blog: http://www.terminalstate.net Thank you! Any questions?
Credits • https://unsplash.com/ • The horseless cart: https://www.flickr.com/photos/ ellesmerefnc/4249596803/ •
Message in a bottle: https://www.flickr.com/photos/ rpenalozan/5128413528