4 ms·

No one says you can't have all of your microservices use the same language...

by tsss 3y ago

bob1029 3y ago
Absolutely. This is how we operated when we were at the peak of our tech showmanship phase. We had ~12 different services, all .NET 4.x the exact same way. This sounds like it could work, but then you start to wonder about how you'd get common code into those 12 services. Our answer at the time was nugets, but we operate in a sensitive domain with proprietary code, so public nuget services were a no go. So, we stood up our own goddamn nuget server just so we could distribute our own stuff to ourselves in the most complicated way possible. Even if you are using all the same language and patterns everywhere, it still will not spare you from all of the accidental complexity that otherwise becomes essential if you break the solution into arbitrary piles.
- ValtteriL 3y ago
  Can't you share them via shared libraries in .NET?
  - jcmontx 3y ago
    YMMV but I think you can only do that if you have a monorepo with the shared library and all the microservices
    - Atotalnoob 3y ago
      You can, but it’s just kind of hinky, you end up relying on a specific path for the shared library
- deleted 3y ago
  [deleted]
- lmm 3y ago
  Does .net not have a way to run simple private repository like Nexus? Over in JVM-land that's a basic thing that you'd be doing anyway.
  - smaudet 3y ago
    It's the difference between drag-dropping a reference between "projects" or whatnot in your monolith project, or coming up with a publish pipeline after which your merged code gets into the repo so that other people can use it, if you have three projects in three checkouts that all have to be coordinated and merged in order so that you don't accidentally break your environment and worry about security and and and.... One is much simpler than the other. Artifact management is surprisingly complex, it only looks like it works great while you aren't managing many versions and acting more like a monolith, just spread across repos/deploy points.
    - lmm 3y ago
      > It's the difference between drag-dropping a reference between "projects" or whatnot in your monolith project, or coming up with a publish pipeline after which your merged code gets into the repo so that other people can use it You already have that pipeline for release/deployment though, don't you? (And it's already hooked up to your SSO or what have you). > if you have three projects in three checkouts that all have to be coordinated and merged in order so that you don't accidentally break your environment and worry about security and and and.... It's the same as any other library dependency though, which is a completely normal thing to deal with. The cost of separating your pieces enough that you can use different versions of a library in different services is that you can use different versions of a library in different services. I'm skeptical about microservices as a deployment model, but I'm absolutely convinced that code-level modularisation and independent release cycles for things that deploy independently are worthwhile, at least if your language ecosystem has decent dependency management.
    - briHass 3y ago
      The only way package feed complexity works -- and really microservices in general -- is to be absolutely fastidious about backwards compatibility of your packages and as open as possible with transitive dependency versions. Nuget does provide mechanisms for obsoleting packages, so it's reasonable to enforce that new packages should allow for a few versions worth of backwards compatibility before deprecation and finally pulling the plug.
ljm 3y ago
Ideally you would use the same language if it had distributed support. Use Erlang or Elixir for example and you have everything you need for IPC out of the box. Might take a little bit more effort if you're on Kubernetes. One of my problems with microservices isn't really the services themselves, but the insane amount of tooling that creeps in: GRPC, Kafka, custom JSON APIs, protobufs, etc. etc. and a lot of them exist in some form to communicate between services.
- 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.
switch007 3y ago
You need a CTO with a backbone to say no to the senior people hell bent on padding their resumes and scratching an itch though Too often devs weaponise micro services and say it’s one of the key reasons for microservices is to allow free language choice !

No one says you can't have all of your microservices use the same language...

by tsss 3y ago

No one says you can't have all of your microservices use the same language...

Absolutely. This is how we operated when we were at the peak of our tech showmanship phase. We had ~12 different services, all .NET 4.x the exact same way. This sounds like it could work, but then you start to wonder about how you'd get common code into those 12 services. Our answer at the time was nugets, but we operate in a sensitive domain with proprietary code, so public nuget services were a no go. So, we stood up our own goddamn nuget server just so we could distribute our own stuff to ourselves in the most complicated way possible. Even if you are using all the same language and patterns everywhere, it still will not spare you from all of the accidental complexity that otherwise becomes essential if you break the solution into arbitrary piles.

ValtteriL 3y ago
Can't you share them via shared libraries in .NET?
- jcmontx 3y ago
  YMMV but I think you can only do that if you have a monorepo with the shared library and all the microservices
  - Atotalnoob 3y ago
    You can, but it’s just kind of hinky, you end up relying on a specific path for the shared library
deleted 3y ago
[deleted]
lmm 3y ago
Does .net not have a way to run simple private repository like Nexus? Over in JVM-land that's a basic thing that you'd be doing anyway.
- smaudet 3y ago
  It's the difference between drag-dropping a reference between "projects" or whatnot in your monolith project, or coming up with a publish pipeline after which your merged code gets into the repo so that other people can use it, if you have three projects in three checkouts that all have to be coordinated and merged in order so that you don't accidentally break your environment and worry about security and and and.... One is much simpler than the other. Artifact management is surprisingly complex, it only looks like it works great while you aren't managing many versions and acting more like a monolith, just spread across repos/deploy points.
  - lmm 3y ago
    > It's the difference between drag-dropping a reference between "projects" or whatnot in your monolith project, or coming up with a publish pipeline after which your merged code gets into the repo so that other people can use it You already have that pipeline for release/deployment though, don't you? (And it's already hooked up to your SSO or what have you). > if you have three projects in three checkouts that all have to be coordinated and merged in order so that you don't accidentally break your environment and worry about security and and and.... It's the same as any other library dependency though, which is a completely normal thing to deal with. The cost of separating your pieces enough that you can use different versions of a library in different services is that you can use different versions of a library in different services. I'm skeptical about microservices as a deployment model, but I'm absolutely convinced that code-level modularisation and independent release cycles for things that deploy independently are worthwhile, at least if your language ecosystem has decent dependency management.
  - briHass 3y ago
    The only way package feed complexity works -- and really microservices in general -- is to be absolutely fastidious about backwards compatibility of your packages and as open as possible with transitive dependency versions. Nuget does provide mechanisms for obsoleting packages, so it's reasonable to enforce that new packages should allow for a few versions worth of backwards compatibility before deprecation and finally pulling the plug.

ljm 3y ago

Ideally you would use the same language if it had distributed support. Use Erlang or Elixir for example and you have everything you need for IPC out of the box. Might take a little bit more effort if you're on Kubernetes. One of my problems with microservices isn't really the services themselves, but the insane amount of tooling that creeps in: GRPC, Kafka, custom JSON APIs, protobufs, etc. etc. and a lot of them exist in some form to communicate between services.

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.

switch007 3y ago

You need a CTO with a backbone to say no to the senior people hell bent on padding their resumes and scratching an itch though Too often devs weaponise micro services and say it’s one of the key reasons for microservices is to allow free language choice !