(0:48) Ian explains that "micro" doesn’t imply number of lines of code but "A bounded concept/business capability within your Domain" (put forth by Martin Fowler and James Lewis)
(1:20) Ian talks about breaking the domain problem down further and further for simpler testing, better fault tolerance and incremental releases.
(2:20) "If you can’t QA everything you need to be able to monitor and respond to issues rapidly."
(2:42) Scott Allen asks if Devops is a driver for Microservices rather than physical deployment or team size.
(3:00) Ian talks about the scale limits of developers and teams and how component based architectures.
Have we been here before?
(4:00) Ian talks about how Microservices is the next generation of component-based architectures after DCOM, CORBA, SOA and the importance of understanding what worked, what didn’t and why.
(4:49) Asking a component for a cup of tea vs telling something how to make tea highlighting the difference between Microservices vs RPC. RPC was very coupled to behavior which lead to fragile APIs.
Finding the "micro" sweet spot
(5:50) Jon asks how you manage the complexity of orchestrating many smaller pieces.
(6:15) Ian advises against going too small – Nanoservices – where the overhead of a service overshadows the utility value of it.
(6:30) "It’s really hard to get a feel in a new domain of where those points are that you can slice effectively" – one solution is to start exploring the domain in a traditional monolithic way and to break the parts apart at the seems to get the tradeoff right.
Tooling and support
(7:06) Jon asks what a good way to manage these services including profiling and monitoring.
(7:20) Ian recommends some tools to help:
New Relic for introspective monitoring and diagnostics.
Logstash or Splunk for log analysis and the usefulness of adding a GUID to a request that flows through messages and logs to correlate the activity.