3 ms·

Bleah. I hate articles like this. They regurgitate all the well known talking points about enterprise software development but none of the realities of micro se

Bleah. I hate articles like this. They regurgitate all the well known talking points about enterprise software development but none of the realities of micro services. It sounds like they haven’t actually worked in the trenches supporting and coding real microservices at scale. The realities are that going from monolith to microservices is a huge investment, and only large engineering teams should do this migration. The reason is that once you go microservices You instantly require an immediate investment in devops which is something you didn’t need as much before with a monolith. Oncall rotations and pager duty schedules become imperative because services will go down. Also monitoring is another investment that you immediately need otherwise you’re completely blind. The article talks about things that are obvious, like designing the apis etc, but those are the same regardless of if it’s a module within a monolith or a microservice. All the characteristics they list at the beginning is no different than what a team that owns a module in a monolith would require as well. It feels like this article isn’t very useful because it regurgitates concepts from regular enterprise development and packages as new for microservices when it’s not. What the article lacks is the difference in architecting for a real microservice environment. One of the biggest missed issues is never mentioning dependencies. Sure it’s great to talk about how to model services with eventual consistency blah blah. But if you already have a large engineering team, which you must have otherwise why have microservices, then there will be a dependency between services and to believe otherwise is crazy. You will probably have one or two services that when they go down, your entire company is down. It’s imperative that every service is architected with that in mind and what happens when it’s down. Hand waving “eventual consistency” won’t cut it in the real world, it’s the biggest problem that each team needs to focus on early otherwise it’s a ticking time bomb.

rumanator 6y ago
> Bleah. I hate articles like this. They regurgitate all the well known talking points about enterprise software development but none of the realities of micro services. I disagree. The post is a good summary of all the key features and main concepts of a microservices architecture developed with domain-driven design. It does what it says on the tin, and you don't have to read three books to get there. > It sounds like they haven’t actually worked in the trenches supporting and coding real microservices at scale. I have no idea where you got that idea. It certainly wasn't from the blog post, though. > The realities are that going from monolith to microservices is a huge investment, and only large engineering teams should do this migration. Your rant makes no sense at all. You're just mindlessly repeating cliches about issues that have absolutely nothing to do with the subject. I mean, the blog post is about microservices software architecture with domain-driven design and clean code, but here you are whining about how you believe refactoring projects designed following an entirely different architectural style is hard.
- remote_phone 6y ago
  My point is everything they talk about is common to any type of enterprise software development. It’s not new. And then they slap on “microservices” at the end so they can claim to have written something new. If they want to write something new then talk about the realities of how microservice development is different than regular enterprise software development. Not regurgitating the same old concepts and pretending it’s eye opening and new.
  - rumanator 6y ago
    > My point is everything they talk about is common to any type of enterprise software development. It’s not new. And then they slap on “microservices” at the end so they can claim to have written something new. Again, your rant makes no sense at all. The blog post talks about a specific distributed system architecture style whose services are designed following a specific architecture style. And here you are, angry at someone because... Because you believe the author has ulterior motivations? > If they want to write something new then talk about Sorry, but you have no authority to tell others what they should or should not write. The author of this post contributed something to the public that's interesting and has value. Meanwhile what have you done?
  - ChicagoDave 6y ago
    It’s inherent in this comment that you really don’t understand DDD and why adhering to its precepts is a critical improvement in designing microservices. Plenty of books to read, videos to watch. Learn/listen before you speak.
  - vmurthy 6y ago
    Um, it may not be new to you but it is new and eye opening to me and there might be hundreds or thousands of people who haven't read about this. From a newbie's POV, I quite like how the author explains the concepts with the example of an e-commerce company. Sure there will be advanced concepts but the author makes no claims that he is addressing that audience :) .
