3 ms·

One thing I don't like about SOA is that an error does not have a full stack trace. I know Zipkin exists but it's nowhere close to what we had in a monolithic a

by msoad 10y ago

One thing I don't like about SOA is that an error does not have a full stack trace. I know Zipkin exists but it's nowhere close to what we had in a monolithic app where you could just put a breakpoint and trace back to where exactly an error is thrown. If we can find a way of running a giant monolithic app in development and production environment without vertically scaling our machines, I would rather have that. Every bug I'm working on is like a mystery that I have to hop to many services to find what's going. I also think HTTP is the worst protocol for apps to talk to each other.

malandrew 10y ago
http://opentracing.io/ http://opentracing.io/
- slowmovintarget 10y ago
  I was thinking of a simpler "Y U no log?!?" with correlation IDs but this is much cooler.
themihai 10y ago
Depending on your requirements micro-services may be a good or a bad solution. If the communication/protocol becomes too chatty that may be a sign you are doing it wrong.
jeremiep 10y ago
How is that different from debugging a multi-threaded or networked application? In both cases barely entering the debugger changes the behavior of the system. Heck even an asynchronous program running on a single thread doesn't have full stack traces. Having worked with both monolithic and SOA apps, the later yields radically simpler architectures and from there you spend a lot less time debugging. The older I grow as a programmer, the more I dislike monoliths. I'd rather have simpler programs where entire classes of bugs are guaranteed never to happen. I have yet to see a single monolithic app without serious technical and conceptual debt. The worst thing is that back when I thought monoliths were great I had absolutely no idea things could be so much simpler. Also, HTTP/1.1 is a fantastic protocol. Its dead-simple to implement, debug, cache, send through proxies who won't understand your custom headers or body format and whatnot. It even gives you an extra layer of routing on top of TCP/IP! This is exactly what you want to build systems with.
uluyol 10y ago
What's wrong with HTTP? If you're going to build an RPC protocol, you are going to need encryption, stream multiplexing, a way to distinguish RPC methods, support for extensions (e.g. auth), and compression. Add the fact that high performance HTTP servers and clients exist in most languages, and building an RPC protocol on top of HTTP sounds pretty attractive. No wonder gRPC did exactly that.
- devonkim 10y ago
  Tons of round trip calls potentially in most RPC-style systems are one start, which Cap'n Proto addresses with its unique style of avoiding round-trips for many network transactions which can drastically reduce network chatter. Security is addressed simultaneously (but not necessarily sufficiently for many people or regulatory bodies) in Cap'n Proto at least via use of capabilities instead of building it into transport layers.
RhodesianHunter 10y ago
Any service taking requests from a client generates a UUID and passes it through to any additional services it calls. Most microservice frameworks have this functionality built in. You log to a central store such as an ELK stack or any of the great third party offerings. When you need to see the entire stack trace you search by the id.
djspoons 10y ago
Tracing and debugging-in-developer are solving different problems, though: tracing is there to help you understand issues that you can't reproduce in development. And for the record, Zipkin is only one tracing tool and is really aimed at helping you address latency issues, not errors.

by msoad 10y ago

malandrew 10y ago

http://opentracing.io/ http://opentracing.io/

slowmovintarget 10y ago
I was thinking of a simpler "Y U no log?!?" with correlation IDs but this is much cooler.

themihai 10y ago

Depending on your requirements micro-services may be a good or a bad solution. If the communication/protocol becomes too chatty that may be a sign you are doing it wrong.

jeremiep 10y ago

How is that different from debugging a multi-threaded or networked application? In both cases barely entering the debugger changes the behavior of the system. Heck even an asynchronous program running on a single thread doesn't have full stack traces. Having worked with both monolithic and SOA apps, the later yields radically simpler architectures and from there you spend a lot less time debugging. The older I grow as a programmer, the more I dislike monoliths. I'd rather have simpler programs where entire classes of bugs are guaranteed never to happen. I have yet to see a single monolithic app without serious technical and conceptual debt. The worst thing is that back when I thought monoliths were great I had absolutely no idea things could be so much simpler. Also, HTTP/1.1 is a fantastic protocol. Its dead-simple to implement, debug, cache, send through proxies who won't understand your custom headers or body format and whatnot. It even gives you an extra layer of routing on top of TCP/IP! This is exactly what you want to build systems with.

uluyol 10y ago

What's wrong with HTTP? If you're going to build an RPC protocol, you are going to need encryption, stream multiplexing, a way to distinguish RPC methods, support for extensions (e.g. auth), and compression. Add the fact that high performance HTTP servers and clients exist in most languages, and building an RPC protocol on top of HTTP sounds pretty attractive. No wonder gRPC did exactly that.

devonkim 10y ago
Tons of round trip calls potentially in most RPC-style systems are one start, which Cap'n Proto addresses with its unique style of avoiding round-trips for many network transactions which can drastically reduce network chatter. Security is addressed simultaneously (but not necessarily sufficiently for many people or regulatory bodies) in Cap'n Proto at least via use of capabilities instead of building it into transport layers.

RhodesianHunter 10y ago

Any service taking requests from a client generates a UUID and passes it through to any additional services it calls. Most microservice frameworks have this functionality built in. You log to a central store such as an ELK stack or any of the great third party offerings. When you need to see the entire stack trace you search by the id.

djspoons 10y ago

Tracing and debugging-in-developer are solving different problems, though: tracing is there to help you understand issues that you can't reproduce in development. And for the record, Zipkin is only one tracing tool and is really aimed at helping you address latency issues, not errors.