4 ms·

I've come to the conclusion that microservices as usually implemented are simply a Conway's law concern. We haven't had a great track record defining the seman

I've come to the conclusion that microservices as usually implemented are simply a Conway's law concern. We haven't had a great track record defining the semantics of component boundaries, but http is both simple enough that it constricts code flow in a particular way leaving a lot of misunderstandings and bike shedding discussions off of the table, and is the ligua franca for external services owned by other orgs so your engineers can be universally expected to understand those semantics. There is a nice decoupling of letting teams make technology choices though. Letting that drift on a per team basis is kind of nice to allow experimentation with different technologies without having to get the whole org onboard. Maybe I need to go on the talk giving, consultant circuit reselling a restricted view of DI as "hybrid service architecture! Write your code as microservices but DevOps can colocate your apps in the same process if that's more efficient!" Lolz It's also quite a nerd trap as we developers love to separate components into as small of boxes as possible, but just like I've seen super deep object hierarchies that didn't gain you anything at the end of the day, it's easy to fall into the trap of spinning every tiny bit of code into its own service. I'm creating my own backend arch right now from scratch, and really trying to look at each network traversal from a "what does drawing this boundary actually get me" perspective. And I'm only splitting that out because the third party protocol being implemented is inherently separate services in an interesting way.

karmakaze 5y ago
Spot on. Microservices is a way of scaling people. There are other ways of scaling systems. I would suggest that http not be the go-to mechanism for communicating between microservices. Each should be able to operate to some degree without hard dependencies. If you build using microservices with RPC over http or what-have-you replacing function calls, you've done it wrong. You can usually tell if your 'bounded context' is of the form noun-service or adjective-noun-service. Usually the context boundary should be a process (workflow kind) that serves a user type. Reliable one-way async datastreams are more useful for keeping microservices fed with the information it needs, and it can decide how to utilize that information in a way that makes sense for that service. If you have core 'source of truth' services used by many others, you have a distributed monolith.
scottious 5y ago
There are plenty of monoliths that scale in terms of number of contributors and organizational changes. For example, the Linux kernel. I've worked on massive monoliths that were 20 years old and changed hands and org structures tons of times and nobody ever thought "this needs to be microservices!" Microservices are not the only way to modularize code. Also, there is TONS of bike-shedding with regard to HTTP. Which HTTP method do you use? How do you structure your paths? What does the body of the request look like? How to we translate failures into the various HTTP error codes? Do you send a 200 or a 201 status for this particular request? I could go on and on... Even among well established HTTP APIs, there are differences. > Letting [technology choices] drift on a per team basis is kind of nice to allow experimentation with different technologies without having to get the whole org onboard. This is very much a double edged sword. I've seen this happen and people just tend to avoid services in languages/frameworks that they don't know. And even if they don't avoid them, they are less productive in them. We have a critical services written in Rust and one guy at the company knows Rust. We have 2 services written in a particular Java reactive framework which only a few people know how to use. Any newcomers to these services have to spend a lot of time learning a new thing.
- monocasa 5y ago
  > There are plenty of monoliths that scale in terms of number of contributors and organizational changes. For example, the Linux kernel. I've worked on massive monoliths that were 20 years old and changed hands and org structures tons of times and nobody ever thought "this needs to be microservices!" > Microservices are not the only way to modularize code. Nobody said that it was the only way to modularize code. However, but to be frank, most of those require greater discipline than most of the engineering teams going to microservices have. These teams don't do a great job at microservices, but probably would do a worse job with a monolith. > Also, there is TONS of bike-shedding with regard to HTTP. Which HTTP method do you use? How do you structure your paths? What does the body of the request look like? How to we translate failures into the various HTTP error codes? Do you send a 200 or a 201 status for this particular request? I could go on and on... Even among well established HTTP APIs, there are differences. You can bike shed anything, that's why it's called bikeshedding. Referring to nobody being able to contribute to the design review of a nuclear reactor so the committee just fights over the color of the bikeshed. That being said, the state space of an HTTP API is strictly smaller than a local library's API, and you can generally expect backend engineers to at least know what complete the state space of options looks like and what the tradeoffs are. > This is very much a double edged sword. I've seen this happen and people just tend to avoid services in languages/frameworks that they don't know. And even if they don't avoid them, they are less productive in them. We have a critical services written in Rust and one guy at the company knows Rust. We have 2 services written in a particular Java reactive framework which only a few people know how to use. Any newcomers to these services have to spend a lot of time learning a new thing. The other end I've seen is that having the whole org on one tech stack is a single organizational point of failure. It's not an issue for smaller orgs, but if you have more than say, 200 devs working on the same product, you want a little experimentation and a lower barrier to new technology. If something is abandoned you can simply replace it, since it's not your literal entire stack. And forcing your devs to be polylingual I've found makes them better in all of the language they use, even their primary language.

