There is lot of focus around building microservices based systems and lot has been discussed around what is needed for microservice architecture. How to draw the service boundaries is one of the key complexity in this type of architecture. Building separate service is not a simple technical choice. Decision should be made based on functional boundaries, organisational structure and business direction. This will help in getting the best benefits of this type of architecture and also justify the investment made for it.
7. MILAN 20/21.11.2015 - Thiyagu Palanisamy
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3610582
http://tamai-lab.ws.hosei.ac.jp/pub/icsm92.pdf
8. MILAN 20/21.11.2015 - Thiyagu Palanisamy
Accelerated growth of
technology is disrupting
businesses
https://en.wikipedia.org/wiki/The_Singularity_Is_Near
9. MILAN 20/21.11.2015 - Thiyagu Palanisamy
should be cheap to replace
gives flexibility to experiment
allows you to go as fast as possible
needs on systems
12. MILAN 20/21.11.2015 - Thiyagu Palanisamy
organizations which design systems ... are constrained to produce designs which
are copies of the communication structures of these organizations
Conway's law 1967
23. MILAN 20/21.11.2015 - Thiyagu Palanisamy
This is the Unix philosophy - Write programs that do one thing and do it well.
Write programs to work together. Write programs to handle text streams,
because that is a universal interface
Doug McIlroy
ps aux | grep conky | grep -v grep | awk '{print $2}' | xargs kill
24. MILAN 20/21.11.2015 - Thiyagu Palanisamy
• Modularity - simple parts connected by well defined interfaces
• Clarity - most important communication is to the developer
• Composition - design programs to be connected to other programs
• Separation - separate the mechanisms of the programs from the policies
• Simplicity - small, straightforward cooperating pieces
• Parsimony - avoid writing big programs
• Transparency - design for visibility and discoverability
• Robustness - robustness is the child of transparency and simplicity
• Representation - easier to understand complex data than complex logic
• Least Surprise - build intuitive products that are easy to use
• Silence - do not print unnecessary output
• Repair - fail in a manner that is easy to localize and diagnose
• Economy - value developer time over machine time
• Generation - write abstract high-level programs that generate code
• Optimization - prototype software before polishing it
• Diversity - programs to be flexible and open
• Extensibility - design for the future by making their protocols extensible
Eric Raymond’s 17 Unix Rules