5 ms·

If you do so much IPC that you have to design your language around it you're probably doing it wrong. I don't think that moving to a monolith would really cut d

by tsss 3y ago

If you do so much IPC that you have to design your language around it you're probably doing it wrong. I don't think that moving to a monolith would really cut down that much on other technologies. Maybe you can do without Kafka, but certainly you will need some other kind of persistent message queue. You will still need API docs and E2E integration tests.

jocaal 3y ago
> If you do so much IPC that you have to design your language around it you're probably doing it wrong... I'm gonna have to disagree with this. Often when languages add features to their core, it allows for a very different (and often better) approach to writing code. Think Lisp with first class functions, or Rust with the borrow checker. Why should concurrency be any different? This feels like a Blub moment and I would highly recommend you give erlang or elixir a try, just to see what it is about.
- tsss 3y ago
  If you need that much IPC then you aren't doing microservices correctly. Microservices are supposed to be independent, self-contained domains wherever possible. Purely technical boundaries like dedicated caching services that you see in very large companies like Google are more of an exception and should only be used when the non-functional requirements absolutely dictate it. A language that is designed around IPC wants to distribute dynamic parts of one application over multiple interchangeable compute resources (like in an HPC environment). This is a different thing altogether from microservices, which are self-contained applications working independently to each provide a fixed piece of the whole.
  - ljm 3y ago
    The theory is that microservices are supposed to be independent and self-contained, but such a wonderful implementation of DDD is a theoretical fantasy that rarely plays out in practice. It's not just a technical difficulty but an organisational problem where communication between teams also throws a spanner in the works. If your typical microservice setup is simply distributing your call stack over a network (and oftentimes that's all it is), then you might as well use a language designed to operate in such a manner and reap the benefits of it. That kind of microservice architecture only really exists as a function of the organisation's structure such that teams can work more autonomously.
smaudet 3y ago
"You will still need API docs" Been free in my IDE since I compiled the code... "E2E integration tests" I can mostly run these on my machine, no need to stand up a cluster to get it running (bonus points if you virt multiple machines on one and still don't need the cluster for complex distributed scenarios). "you will need some other kind of persistent message queue" var queue = new Queue(); // then sometime later... queue.Save(); // or queue.EmplaceAndSave(); ... queue.Pop(); Trivial and didn't need a server to set it up. Lots of tech stack stuff simply disappears without server boundaries and the like to get in the way. There is other tech you have to deal with, but at the small scales it mostly doesn't apply. Which, you as a dev are usually only working at small, testing scales, so you don't usually need to support it.
- tsss 3y ago
  > var queue = new Queue(); // then sometime later... queue.Save(); // or queue.EmplaceAndSave(); ... queue.Pop(); Yeah, no... you'll lose data for sure, you'll have race conditions or no cooperative queuing between multiple instances of the application. This is exactly the kind of half-assery that people resort to when they say monoliths are so much less complex than microservices. A good monolith still requires all the same hard decisions about modularity, high-availability etc.
  - smaudet 3y ago
    Eh? Default queue implementations come with co-operating queuing out of the box. I suppose you could use some hand-rolled queue with no internal locking, but this is disingenuous. > you'll have race conditions or no cooperative queuing between multiple instances of the application. You're thinking micro-service again here. There's no need to have multiple "instances" at all. Any concurrency is handled internal to the application itself with use of e.g. fibers, threads, etc. A good argument to why monoliths have drawbacks can't be "well its not a microservice". :) > A good monolith still requires all the same hard decisions about modularity, high-availability etc. Never said it didn't. What it doesn't require is all the tech stack to support that over many instances, because there's one instance. A large majority of µServices is just re-implementing what your runtime gives you for free.

by tsss 3y ago

jocaal 3y ago

> If you do so much IPC that you have to design your language around it you're probably doing it wrong... I'm gonna have to disagree with this. Often when languages add features to their core, it allows for a very different (and often better) approach to writing code. Think Lisp with first class functions, or Rust with the borrow checker. Why should concurrency be any different? This feels like a Blub moment and I would highly recommend you give erlang or elixir a try, just to see what it is about.

tsss 3y ago
If you need that much IPC then you aren't doing microservices correctly. Microservices are supposed to be independent, self-contained domains wherever possible. Purely technical boundaries like dedicated caching services that you see in very large companies like Google are more of an exception and should only be used when the non-functional requirements absolutely dictate it. A language that is designed around IPC wants to distribute dynamic parts of one application over multiple interchangeable compute resources (like in an HPC environment). This is a different thing altogether from microservices, which are self-contained applications working independently to each provide a fixed piece of the whole.
- ljm 3y ago
  The theory is that microservices are supposed to be independent and self-contained, but such a wonderful implementation of DDD is a theoretical fantasy that rarely plays out in practice. It's not just a technical difficulty but an organisational problem where communication between teams also throws a spanner in the works. If your typical microservice setup is simply distributing your call stack over a network (and oftentimes that's all it is), then you might as well use a language designed to operate in such a manner and reap the benefits of it. That kind of microservice architecture only really exists as a function of the organisation's structure such that teams can work more autonomously.

smaudet 3y ago

"You will still need API docs" Been free in my IDE since I compiled the code... "E2E integration tests" I can mostly run these on my machine, no need to stand up a cluster to get it running (bonus points if you virt multiple machines on one and still don't need the cluster for complex distributed scenarios). "you will need some other kind of persistent message queue" var queue = new Queue(); // then sometime later... queue.Save(); // or queue.EmplaceAndSave(); ... queue.Pop(); Trivial and didn't need a server to set it up. Lots of tech stack stuff simply disappears without server boundaries and the like to get in the way. There is other tech you have to deal with, but at the small scales it mostly doesn't apply. Which, you as a dev are usually only working at small, testing scales, so you don't usually need to support it.

tsss 3y ago
> var queue = new Queue(); // then sometime later... queue.Save(); // or queue.EmplaceAndSave(); ... queue.Pop(); Yeah, no... you'll lose data for sure, you'll have race conditions or no cooperative queuing between multiple instances of the application. This is exactly the kind of half-assery that people resort to when they say monoliths are so much less complex than microservices. A good monolith still requires all the same hard decisions about modularity, high-availability etc.
- smaudet 3y ago
  Eh? Default queue implementations come with co-operating queuing out of the box. I suppose you could use some hand-rolled queue with no internal locking, but this is disingenuous. > you'll have race conditions or no cooperative queuing between multiple instances of the application. You're thinking micro-service again here. There's no need to have multiple "instances" at all. Any concurrency is handled internal to the application itself with use of e.g. fibers, threads, etc. A good argument to why monoliths have drawbacks can't be "well its not a microservice". :) > A good monolith still requires all the same hard decisions about modularity, high-availability etc. Never said it didn't. What it doesn't require is all the tech stack to support that over many instances, because there's one instance. A large majority of µServices is just re-implementing what your runtime gives you for free.