4 ms·

I think the pushback can be summarized by the fact that there are more moving parts with a microservice architecture. Harder to test, more things that can break

I think the pushback can be summarized by the fact that there are more moving parts with a microservice architecture. Harder to test, more things that can break, more coordination for deployments. Are you referring to mashups in that the application is using external APIs? I'd say that's similar with the difference being you don't have to coordinate the deployment part. With mashups you still have the testing challenge and reliance on another system to be running that comes with a microservice architecture.

HeroOfAges 11y ago
I guess I'm confused about why you would need to coordinate deployments. In my mind each microservice is completely decoupled from any other. There are a large number of tools to automate the process of testing and deployment. I think we as developers understand the need to code defensively and we understand how to build applications that have large amounts of asynchronous operations. I'm also not sure why people keep insisting on using messaging as a way to allow one microservice to communicate to another. Wouldn't exposing a RESTful interface over HTTP work well enough? The concept seems so simple and refreshing. What am I missing?
- mountaineer 11y ago
  Interesting, I feel like I've seen much more literature about RESTful microservices than message oriented approaches. I've done it both ways and I'm of the opinion that RESTful services are more complicated for a couple reasons: * All RESTful services must be up and running for application to be fully up and running * application must have all knowledge of RESTful services it calls With messaging (and PubSub), services don't need to be running at all times and you can add as many services you'd like without the application needing to know. Applications just says "hey, something happened" and services go to work. I agree with you, in either case, it is important to code defensively and be aware of possible request version mismatches. Deployment coordination is probably awash between the 2 approaches. I think testing is more of a challenge with message oriented too, as most integration testing tools are geared towards HTTP interactions.

HeroOfAges 11y ago

I guess I'm confused about why you would need to coordinate deployments. In my mind each microservice is completely decoupled from any other. There are a large number of tools to automate the process of testing and deployment. I think we as developers understand the need to code defensively and we understand how to build applications that have large amounts of asynchronous operations. I'm also not sure why people keep insisting on using messaging as a way to allow one microservice to communicate to another. Wouldn't exposing a RESTful interface over HTTP work well enough? The concept seems so simple and refreshing. What am I missing?

mountaineer 11y ago
Interesting, I feel like I've seen much more literature about RESTful microservices than message oriented approaches. I've done it both ways and I'm of the opinion that RESTful services are more complicated for a couple reasons: * All RESTful services must be up and running for application to be fully up and running * application must have all knowledge of RESTful services it calls With messaging (and PubSub), services don't need to be running at all times and you can add as many services you'd like without the application needing to know. Applications just says "hey, something happened" and services go to work. I agree with you, in either case, it is important to code defensively and be aware of possible request version mismatches. Deployment coordination is probably awash between the 2 approaches. I think testing is more of a challenge with message oriented too, as most integration testing tools are geared towards HTTP interactions.