3 ms·

> I have no idea why people keep thinking microservices is all about scalability. It's an aspect. It's often the beginning of a micro-service migration story i

> I have no idea why people keep thinking microservices is all about scalability. It's an aspect. It's often the beginning of a micro-service migration story in talks I've heard. > Microservices is all about taking a big problem and breaking it down into smaller components ... and putting the network between them. It's all well and good but the tradeoffs are not obvious there either. Most engineers I know who claim to be experts in distributed systems don't even know how to formally model their systems. This is manageable at a certain small scale as some computations take 35 or more steps to reveal themselves. But even the AWS team has realized that this architecture comes with the added burden of complex failure modes[0]. Obscenely complex failure modes that aren't detectable without formal models. Even the presenter mentioned... why even HTTP? Why not a typed, serialized format on a robust message bus? Even then... race conditions in a highly distributed environment are terrible beasts. [0] http://research.microsoft.com/en-us/um/people/lamport/tla/amazon.html http://research.microsoft.com/en-us/um/people/lamport/tla/am... You just have to know your data. The architecture comes after... and will change over time.

threeseed 10y ago
You seem to be repeating these weird myths that have no basis in reality. You don't need to be an expert in distributed systems to use microservices. It's literally replacing a function call with an RPC call. That's it. If you want to make tracing easier you tag the user request with an ID and pass it through your API calls or use something like Zipkin. But needing formal verification in order to test your architecture ? Bizarre. And I've worked on 2 of the world's top 5 ecommerce sites which both use microservices. And HTTP is used for many reasons namely that it is easy to inspect over the wire, is fully supported by all firewalls and API gateways e.g. Apigee. And nothing is stopping you using a typed, serialized format over HTTP. Likewise nothing is stopping you using an message bus with a microservices architecture.
- vkou 10y ago
  > It's literally replacing a function call with an RPC call. Until you want to make five function calls, in a transactional manner. Architecting correct transaction semantics in a monolithic application is often much easier then doing so across five microservices.
  - tmd83 10y ago
    Yeah, that absolutely didn't compute for me either. If it really was the case with no thoughts needed for transactions or correctness I would have started to split my monolithic apps years ago. Its when your data model is complex enough to make consistency/correctness difficult without transactions you have a real trouble splitting things up.
- agentultra 10y ago
  > You seem to be repeating these weird myths that have no basis in reality. No basis at all? I knew I was unhinged... > You don't need to be an expert in distributed systems to use microservices. True. Hooray for abstractions. You don't need to understand how the V8 engine allocates and garbage collects memory either... well until you do. > It's literally replacing a function call with an RPC call. You're not wrong. Which is the point. Whether for architectural or performance reasons I think you need to understand your domain and model your data first. For domains that map really well to the microservice architecture you're not going to have many problems. And a formal specification is overkill for many, many scenarios. That doesn't mean they're useless. They're just not useful, perhaps, for e-commerce sites. But anywhere you have an RPC call that depends on external state, ordering, consensus... the point is that the tradeoffs are not always immediately apparent unless you know your data really well. > And I've worked on 2 of the world's top 5 ecommerce sites which both use microservices. And I've worked on public and private clouds! Cool. The point was and still is the same whether performance or architecture... think about your data! The rest falls out from that.
- barrkel 10y ago
  RPC vs PC means introduces a greatly increased probability of random failure. If you're trying to do something transactional, you're in a different world of pain.
sokoloff 10y ago
> [Scalability i]s an aspect. It's often the beginning of a micro-service migration story in talks I've heard. It absolutely helps with people and org scalability. I haven't seen it help with technical load scalability (assuming you were already doing monolithic development relatively "right"; we ran a >$1BB company for the overwhelming majority on a single SQL server).

threeseed 10y ago

You seem to be repeating these weird myths that have no basis in reality. You don't need to be an expert in distributed systems to use microservices. It's literally replacing a function call with an RPC call. That's it. If you want to make tracing easier you tag the user request with an ID and pass it through your API calls or use something like Zipkin. But needing formal verification in order to test your architecture ? Bizarre. And I've worked on 2 of the world's top 5 ecommerce sites which both use microservices. And HTTP is used for many reasons namely that it is easy to inspect over the wire, is fully supported by all firewalls and API gateways e.g. Apigee. And nothing is stopping you using a typed, serialized format over HTTP. Likewise nothing is stopping you using an message bus with a microservices architecture.

vkou 10y ago
> It's literally replacing a function call with an RPC call. Until you want to make five function calls, in a transactional manner. Architecting correct transaction semantics in a monolithic application is often much easier then doing so across five microservices.
- tmd83 10y ago
  Yeah, that absolutely didn't compute for me either. If it really was the case with no thoughts needed for transactions or correctness I would have started to split my monolithic apps years ago. Its when your data model is complex enough to make consistency/correctness difficult without transactions you have a real trouble splitting things up.
agentultra 10y ago
> You seem to be repeating these weird myths that have no basis in reality. No basis at all? I knew I was unhinged... > You don't need to be an expert in distributed systems to use microservices. True. Hooray for abstractions. You don't need to understand how the V8 engine allocates and garbage collects memory either... well until you do. > It's literally replacing a function call with an RPC call. You're not wrong. Which is the point. Whether for architectural or performance reasons I think you need to understand your domain and model your data first. For domains that map really well to the microservice architecture you're not going to have many problems. And a formal specification is overkill for many, many scenarios. That doesn't mean they're useless. They're just not useful, perhaps, for e-commerce sites. But anywhere you have an RPC call that depends on external state, ordering, consensus... the point is that the tradeoffs are not always immediately apparent unless you know your data really well. > And I've worked on 2 of the world's top 5 ecommerce sites which both use microservices. And I've worked on public and private clouds! Cool. The point was and still is the same whether performance or architecture... think about your data! The rest falls out from that.
barrkel 10y ago
RPC vs PC means introduces a greatly increased probability of random failure. If you're trying to do something transactional, you're in a different world of pain.

sokoloff 10y ago

> [Scalability i]s an aspect. It's often the beginning of a micro-service migration story in talks I've heard. It absolutely helps with people and org scalability. I haven't seen it help with technical load scalability (assuming you were already doing monolithic development relatively "right"; we ran a >$1BB company for the overwhelming majority on a single SQL server).