YOU ARE DOWNLOADING DOCUMENT

Please tick the box to continue:

Transcript
Page 1: Micro-services Battle Scars
Page 2: Micro-services Battle Scars
Page 3: Micro-services Battle Scars

nearForm ❤️ micro-services. Richard Rodger @rjrodger

4 years of Node.js 50+ projects

startups to gorillas 1 user to 1 000 000

every kind team all skill levels

Page 4: Micro-services Battle Scars

What do you think micro-services are made of?

Page 5: Micro-services Battle Scars

You run lots of little processes, on many machines.

Page 6: Micro-services Battle Scars

Your services communicate using asynchronous messages.

All services can see All messages …

and react to the ones they care about - a useful fiction!

Page 7: Micro-services Battle Scars

You use pattern-matching to react to the right messages.

Messages are just JSON documents. Patterns are just property-value pairs.

info:user, what:login

Page 8: Micro-services Battle Scars

You get real software components. Finally!

Page 9: Micro-services Battle Scars

Here’s what software components should do for you.

•re-usable •which really means: composable

•extensible •easy to add functionality

•encapsulated and loosely coupled •the implementation does not leak

•well-defined interface •but note: this does not mean strict!

Page 10: Micro-services Battle Scars

How do you write micro-services to handle this?

Page 11: Micro-services Battle Scars

You always add services, never modify. Pattern matching makes this work.

Write more micro-services when you need to specialise.

Add more specific patterns for more fine-grained functionality.

Page 12: Micro-services Battle Scars

You get service composition when you use pattern matching.

Page 13: Micro-services Battle Scars

nodezoo.com - github.com/rjrodger/nodezoo An example system big enough to be interesting.

Page 14: Micro-services Battle Scars

You can get yourself into trouble with micro-services…

💩 PILE OF POO

U+1F4A9

Page 15: Micro-services Battle Scars

You may get a rash of little web servers. This never ends well.

Page 16: Micro-services Battle Scars

Jon Postel: You should be liberal in what you accept, and strict in what you emit.

Define a schema for the properties of the Chair entity.

Make sure you cover all the business cases!

Page 17: Micro-services Battle Scars

You can never get away from some anti-patterns.

Page 18: Micro-services Battle Scars

You can use any language! What could possibly go wrong?

Page 19: Micro-services Battle Scars

You’ll discover more services than you’ll design.

Architecture. The boxes and arrows don’t work anymore.

Page 20: Micro-services Battle Scars

You use micro-services to perform actions. They don’t describe the world.

Don’t keep any state in your services. We’ve tried that already with OOP.

It doesn’t work.

Page 21: Micro-services Battle Scars

You’ll need practice. Micro-services break lots of rules.

Page 22: Micro-services Battle Scars

You can be awesome with micro-services.

🚀 ROCKET U+1F680

Page 23: Micro-services Battle Scars

You can swap databases mid-project! Or anything else. Infinite Power!

Page 24: Micro-services Battle Scars

Your system will scale.

Page 25: Micro-services Battle Scars

You can actually do continuous deployment! Micro-services are the “unit of deployment”.

Page 26: Micro-services Battle Scars

You can verify new micro-service versions work by running them beside old versions.

Page 27: Micro-services Battle Scars

You’ll need some tools to make this work.

senecajs.org nearform.com/nscale nodejs.org docker.com

Page 28: Micro-services Battle Scars

Thanks! Richard Rodger

@rjrodger


Related Documents