Comments by "Michael Stover" (@michaelrstover) on "Getting Started With Microservices" video.

  1.  @ContinuousDelivery  I guess I always thought of services as being this sort of independently deployable. The main issues I have with the current trendyness of "micro" services is the "micro" part. As far as I can tell, people's impression of the "right" size of these things is way way too small. And, microservices being just inherently more difficult to work with, people are splitting things up into far too many, far too small chunks that are then an extremely complicated ecosystem to work with and reason about. When I read or hear about the "modular monolith" idea, that makes far more sense to me, as it tries to bring the good parts of modularity and independence of deployability, but also keep some sanity about the number of moving pieces. I don't know if you have thoughts about "modular monolith" ideas, but if you do, I would be extremely interested to hear them. Maybe you could make a video about this issue of granularity in these services. You've said in the past that the right size is what you can rewrite in about a week, and that seems much too small to me. I had myself thought the right size would be what a normal sized development team could be expected to handle and maintain, which would be a lot larger than what they could completely rewrite in one week.
    5
  2. A system full of translators essentially defines an implicit grand model, since we have to know to translate A -> B, as opposed to Whatever -> B. Someone has to define all the translation mappings, and agreements have to be reached about it between teams. There's no getting around that.
    3
  3. "Independently deployable". Ok, little thought experiment, let's say me and my independently deployable microservice decide NOT to deploy. How's that going to work? Oh, we're actually dependent on each other, aren't we? Independently deployable, just so long as your payload of JSON stays just what I need and expect.
    1
  4.  @ContinuousDelivery  But the history of strategies to break development time dependencies has generally been to just move them to runtime dependencies that are typically harder to manage and reason about, and, worst of all, a lot of people will be fooled into thinking there's no problem at all. Independently deployable, but maybe broken, maybe not of any value doesn't have quite the same ring to it.
    1
  5. Imagine if your system of microservices just becomes a bunch of anemic data structures, with little more than get/set methods 🤣
    1
  6.  @Cerebradoa  I think you misinterpreted me, Juan. I don't know whose opinion you thought I was making fun of.
    1