8 ms·
I found this interesting and an excellent general overview of today's monitoring practices while using microservices. I have to say, though, that I am always p
by sklivvz1971 7y ago
I found this interesting and an excellent general overview of today's monitoring practices while using microservices.
I have to say, though, that I am always perplexed by these toy microservice architectures because they are not solving a problem but creating it. For example, we would not need sophisticated distributed tracing if we used less moving parts; we would not need to use highly optimized (but hard to debug) protocols like grpc and protobuf if we did not have to rely on a massive graph of calls for each service, and so on.
Of course, there are a bunch of lovely use cases for microservices, mostly around "how do we make 1k developers collaborate over our codebase?" (answer: enlarge the codebase!), which always sounded like a self-fulfilling prophecy to me, but then again, I loathe working for huge companies.
If that is your case, then these tools will make your developer life a little more bearable. If you are playing with microservices because they are fresh and new, please consider a more conservative architecture first.
- orf 7y agoThese solutions didn’t appear out of thin air because people get bored one day. Micro services solve tangible, real world problems. gRPC isn’t necessary hard to debug, and it brings a whole host of improvements over whatever ad-hoc mess you used before.
- ioquatix 7y agoImprovements like...?
- mping 7y agoPerformance, I guess. Also, a schema. Eg json has schema but most apis I know don't use json schemas.
- deleted 7y ago[deleted]
- orf 7y agoSpeed, schemas, code generation, built in backwards compatibility, extension points, public service definitions, introspection to name a few.
- Thaxll 7y agoYou forgot real bi-directional streaming but otherwise I agree :)
- sklivvz1971 7y ago> These solutions didn’t appear out of thin air because people get bored one day. I certainly did not say these architectures appeared out of thin air. They were invented to solve the problems of internet-scale companies. > Micro services solve tangible, real world problems. Incorrect. Microservices solve tangible, real-world problems when they are applied to the correct problems. Microservices might also create tangible, real-world problems whether they are applied correctly or not. In fact, that's one of the points of the article, if you read between the lines. > gRPC isn’t necessary hard to debug, and it brings a whole host of improvements over whatever ad-hoc mess you used before. I don't know what you are referring to. If your microservices are well done, good for you. You still need to optimize the transport, which is a cost you pay only because of your choice of architecture. If you used thicker services or a monolith you would have different problems, but not that one.