Explore your Microservices Architecture with Graph Theory & Network Science • Nicki Watt • GOTO 2019

This presentation was recorded at GOTO Berlin 2019. #GOTOcon #GOTOber
gotober.com
Nicki Watt - CTO of OpenCredo, Leading Delivery of Large-scale, Cloud Native Projects
ORIGINAL TALK TITLE
Using Graph Theory and Network Science to Explore your Microservices Architecture
ABSTRACT
So your microservice system has been up and running for a while. You know you’ve diligently employed every ounce of your experience and knowledge over time to design a sensible application architecture, with hopefully sensible boundaries.
But time is now throwing new questions your way:
Are my boundaries still sensible?
Have any anti-patterns crept in, have I inadvertently created the dreaded distributed monolith?
This talk explores how network science and graph theory techniques can be applied to help gain insight into, and explore questions about your microservices architecture [...]
Download slides and read the full abstract here:
gotober.com/2019/sessions/112...
RECOMMENDED BOOKS
Sam Newman • Monolith to Microservices • amzn.to/2Nml96E
Sam Newman • Building Microservices • amzn.to/3dMPbOs
Ronnie Mitra & Irakli Nadareishvili • Microservices: Up and Running• amzn.to/3c4HmmL Mitra, Nadareishvili, McLarty & Amundsen • Microservice Architecture • amzn.to/3fVNAb0
Chris Richardson • Microservices Patterns • amzn.to/2SOnQ7h
Adam Bellemare • Building Event-Driven Microservices • amzn.to/3yoa7TZ
Dave Farley • Continuous Delivery Pipelines • amzn.to/3hjiE51
/ gotober
/ goto-
/ gotoconferences
#Microservices #SoftwareArchitecture #MicroservicesArchitecture #GraphTheory #NetworkScience
Looking for a unique learning experience?
Attend the next GOTO Conference near you! Get your ticket at gotocon.com
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ua-cam.com/users/GotoConf...

[@saeidghafouri8501]

Is there any dataset available for microservice graphs like the one presented in the talk?

[@kapilshekhar]

Using Graph Theory to do architecture analysis is the same mindset that uses lines of code to determine size of microservice !

[@l_combo]

great talk, would love to see this on a grander scale with an existing application portfolio including monliths however getting reliable interface / interchange data isn't easy when there is a proliferation of technologies and approaches e.g. file transfer / DB links / SOAP / REST / Message / Event / RPC etc.

[@kingscrusher]

I have unease about the microservices presented for Graph analysis - why didn't they just be designed as Asynchronous from the outset using things like Kafka - not really sure about this one. Why would you need in retrospect to model your system to try and retrofit it to become more asynchronous - why not design it from the outset with an event bus and be as asynchronous as possible which many other GOTO videos gave emphasised. Asynchronous is surely as close as we have to a sliver bullet for scalability and teams being able to work independently on their microservices. Cheers, K

[@AlisperNym]

I think the point was starting from an existing legacy system and trying to improve performance. The technique used would help determine where to make the most impact based on data. Yes, it would be nice if the system was originally designed to be perfect, but if (when) it wasn't, having data to help determine where to make changes would be a plus. Also, a focus of the talk seemed to be around tightly coupling services together where it was not necessary. That issue isn't about async services; it's about proper boundaries.

[@kingscrusher]

@@AlisperNym Well many GOTO conference videos have advocated being strong in Domain Driven Design when trying to move monoliths to microservices to try and get the best kind of decoupling and follow minimal coupling and maximum cohesion principles highlighted in IBM research as far back as the 1960s. Also many videos have now highlighted the use of the "Strangler" method along with intelligent load balancing if you want to refactoring of an existing system. To do the Strangler method, again it seems very important to be fundamentally aware of Domain Driven design. Clearing out messes after the fact just seems intuitively the wrong way to do things. But even in the clearing up and resolution process it would seem that an awareness of Domain Driven design and Strangler to be vital in refactoring distributed "Balls of Mud". The other point is that no emphasis was placed on an Event Bus strategy which seems the only way really for each microservice to have their own separate Data stores which is an important aspect of the decoupling process. In Chess terms btw Stockfish which can calculate billions of positions a second compared to a more intuitive Neural Network is currently losing a major chess match. Calculation is good - but so is Intuition. For me Intuition and understanding trumps technical analysis data and tries to tackle things in a more root cause manner rather than just playing wth data. Cheers, K