3 ms·

Obviously, the article is microservice apologia, but... > They were able to re-use most of their working code by combining it into a single long running micros

by bhauer 3y ago

Obviously, the article is microservice apologia, but... > They were able to re-use most of their working code by combining it into a single long running microservice that is horizontally scaled using ECS... No, it was no longer a microservice; it became a plain service, as in SOA. It was no longer micro. That's the whole point. They could have saved time and money had they just made the thing a plain service to begin with. This thing was not sufficiently complicated to warrant the complexity of starting with a bunch of microservices. The article says many hot takes have missed the point, but I think what we're seeing here is an example of the two sides talking past one another since the author hasn't appreciated the opposition's arguments at all.

m_mueller 3y ago
One thing to note is that the transition from smaller to larger services tends to be straight forward, while cutting into smaller can be tricky. Thus IMO there is some merit to keeping them small in the beginning until you can analyse them under production workloads. That being said, in this case here I think some very simple performance / cost modelling would have shown the issues with serverless already in the beginning. I do find serverless architecture useful, but not for such a case with heavy base load. Furthermore, data locality is also an important aspect to consider in anything with strong latency or throughput requirements - serverless or not.
- mirekrusin 3y ago
  It's the other way around - start with monolith (because it's easier to change things, it's just single pr addressing all places at once) and then, possibly few years later, whatever has crystalized and has clear boundaries with little to no changes coming in or changes contained within this boundary - can be potentially extracted. Just look how over-represented RoR is/was as bootstrap tech in known, successful companies. Microservices is not yes/no - it's a slider. You may find sweet spot at ie. 50/50 split like ie. github does, have more or less microservices while keeping core in monolith or services under single versioned monorepo. Microservices are good for satellite services like system integration, pre/post-processing, gateways etc. As a rule of thumb whatever can fit single (tech lead + team)'s "head" - can be monolithic (single monolith or set of services under single versioned monorepo managed by that team). Their job is to provide stable apis/uis - otherwise it can be seen as black box by other teams. This is natural way things evolve (teams are created around naturally bounded concepts) and the suggestion is - don't break it by creating mismatches, keep it in harmony. If something creates measurable problems, slowly form team around it with new tech lead from existing team and let it grow on it's own - it'll extract itself to separate subsystem by itself. It doesn't have to be done overnight. It's astounding how many people use "scale" as chupacabra to scare everybody in the meeting room without clearly defining what they mean by "scale". To make decision around changing architecture to scale you need to precisely define what it means, have metrics, have benchmarks showing current limits, proof it's a problem now or near future and focus just on those actual issues, if they even exist.
  - m_mueller 3y ago
    > (because it's easier to change things, it's just single pr addressing all places at once) and then, possibly few years later, whatever has crystalized and has clear boundaries with little to no changes coming in or changes contained within this boundary - can be potentially extracted. From my experience you get the best of both worlds by having a mono-repo but try to keep your services small-ish. E.g. for a reporting framework we have separate services for source data extraction, one for view transformations and one for exports. We can always recombine that (and we do actually integrate it locally in a single process for dev/debugging purposes), but it does enforce some good practices in keeping the boundaries clean IMO. Note that I wasn't arguing at all to just go blindly all-in on Microservices, I was just saying there is some merit and YMMV.
    - mirekrusin 3y ago
      Yes, we do it as well - we have local monolith workspace package that combines all services and simulators in single node process. We don't use it on any environments, just for local development and ci. It works very well (very fast, very little resources and with simulators for external services you can work even on a plane without internet if you want and system behaves very much like real one in production). And yes, non-microservices doesn't imply monolith. We have many services. But they're not microservices because they don't have their own data store and distinct versioning/deployment - they're part of monorepo.
klabb3 3y ago
Yes, and that’s not the only example of microservice apologia: > They state in the blog that this was quick to build, which is the point. When you are exploring how to construct something, building a prototype in a few days or weeks is a good approach. First, it’s a huge stretch to say its simpler to use microservices. Anything distributed has to deal with consistency, dropped messages, serialization, propagation latency etc. If you choose to ignore those aspects, that doesn’t make it simpler, it just leaves a wrapped gift of complexity to your future coworkers who will have to maintain it. Secondly, this wasn’t the case of building something exploratory for future unpredictable workloads. All the requirements were already available. This tells you an important story: Amazon engineers were not able to estimate upfront how much “serverless” resources were needed, and how this “microservice mesh” would perform. This isn’t surprising, because the more complex a system is, the harder it is to predict how it’ll work under some workload. And it doesn’t help that the microservice preachers have been actively discouraging developers to think about infrastructure. I don’t have a horse in this race. I often hold off with judgment until I have seen the defending side speak. In this case, the defense only strengthens the cause for concern.
potamic 3y ago
What's the difference between a microservice and an SOA service?

