Dreamforce 2015 microservices
Download as PPT, PDF3 likes1,146 views
The document discusses the microservice architectural style, emphasizing its approach to developing applications as suites of small, independently deployable services. It highlights Jeff Bezos' mandates for teams to communicate solely through service interfaces and addresses challenges such as unexpected load spikes and security issues. The conclusion stresses the need for agility in development while acknowledging the ongoing relevance of service-oriented architecture (SOA).
Dreamforce 2015 microservices
- 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
- 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
- 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
Editor's Notes
- #12: Which of course encourages more forking and diversity, the new way innovation is done