tsss 6y ago
You have no idea what you're talking about. Monitoring and logging is just as important with a monolith, how else are you gonna notice when something is going wrong? In fact it is much more likely that your monolith will go down and lead to a significant outage because the monolith is bigger and thus has more failure points. Furthermore, a monolith that crashes will take _everything_ else with it whereas a microservice that is unavailable only impacts a part of your business. You can do some disaster recovery in your monolith to a certain degree but you will only be reimplementing things that K8S can already do. > You will probably have one or two services that when they go down, your entire company is down If you have microservices like that then your macro architecture is bad because one of the key points of an SOA is to limit the impact of failures. Probably you are using a lot of synchronous communication like REST because it was "easier" and now you have to pay the price. You chose consistency (which can be a valid choice) and now you complain about lack of availability when any undergrad knows you can not possibly have both (at a scale that requires partitioning). Using synchronous communication everywhere between microservices leads to a "distributed monolith" where you have to pay most of the costs of a SOA but get few of the benefits. The one correct thing you said is that a microservice architecture is indeed a huge investment that requires sophisticated devops processes in order not to drown in operational tasks. Microservices are a good choice when you need to scale either in amount of users or developers beyond the capabilities of a monolith (i.e. you need an application that is partition tolerant). At that point you can chose between consistency + easier development or availability. No matter what choice you make, it will be painful but it can't be avoided.

rumanator 6y ago

> Bleah. I hate articles like this. They regurgitate all the well known talking points about enterprise software development but none of the realities of micro services. I disagree. The post is a good summary of all the key features and main concepts of a microservices architecture developed with domain-driven design. It does what it says on the tin, and you don't have to read three books to get there. > It sounds like they haven’t actually worked in the trenches supporting and coding real microservices at scale. I have no idea where you got that idea. It certainly wasn't from the blog post, though. > The realities are that going from monolith to microservices is a huge investment, and only large engineering teams should do this migration. Your rant makes no sense at all. You're just mindlessly repeating cliches about issues that have absolutely nothing to do with the subject. I mean, the blog post is about microservices software architecture with domain-driven design and clean code, but here you are whining about how you believe refactoring projects designed following an entirely different architectural style is hard.

remote_phone 6y ago
My point is everything they talk about is common to any type of enterprise software development. It’s not new. And then they slap on “microservices” at the end so they can claim to have written something new. If they want to write something new then talk about the realities of how microservice development is different than regular enterprise software development. Not regurgitating the same old concepts and pretending it’s eye opening and new.
- rumanator 6y ago
  > My point is everything they talk about is common to any type of enterprise software development. It’s not new. And then they slap on “microservices” at the end so they can claim to have written something new. Again, your rant makes no sense at all. The blog post talks about a specific distributed system architecture style whose services are designed following a specific architecture style. And here you are, angry at someone because... Because you believe the author has ulterior motivations? > If they want to write something new then talk about Sorry, but you have no authority to tell others what they should or should not write. The author of this post contributed something to the public that's interesting and has value. Meanwhile what have you done?
- ChicagoDave 6y ago
  It’s inherent in this comment that you really don’t understand DDD and why adhering to its precepts is a critical improvement in designing microservices. Plenty of books to read, videos to watch. Learn/listen before you speak.
- vmurthy 6y ago
  Um, it may not be new to you but it is new and eye opening to me and there might be hundreds or thousands of people who haven't read about this. From a newbie's POV, I quite like how the author explains the concepts with the example of an e-commerce company. Sure there will be advanced concepts but the author makes no claims that he is addressing that audience :) .

tsss 6y ago

You have no idea what you're talking about. Monitoring and logging is just as important with a monolith, how else are you gonna notice when something is going wrong? In fact it is much more likely that your monolith will go down and lead to a significant outage because the monolith is bigger and thus has more failure points. Furthermore, a monolith that crashes will take _everything_ else with it whereas a microservice that is unavailable only impacts a part of your business. You can do some disaster recovery in your monolith to a certain degree but you will only be reimplementing things that K8S can already do. > You will probably have one or two services that when they go down, your entire company is down If you have microservices like that then your macro architecture is bad because one of the key points of an SOA is to limit the impact of failures. Probably you are using a lot of synchronous communication like REST because it was "easier" and now you have to pay the price. You chose consistency (which can be a valid choice) and now you complain about lack of availability when any undergrad knows you can not possibly have both (at a scale that requires partitioning). Using synchronous communication everywhere between microservices leads to a "distributed monolith" where you have to pay most of the costs of a SOA but get few of the benefits. The one correct thing you said is that a microservice architecture is indeed a huge investment that requires sophisticated devops processes in order not to drown in operational tasks. Microservices are a good choice when you need to scale either in amount of users or developers beyond the capabilities of a monolith (i.e. you need an application that is partition tolerant). At that point you can chose between consistency + easier development or availability. No matter what choice you make, it will be painful but it can't be avoided.