The histories of microservices
0 likes159 views
The document discusses the history and evolution of microservices architecture. It describes how software architectures progressed from monolithic structures with tight coupling to microservices with loose coupling and independent scalability. Microservices allow for improved resilience, scalability, and the ability for teams to work independently. The document also discusses the influence of cloud computing, containerization, and other factors on enabling and popularizing the microservices approach.
The histories of microservices
- 1. The histories of Microservices @Steve_Upton
- 2. The standard Microservices creation story
- 8. Hard to scale RDBMS was also a SPOF
- 9. Hard to scale RDBMS was also a SPOF and bottleneck
- 10. Hard to scale RDBMS was also a SPOF and bottleneck Vertical scaling easy, but limited
- 11. Hard to scale RDBMS was also a SPOF and bottleneck Vertical scaling easy, but limited Horizontal scaling helpful, but slow and expensive
- 12. Hard to scale RDBMS was also a SPOF and bottleneck Vertical scaling easy, but limited Horizontal scaling helpful, but slow and expensive Scaling the whole monolith was wasteful
- 13. “...the average server operates at no more than 12 to 18 percent of its capacity” Natural Resources Defense Council
- 14. Tightly coupled, slow to change
- 15. Sharing knowledge of components Difficult to upgrade without affecting other services Tightly coupled, slow to change
- 16. Sharing knowledge of components Difficult to upgrade without affecting other services Sharing libraries, platform, OS etc. Teams have little choice in setup Tightly coupled, slow to change
- 19. ?
- 20. Service Moving to the cloud HTTP Data Access Component Component Component ... HTTP
- 22. Resilience to failure Able to isolate failures
- 23. Resilience to failure Able to isolate failures
- 24. Resilience to failure Able to isolate failures Gracefully adapt to failures
- 25. Resilience to failure Able to isolate failures Gracefully adapt to failures Quick recovery
- 26. Resilience to failure Able to isolate failures Gracefully adapt to failures Quick recovery Easy (auto) scaling
- 27. Loosely coupled, easy to change Share contracts, not internals Little to no knowledge of other services needed
- 28. Loosely coupled, easy to change Share contracts, not internals Little to no knowledge of other services needed Teams free to choose OS, language, libraries etc. Free to upgrade and experiment independently
- 29. “In short, 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.” James Lewis and Martin Fowler, ThoughtWorks
- 30. “Loosely coupled service oriented architecture with bounded contexts” Adrian Cockcroft, Architect @ Netflix
- 35. Atlas
- 38. The other story
- 39. The other story credit to Fred George
- 40. Project delivery cycles 1980 1990 2000 2010 Projectduration(log) 1 week 1 month 1 year 5 years
- 41. Project delivery cycles 1980 1990 2000 2010 Projectduration(log) 1 week 1 month 1 year 5 years Waterfall
- 42. Project delivery cycles 1980 1990 2000 2010 Projectduration(log) 1 week 1 month 1 year 5 years Waterfall Waterfall + OO
- 43. Project delivery cycles 1980 1990 2000 2010 Projectduration(log) 1 week 1 month 1 year 5 years Waterfall Waterfall + OO Agile
- 44. Project delivery cycles 1980 1990 2000 2010 Projectduration(log) 1 week 1 month 1 year 5 years Waterfall Waterfall + OO Agile Agile + Lean
- 45. Hardware lead times 1990 2000 2010 2015 Orderleadtime(log(ish)) < 1 sec 1 hour 1 week 6 months 5 secs
- 46. Hardware lead times 1990 2000 2010 2015 Orderleadtime(log(ish)) < 1 sec 1 hour 1 week 6 months Data center 5 secs
- 47. Hardware lead times 1990 2000 2010 2015 Orderleadtime(log(ish)) < 1 sec 1 hour 1 week 6 months Data center Virtual machines 5 secs
- 48. Hardware lead times 1990 2000 2010 2015 Orderleadtime(log(ish)) < 1 sec 1 hour 1 week 6 months Data center Virtual machines Commercial cloud (AWS) 5 secs PaaS
- 49. Hardware lead times 1990 2000 2010 2015 Orderleadtime(log(ish)) < 1 sec 1 hour 1 week 6 months Data center Virtual machines Commercial cloud (AWS) Docker FaaS 5 secs PaaS
- 50. Project size 1990 2000 2010 2015 Projectsize(linesofcode) 1,000 10,000 100,000 1,000,000
- 51. Project size 1990 2000 2010 2015 Projectsize(linesofcode) 1,000 10,000 100,000 1,000,000 Java
- 52. Project size 1990 2000 2010 2015 Projectsize(linesofcode) 1,000 10,000 100,000 1,000,000 Java Ruby
- 53. Project size 1990 2000 2010 2015 Projectsize(linesofcode) 1,000 10,000 100,000 1,000,000 Java Ruby Python
- 54. Project size 1990 2000 2010 2015 Projectsize(linesofcode) 1,000 10,000 100,000 1,000,000 Java Ruby Python Node.js
- 55. Onboarding the new dev... credit: https://twitter.com/moonpolysoft/status/781868129269919744
- 56. Story time
- 58. Marx on Microservices Economic and Philosophic Manuscripts of 1844
- 59. Marx on Microservices Economic and Philosophic Manuscripts of 1844 Gattungswesen (species-being) Workers feeling a connection to their work
- 60. Marx on Microservices Economic and Philosophic Manuscripts of 1844 Gattungswesen (species-being) Workers feeling a connection to their work Entfremdung (alienation) Workers feel estranged from their work
- 62. “Any piece of software reflects the organizational structure that produced it” Conway's Law
- 64. What sort of organisation do you want to work in?
- 65. The other, other story
- 66. SOA
- 68. Service Oriented Architecture Boundaries are explicit
- 69. Service Oriented Architecture Boundaries are explicit Services are autonomous
- 70. Service Oriented Architecture Boundaries are explicit Services are autonomous Services share schema and contract, not class
- 71. Service Oriented Architecture Boundaries are explicit Services are autonomous Services share schema and contract, not class Service compatibility is based on policy
- 73. IBM SOA Foundation Reference Architecture
- 74. IBM SOA Foundation Reference Architecture logical model
- 75. IBM SOA Foundation Reference Architecture solution
- 76. Oracle SOA Foundation Reference Architecture (Product Mapping)
- 77. Oracle SOA Foundation Reference Architecture
- 78. “The latest shiny new technology will not make things better… If you want spectacular gains, then you need to make a spectacular commitment to change.” Anne Thomas Manes, SOA is Dead; Long Live Services
- 79. “... and that’s where we need to concentrate from this point forward: Services” Anne Thomas Manes, SOA is Dead; Long Live Services
- 80. “Microservices are hard. Some things you get for free, but you have to work for the good stuff. If you won’t put in the work, you shouldn’t be doing Microservices. (You should be doing that stuff anyway!)” Steve Upton
- 81. “Microservices are hard. Some things you get for free, but you have to work for the good stuff. If you won’t put in the work, you shouldn’t be doing Microservices. (You should be doing that stuff anyway!)” Steve Upton
- 82. “Microservices are hard. Some things you get for free, but you have to work for the good stuff. If you won’t put in the work, you shouldn’t be doing Microservices. (You should be doing that stuff anyway!)” Steve Upton
- 83. “Microservices are hard. Some things you get for free, but you have to work for the good stuff. If you won’t put in the work, you shouldn’t be doing Microservices. (You should be doing that stuff anyway!)” Steve Upton
- 84. “Microservices are hard. Some things you get for free, but you have to work for the good stuff. If you won’t put in the work, you shouldn’t be doing Microservices. (You should be doing that stuff anyway!)” Steve Upton
- 85. “Microservices are hard. Some things you get for free, but you have to work for the good stuff. If you won’t put in the work, you shouldn’t be doing Microservices. (You should be doing that stuff anyway!)” Steve Upton
- 87. Essential reading https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed https://plus.google.com/+RipRowan/posts/eVeouesvaVX https://engineering.linkedin.com/distributed-systems/log-what-every-software-engi neer-should-know-about-real-time-datas-unifying http://martinfowler.com/articles/microservices.html http://jonasboner.com/bla-bla-microservices-bla-bla/ (honestly, just Google “netflix microservices”, there are loads of good videos)