Disposability has been a long time coming – I remember the aha when I first heard how Google dealt with hardware failures – by simply throwing out the offending boxes every once in a while, with no need to do anything immediate. At Google the software architecture meant that hardware became disposable. Today that architectural idea(l) is becoming a core design principle for Cloud Native software – 12 Factor Apps. Everything should be disposable. Except of course the data… Apps are like fish, but data is like wine. Stateless apps still require a persistence layer.

1. 10.20.2005
On Composability, Adaptability, and Disposability:
Microservices, Cattle and Pets
Dreamforce 2015, SF

2. 2

3. 3
The End of Feature vs Product

4. 4
The Rise of Micro-services
“The microservice architectural style is an approach to developing a single application
as a suite of small services, each running in its own process and communicating with
lightweight mechanisms, often an HTTP resource API. These services are built around
business capabilities and independently deployable by fully automated deployment
machinery. There is a bare minimum of centralized management of these services,
which may be written in different programming languages and use different data
storage technologies.”
Martin Fowler, Thoughtworks, March 2014

5. 5

6. 6
Cattle vs Pets

7. 7
Microservices in Nature

8. 8
What about the Prize Bull?

9. 9
There are Many Copies

10. 10
Apps Are Like Fish, Data is Like Wine

11. 11
Many Tools – the Rise of Polyglot

12. 12
Language Rankings

13. 13
1990s: farming

14. 14
2002+: foraging

15. 15
Search-First Development

16. 16
Borrow from Web Companies

17. 17
µServices as a Cultural Change
Amazon CEO Jeff Bezos mandate, from Steve Yegge post on Google+
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no
direct reads of another team’s data store, no shared-memory model. The only communication
allowed is via service interface calls over the network.
4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols —
doesn’t matter. Bezos doesn’t care.
5) All service interfaces, without exception, must be designed from the ground up to be
externalizable. That is to say, the team must plan and design to be able to expose the interface
to developers in the outside world. No exceptions.
6) Anyone who doesn’t do this will be fired.

18. 18
Conways Law
"Any organization that designs a system (defined more broadly here than just
information systems) will inevitably produce a design whose structure is a copy of the
organization's communication structure."

19. 19
µServices Issues
The Perils of Success -
unexpected, dramatic load spikes. Noisy
Neighbors
Retrofitting security for services
not born on the web
Born on the Web development tools and methods
taking advantage of agile, DevOps, NoSQL
Organisational Change
Distributed Systems are hard – CAP

20. 20

21. 21

22. 22
Then Martin Said
“don't even consider microservices unless you have a system that's too
complex to manage as a monolith.” Martin Fowler, Thoughtworks

23. 23
Wrap Up
The World is Changing Really Fast – development and deployment needs to change with it.
SOA still has a huge role to play – the Amazon lesson.
Conways Law Applies
Messaging-based integration styles have won.
Shift testing left
Develop all services as if they will be exposed to the cloud
same as you should develop all code so it could be open sourced
Focus on drawbridges not moats
Microservices as a forcing function for better security
SecOps is now a thing
SOA as a style to manage internal and External access to resources

24. 10.20.2005
Bottlenecks