karmakaze 5y ago

Spot on. Microservices is a way of scaling people. There are other ways of scaling systems. I would suggest that http not be the go-to mechanism for communicating between microservices. Each should be able to operate to some degree without hard dependencies. If you build using microservices with RPC over http or what-have-you replacing function calls, you've done it wrong. You can usually tell if your 'bounded context' is of the form noun-service or adjective-noun-service. Usually the context boundary should be a process (workflow kind) that serves a user type. Reliable one-way async datastreams are more useful for keeping microservices fed with the information it needs, and it can decide how to utilize that information in a way that makes sense for that service. If you have core 'source of truth' services used by many others, you have a distributed monolith.

scottious 5y ago

There are plenty of monoliths that scale in terms of number of contributors and organizational changes. For example, the Linux kernel. I've worked on massive monoliths that were 20 years old and changed hands and org structures tons of times and nobody ever thought "this needs to be microservices!" Microservices are not the only way to modularize code. Also, there is TONS of bike-shedding with regard to HTTP. Which HTTP method do you use? How do you structure your paths? What does the body of the request look like? How to we translate failures into the various HTTP error codes? Do you send a 200 or a 201 status for this particular request? I could go on and on... Even among well established HTTP APIs, there are differences. > Letting [technology choices] drift on a per team basis is kind of nice to allow experimentation with different technologies without having to get the whole org onboard. This is very much a double edged sword. I've seen this happen and people just tend to avoid services in languages/frameworks that they don't know. And even if they don't avoid them, they are less productive in them. We have a critical services written in Rust and one guy at the company knows Rust. We have 2 services written in a particular Java reactive framework which only a few people know how to use. Any newcomers to these services have to spend a lot of time learning a new thing.

monocasa 5y ago
> There are plenty of monoliths that scale in terms of number of contributors and organizational changes. For example, the Linux kernel. I've worked on massive monoliths that were 20 years old and changed hands and org structures tons of times and nobody ever thought "this needs to be microservices!" > Microservices are not the only way to modularize code. Nobody said that it was the only way to modularize code. However, but to be frank, most of those require greater discipline than most of the engineering teams going to microservices have. These teams don't do a great job at microservices, but probably would do a worse job with a monolith. > Also, there is TONS of bike-shedding with regard to HTTP. Which HTTP method do you use? How do you structure your paths? What does the body of the request look like? How to we translate failures into the various HTTP error codes? Do you send a 200 or a 201 status for this particular request? I could go on and on... Even among well established HTTP APIs, there are differences. You can bike shed anything, that's why it's called bikeshedding. Referring to nobody being able to contribute to the design review of a nuclear reactor so the committee just fights over the color of the bikeshed. That being said, the state space of an HTTP API is strictly smaller than a local library's API, and you can generally expect backend engineers to at least know what complete the state space of options looks like and what the tradeoffs are. > This is very much a double edged sword. I've seen this happen and people just tend to avoid services in languages/frameworks that they don't know. And even if they don't avoid them, they are less productive in them. We have a critical services written in Rust and one guy at the company knows Rust. We have 2 services written in a particular Java reactive framework which only a few people know how to use. Any newcomers to these services have to spend a lot of time learning a new thing. The other end I've seen is that having the whole org on one tech stack is a single organizational point of failure. It's not an issue for smaller orgs, but if you have more than say, 200 devs working on the same product, you want a little experimentation and a lower barrier to new technology. If something is abandoned you can simply replace it, since it's not your literal entire stack. And forcing your devs to be polylingual I've found makes them better in all of the language they use, even their primary language.