People need to debug their application. If you need to convince people that this is a myth, you need to tell people how to debug and inspect their application and system.
If anything your own response here is like the typical politician- avoiding the issue, providing anecdotes that promotes your view, going on the offense and changing the subject.
Err.. today's remote debugging is strongly based on the premises of the issues being isolated to some degree: broken app will not hit the network stack over which you run you remote session, misbehaving network stack doesn't impact serial communication, so using gdbserver is still possible (but already significantly harder), etc.
I don't see why not, it is a matter of what the runtime allows and debugging tools.
When I talk to JEE servers via JMX I don't care if they run on as OS process, on a container, hypervisor or even a bare-metal JVM.
Likewise I get to enjoy cluster monitoring tools like Visual VM, Java Mission Control, New Relic APM, DataDog and many others, all blissful unaware of how the JEE server are actually deployed.
So I don't see why unikernels can't provide debugging access points for such kind of tooling.
> When I talk to JEE servers via JMX I don't care if they run on as OS process, on a container, hypervisor or even a bare-metal JVM.
But I think the whole point on the thread was that, making all this possible on unikernels, would require putting back a big part of the code that went away when making the unikernel lean and mean (and interesting because of that).
That is what people that favor an UNIX userland advocate.
An optional debug layer for JVM, Erlang, CLR running bare-metal (just as possible language examples) is tailored made for such runtimes and much thinner than all the services a general purpose OS needs to provide.
I'm not saying applications don't need to be debugged, that would be silly. What I am saying is that this "Unikernels are hard to debug" is a hand wavey way of knocking down the technology, and it has really worked - witness this subthread.
The unikernel is the final build, the package, the output of application development and debugging which happens upstream, before you put it into the package.
There's always ways you can expose the inner workings of a unikernel to gain insight into whatever might be going wrong for whatever reason - if you really need to do it at the stage that it is a running unikernel - but in most cases its just not necessary because application development and debugging happens, as I say, upstream of the final building of the thing into a unikernel.
This likely means that you work on systems whose needs are very different from the average needs.
Applications absolutely need to be debugged in production, debugging does not only happen upstream before deployments. Unexpected things happen so you might need to list the current TCP connections, view the socket buffer sizes, produce a core dump, view metrics you didn't anticipate at development - even attach a debugger directly on a very bad day. (Please don't get hung up on these specific examples though - the point is more that the last decades have allowed us great system introspection into a production environment running on a traditional OS).
The perfect world where all that would be unnecessary for most people is not even close yet. People are largely not yet willing to give up on being able to ssh into their server and use the available tools to do troubleshooting
, nor are they willing to change the development practice where that could largely be avoided.
Would love to see that guy parsing HTTP pages using some sort of manual software stack in python.
Exceptions? Could be raised at any level. Most of the time you can't predict at all which exceptions can happen.
Server-side errors? Could happen at any level. DNS switch/your provider forgot to restart DNS/Server out of RAM/...
Now try to do something along these lines at 1M requests/day. I mean, requests to several API providers who are probably not even providing good docs for their APIs.
There's no way you can have a scaled-up IT business without online debugging. Most of the time I spend on is debugging issues that I could absolutely not predict (or realistically, I could only predict them if my budget was a multiple of what it was) when I was writing the program.
Real-life problems are based on sets of contradicting requirements. And they are contradicting due to them being at the edge of our understanding; and that's why they are problems.
I'm a little confused. Are you arguing that unikernels are unfit for debugging or just that debugging is necessary in production? I agree with the latter but not the former.
I believe the objection is clearly about debugging in production, not during development. This is absolutely essential if you want to be able to fix things in production that broke unexpectedly long after development/deployment.
Yeah, it's really strange that he's not addressing this, since the unikernel answer is relatively straight forward--you just compile in the debugging abilities (e.g., a protected endpoint that lets you inspect the application dynamically). That said, I don't know of any unikernels that support this.
I agree with this point, it seems most people don't get the fact that most of the debugging is happening in the development phase (before building an unikernel) and when you need to debug in production I think that's certainly not as difficult as it seems.
There's no issue with logging through network as opposed to logging to a file that you need to pull to see the contents (containers).
It's also common to have a debugging interface over network that you can use to inspect program state (eg. Clojure nREPL, node.js inspector protocol, and this can be built into any environment), I'm pretty sure even Rust can have networked REPL that can satisfy most debugging needs.
If anything your own response here is like the typical politician- avoiding the issue, providing anecdotes that promotes your view, going on the offense and changing the subject.