by bhauer 3y ago

m_mueller 3y ago

One thing to note is that the transition from smaller to larger services tends to be straight forward, while cutting into smaller can be tricky. Thus IMO there is some merit to keeping them small in the beginning until you can analyse them under production workloads. That being said, in this case here I think some very simple performance / cost modelling would have shown the issues with serverless already in the beginning. I do find serverless architecture useful, but not for such a case with heavy base load. Furthermore, data locality is also an important aspect to consider in anything with strong latency or throughput requirements - serverless or not.

mirekrusin 3y ago
It's the other way around - start with monolith (because it's easier to change things, it's just single pr addressing all places at once) and then, possibly few years later, whatever has crystalized and has clear boundaries with little to no changes coming in or changes contained within this boundary - can be potentially extracted. Just look how over-represented RoR is/was as bootstrap tech in known, successful companies. Microservices is not yes/no - it's a slider. You may find sweet spot at ie. 50/50 split like ie. github does, have more or less microservices while keeping core in monolith or services under single versioned monorepo. Microservices are good for satellite services like system integration, pre/post-processing, gateways etc. As a rule of thumb whatever can fit single (tech lead + team)'s "head" - can be monolithic (single monolith or set of services under single versioned monorepo managed by that team). Their job is to provide stable apis/uis - otherwise it can be seen as black box by other teams. This is natural way things evolve (teams are created around naturally bounded concepts) and the suggestion is - don't break it by creating mismatches, keep it in harmony. If something creates measurable problems, slowly form team around it with new tech lead from existing team and let it grow on it's own - it'll extract itself to separate subsystem by itself. It doesn't have to be done overnight. It's astounding how many people use "scale" as chupacabra to scare everybody in the meeting room without clearly defining what they mean by "scale". To make decision around changing architecture to scale you need to precisely define what it means, have metrics, have benchmarks showing current limits, proof it's a problem now or near future and focus just on those actual issues, if they even exist.
- m_mueller 3y ago
  > (because it's easier to change things, it's just single pr addressing all places at once) and then, possibly few years later, whatever has crystalized and has clear boundaries with little to no changes coming in or changes contained within this boundary - can be potentially extracted. From my experience you get the best of both worlds by having a mono-repo but try to keep your services small-ish. E.g. for a reporting framework we have separate services for source data extraction, one for view transformations and one for exports. We can always recombine that (and we do actually integrate it locally in a single process for dev/debugging purposes), but it does enforce some good practices in keeping the boundaries clean IMO. Note that I wasn't arguing at all to just go blindly all-in on Microservices, I was just saying there is some merit and YMMV.
  - mirekrusin 3y ago
    Yes, we do it as well - we have local monolith workspace package that combines all services and simulators in single node process. We don't use it on any environments, just for local development and ci. It works very well (very fast, very little resources and with simulators for external services you can work even on a plane without internet if you want and system behaves very much like real one in production). And yes, non-microservices doesn't imply monolith. We have many services. But they're not microservices because they don't have their own data store and distinct versioning/deployment - they're part of monorepo.

klabb3 3y ago

Yes, and that’s not the only example of microservice apologia: > They state in the blog that this was quick to build, which is the point. When you are exploring how to construct something, building a prototype in a few days or weeks is a good approach. First, it’s a huge stretch to say its simpler to use microservices. Anything distributed has to deal with consistency, dropped messages, serialization, propagation latency etc. If you choose to ignore those aspects, that doesn’t make it simpler, it just leaves a wrapped gift of complexity to your future coworkers who will have to maintain it. Secondly, this wasn’t the case of building something exploratory for future unpredictable workloads. All the requirements were already available. This tells you an important story: Amazon engineers were not able to estimate upfront how much “serverless” resources were needed, and how this “microservice mesh” would perform. This isn’t surprising, because the more complex a system is, the harder it is to predict how it’ll work under some workload. And it doesn’t help that the microservice preachers have been actively discouraging developers to think about infrastructure. I don’t have a horse in this race. I often hold off with judgment until I have seen the defending side speak. In this case, the defense only strengthens the cause for concern.

potamic 3y ago

What's the difference between a microservice and an SOA service?