4 ms·

> It can be done wrong, but when executed correctly [...] Quite the self-fulfilling prophecy there. > Yes, it's easier to get your data, but in the long run [

by smoe 7y ago

> It can be done wrong, but when executed correctly [...] Quite the self-fulfilling prophecy there. > Yes, it's easier to get your data, but in the long run [...] Systems can and should be evolved and adapted over time. E.g. deploying components of the monolith as separate services. You can't easily predict what the requirements for your software going to be in say 10 years. And depending on the stage a company is, easy access to data for business decisions outweighs engineering idealism.

pg_is_a_butt 7y ago
> easy access to data for business decisions outweighs engineering idealism. GET HIM!
echelon 7y ago
> Quite the self-fulfilling prophecy there. Microservices require your organization to have an engineering culture. I would be afraid of introducing them at, say, Home Depot where (I've heard) your average programmer doesn't even write tests. If you have engineering talent within a small multiplicative factor of Google (say 0.5), then you can pull off Microservices at your org. Edit: I'm being downvoted, but I don't think it's a dangerous assumption or point to make that it takes a certain amount of discipline and experience to implement microservices correctly. When you have that technical capacity and the project calls for it, the benefit is tremendous.
- redact207 7y ago
  I think you're being downvoted because you're implying monoliths don't require an engineering culture and that microservices are a silver bullet in getting systems built correctly. I've seen good and bad in each approach. It's certainly possible to enforce good SOCs and proper boundaries in monorepos, and also possible to plough a system into the ground with microservices. They're all just tools in your toolbox and both have a part to play in modern development.
  - deleted 7y ago
    [deleted]
- jedberg 7y ago
  You’d be surprised how sophisticated Home Depot is. They switched their monolith to microservices using Spinnaker and even contributed back to Spinnaker.
TeMPOraL 7y ago
> easy access to data for business decisions outweighs engineering idealism I think there are different levels of sophistication of "engineering idealism". GP talks about "data ownership", and I get the desire to keep the data a microservice is responsible for locked in tightly with it. But let's be precise why it's good: because isolating responsibility reduces complexity. Not because code has some innate right to privacy. In my own engineering idealism, there's no internal data privacy in the system. Things should be instrumentable, observable in principle. If an analyst wants to take your carefully designed internal NoSQL document structure and plug it into an OLAP cube for some reason, there must be a path to doing that; if that's an expected part of the business, the service needs to have it on the feature list, that this should be doable without degrading the service. Software needs to be in boxes because otherwise we can't handle it mentally, but the boxes really shouldn't be that black.
- edmundsauto 7y ago
  Isolating responsibility reduces complexity for that piece of code. It increases complexity for assembling the whole thing into a holistic package, which is usually what analytics primary need is. YMMV, but the tradeoff is less complexity at the SWE/prod department, and more at the analytics team.
- wtetzner 7y ago
  > But let's be precise why it's good: because isolating responsibility reduces complexity. The thing is, it just shifts around complexity. Once you have microservices, you have to deal with a bunch of new failure modes, plus a bunch of extra code whose only purpose is to provide an interface to other services. And in terms of separating data, the worst part is that you've prevent access this data with some other data within the same transaction.

by smoe 7y ago

pg_is_a_butt 7y ago

> easy access to data for business decisions outweighs engineering idealism. GET HIM!

echelon 7y ago

> Quite the self-fulfilling prophecy there. Microservices require your organization to have an engineering culture. I would be afraid of introducing them at, say, Home Depot where (I've heard) your average programmer doesn't even write tests. If you have engineering talent within a small multiplicative factor of Google (say 0.5), then you can pull off Microservices at your org. Edit: I'm being downvoted, but I don't think it's a dangerous assumption or point to make that it takes a certain amount of discipline and experience to implement microservices correctly. When you have that technical capacity and the project calls for it, the benefit is tremendous.

redact207 7y ago
I think you're being downvoted because you're implying monoliths don't require an engineering culture and that microservices are a silver bullet in getting systems built correctly. I've seen good and bad in each approach. It's certainly possible to enforce good SOCs and proper boundaries in monorepos, and also possible to plough a system into the ground with microservices. They're all just tools in your toolbox and both have a part to play in modern development.
- deleted 7y ago
  [deleted]
jedberg 7y ago
You’d be surprised how sophisticated Home Depot is. They switched their monolith to microservices using Spinnaker and even contributed back to Spinnaker.

TeMPOraL 7y ago

> easy access to data for business decisions outweighs engineering idealism I think there are different levels of sophistication of "engineering idealism". GP talks about "data ownership", and I get the desire to keep the data a microservice is responsible for locked in tightly with it. But let's be precise why it's good: because isolating responsibility reduces complexity. Not because code has some innate right to privacy. In my own engineering idealism, there's no internal data privacy in the system. Things should be instrumentable, observable in principle. If an analyst wants to take your carefully designed internal NoSQL document structure and plug it into an OLAP cube for some reason, there must be a path to doing that; if that's an expected part of the business, the service needs to have it on the feature list, that this should be doable without degrading the service. Software needs to be in boxes because otherwise we can't handle it mentally, but the boxes really shouldn't be that black.

edmundsauto 7y ago
Isolating responsibility reduces complexity for that piece of code. It increases complexity for assembling the whole thing into a holistic package, which is usually what analytics primary need is. YMMV, but the tradeoff is less complexity at the SWE/prod department, and more at the analytics team.
wtetzner 7y ago
> But let's be precise why it's good: because isolating responsibility reduces complexity. The thing is, it just shifts around complexity. Once you have microservices, you have to deal with a bunch of new failure modes, plus a bunch of extra code whose only purpose is to provide an interface to other services. And in terms of separating data, the worst part is that you've prevent access this data with some other data within the same transaction.