4 ms·

I would agree people are a bit too enthusiastic about microservices these days. The stack I work on is, IMO, broken into too many microservices (admittedly, I h

I would agree people are a bit too enthusiastic about microservices these days. The stack I work on is, IMO, broken into too many microservices (admittedly, I had a large part in the decisions that resulted in that). I wouldn't say it's made things terrible but it has slowed down velocity and makes the system as a whole harder to reason about. If I were to re-architect from scratch, I'd probably slash about at least a third of the microservices we have. In the future I'd be inclined to keep sufficiently modular such that various components could be broken out as separate services if needed, but only do so if compelling reasons to do so presented themselves.

mooreds 8y ago
So would you consider more of an SOA approach in the future, as compared to micro services? Also, when your team architected the microservices originally, how many previous microservices systems had y'all built? I haven't built any and am just trying to get a feel for the learning curve.
- lucidone 8y ago
  As someone on a dev team with little experience with microservices, including myself initially, you're going to make a big mess before you know how to clean it up. Take eventual consistency seriously. Limit rpc across services as much as possible. Agree on standards and your source of truth as early as possible. CI/CD the small stuff that doesn't matter (linting, test running). Also, have a good integration/e2e testing set up early - mock tests ended up being very brittle for us.
  - not_kurt_godel 8y ago
    Agree with all of this, especially: > have a good integration/e2e testing set up early - mock tests ended up being very brittle for us. Unfortunately microservices also can make good integration testing difficult when it comes to testing full e2e functionality. The results of testing e2e, by nature, rely on the sum of the services interacting with each other properly, thus creating testing dependencies between services that negate some of the advantages of having separated them in the first place.

mooreds 8y ago

So would you consider more of an SOA approach in the future, as compared to micro services? Also, when your team architected the microservices originally, how many previous microservices systems had y'all built? I haven't built any and am just trying to get a feel for the learning curve.

lucidone 8y ago
As someone on a dev team with little experience with microservices, including myself initially, you're going to make a big mess before you know how to clean it up. Take eventual consistency seriously. Limit rpc across services as much as possible. Agree on standards and your source of truth as early as possible. CI/CD the small stuff that doesn't matter (linting, test running). Also, have a good integration/e2e testing set up early - mock tests ended up being very brittle for us.
- not_kurt_godel 8y ago
  Agree with all of this, especially: > have a good integration/e2e testing set up early - mock tests ended up being very brittle for us. Unfortunately microservices also can make good integration testing difficult when it comes to testing full e2e functionality. The results of testing e2e, by nature, rely on the sum of the services interacting with each other properly, thus creating testing dependencies between services that negate some of the advantages of having separated them in the first place.