4 ms·

I've come to the conclusion that microservices work for large organizations where division of labor is important but for small development teams it actually mak

I've come to the conclusion that microservices work for large organizations where division of labor is important but for small development teams it actually makes things worse. What once was just a function call now becomes an API call. And now you need to manage multiple CI/CD builds and scripts. It adds a tremendous amount of overhead and there is less time spent delivering core value. Serverless architectures and app platforms seems to correct a lot of this overhead and frustration while still providing most of the benefits of microservices.

ngngngng 8y ago
I'm on a small team working with microservices. I have different complaints than yours. The main issue I run into with microservices is I lose the benefit of my Go compiler. I don't like in dynamic languages because of all the runtime errors I run into. With microservices, even using a statically typed language becomes a nightmare of runtime errors. If I change the type on a struct that i'm marshaling and unmarshaling between services, I can break my whole pipeline if I forget to update the type on each microservice. This feels like something that should be easy to catch with a compiler.
- jayd16 8y ago
  If you use code gen like gRPC or thrift, it is easy for a compiler to catch. Even if you're using microservices with a shared DTO library, its easy for the compiler to catch.
- marcrosoft 8y ago
  A monorepo can help with this.
- solidasparagus 8y ago
  If your services need a shared, implicit understanding of types, you're not respecting the microservice boundaries. Each microservice needs to offer a contract describing what inputs it accepts and immediately reject a request that doesn't meet that contract. Then type mismatches becomes very obvious during development when you start getting 400s when testing against the DEV endpoint. Don't pass around opaque structs.
afgionio 8y ago
I've never found the division of labor argument all that compelling. Using multiple services compels clean divisions and impenetrable abstractions, but shouldn't it be possible to achieve that within a single program? A language with strong support for information hiding should be able to enforce the restrictive interfaces that microservices compel, but without the complexity and overhead of going over the network. If that's not possible, I'd take that as a sign that we need new languages and tools.

ngngngng 8y ago

I'm on a small team working with microservices. I have different complaints than yours. The main issue I run into with microservices is I lose the benefit of my Go compiler. I don't like in dynamic languages because of all the runtime errors I run into. With microservices, even using a statically typed language becomes a nightmare of runtime errors. If I change the type on a struct that i'm marshaling and unmarshaling between services, I can break my whole pipeline if I forget to update the type on each microservice. This feels like something that should be easy to catch with a compiler.

jayd16 8y ago
If you use code gen like gRPC or thrift, it is easy for a compiler to catch. Even if you're using microservices with a shared DTO library, its easy for the compiler to catch.
marcrosoft 8y ago
A monorepo can help with this.
solidasparagus 8y ago
If your services need a shared, implicit understanding of types, you're not respecting the microservice boundaries. Each microservice needs to offer a contract describing what inputs it accepts and immediately reject a request that doesn't meet that contract. Then type mismatches becomes very obvious during development when you start getting 400s when testing against the DEV endpoint. Don't pass around opaque structs.

afgionio 8y ago

I've never found the division of labor argument all that compelling. Using multiple services compels clean divisions and impenetrable abstractions, but shouldn't it be possible to achieve that within a single program? A language with strong support for information hiding should be able to enforce the restrictive interfaces that microservices compel, but without the complexity and overhead of going over the network. If that's not possible, I'd take that as a sign that we need new languages and tools.