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

[@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 !

[@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

[@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.