Microservices - it's déjà vu all over again
•Download as PPTX, PDF•
5 likes•3,727 views
The software industry keeps relearning the same things over and over - now that's microservices
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to Microservices - it's déjà vu all over again
Similar to Microservices - it's déjà vu all over again (20)
More from Arnon Rotem-Gal-Oz
More from Arnon Rotem-Gal-Oz (20)
Recently uploaded
Recently uploaded (20)
Microservices - it's déjà vu all over again
- 1. Microservices it’s déjà vu all over again Arnon Rotem-Gal-Oz
- 3. 2005
- 4. Two boats are traveling towards each other…
- 5. SOA Service describes End Point Exposes Messages Sends/Receives Contracts Binds to Service Consumer implements Policy governed by Sends/Receives Adheres to Component Relation Key Understands Serves
- 8. Keep data and state private
- 9. Two boats are traveling towards each other…
- 10. Physical Protector Protector Commands (navigate to waypoint, Turn on floodlight etc) Status (radar data, subsystem statuses etc.)
- 11. UI Physical Protector Radars & other sensors Protector Common Operating Picture Messagebus Sensors Sensor update Sensor update Updated COP Updated COP
- 12. UI Physical Protector Radars & other sensors Protector Common Operating Picture Messagebus Sensors Image : http://blog.vitria.com/topic/common-operating-picture
- 16. UI Physical Protector Protector Common Operating Picture Messagebus Navigation Alerts Monitor Route
- 17. UI Physical Protector Protector Common Operating Picture Messagebus Navigation Alerts Navigate to Route Navigate to Waypoint1..2..3..
- 18. UI Physical Protector Protector Common Operating Picture Messagebus Navigation Alerts Monitor Route Not the best way
- 19. UI Physical Protector Protector Common Operating Picture Messagebus Navigation Alerts Navigate to Route Navigate to Waypoint1..2..3.. Navigating Monitor Navigating Should have been
- 20. UI Physical Protector Radars & other sensors Protector Common Operating Picture Messagebus Sensors Sensor update Sensor update Updated COP Updated COPNavigation Alerts Updated COP
- 21. UI Physical Protector Protector Common Operating Picture Messagebus Navigation Alerts Interception problem Interception problem Alert Alert
- 26. Private data Leads to islands of information
- 27. Subscribed/ pulled data Pull data Data backend Endpoint Out Load Report Ingest Clean Join Transform Transpose Produce reports Report Endpoint Request Raw data ODS/DM SQL endpoint SQL endpoint Landing area Service Aggregated Reporting
- 28. 2005
- 30. So …. What did change in 10+ years?
- 34. "A first sign of the beginning of understanding is the wish to die.” Franz Kafka
- 35. However age old risks are still relevant
- 36. Nanoservices
- 40. הַ״מ-ָהיָה ֶּׁש,ֶּׁהי ְהִּי ֶּׁש הּוא, הַּומ-ה ֲָשעַנ ֶּׁש,ה ֶָּׁשעֵּי ֶּׁש הּוא; ין ֵּאְוָלכ-שָדָח,שֶּׁמ ָשַה תַח ַת.״ ט פסוק א פרק קהלת "What has been will be again, what has been done will be done again; there is nothing new under the sun." Ecclesiastes 1:9
Editor's Notes
- Software architecture is the collection of the fundamental decisions about a software product/solution designed to meet the project's quality attributes (i.e. requirements). The architecture includes the main components, their main attributes, and their collaboration (i.e. interactions and behavior) to meet the quality attributes. Architecture can and usually should be expressed in several levels of abstraction (depending on the project's size). If an architecture is to be intentional (rather than accidental), it should be communicated. Architecture is communicated from multiple viewpoints to cater the needs of the different stakeholders. Architectural decisions are global tied to quality attributes Designs decisions are local –tied to functionality
- ”The system being produced will tend to have a structure the mirrors the structure of the group that is producing it
- (Events vs. Commands) Immutable data – things that already occurred
- Hector Garcia-Molina and Kenneth Salem defined the term Saga back in 1987 as a way to solve the problem of long lived database transactions. Hector and Kenneth described a Saga as a sequence of related small transactions. In a Saga the coordinator (database in their case) makes sure that all of the involved transactions are successfully completed. Otherwise, if the transactions fails the coordinator runs compensating transactions to amend the partial execution. What made sense for databases makes even more sense for service interactions in SOA. We can break a long service interaction into individual actions or activities and compensations (in case of faults and errors
- ODS – Operational Data Store
- The Erlang view of the world, as Joe Armstrong, co-inventor of Erlang summarized in his PhD thesis:[11] Everything is a process. Processes are strongly isolated. Process creation and destruction is a lightweight operation. Message passing is the only way for processes to interact. Processes have unique names. If you know the name of a process you can send it a message. Processes share no resources. Error handling is non-local. Processes do what they are supposed to do or fail.
- Architecture transcends technology but technology is meaningful Docker
- But also Kafka
- Pub/sub Vs log processing
- Actually they are not isolated and hide
- Netflix conductor AWS Step Various API gateways