tylerflint

Java is supported, but currently in the pro version. Since JavaSSL is implemented in Java code, which runs in the Java VM and not exported as static symbols that can be uprobe'd, there is a bit more involved to generate a bridge between the JVM bytecode and static symbols that can be probed.

Great idea!

On an unrelated note, your work has inspired most of my career in Solaris/Illumos/Linux systems and honestly this project likely wouldn't have happened if it wasn't for all of your books/blogs/projects to help me along the way. Thank you!

The short answer is that we only have to calculate the offset per go version, no expensive runtime scanning is required.

The long answer is that the offsets are the byte alignment offsets for the go structs containing the pointers to the file descriptor and buffers. Fortunately we only have to calculate these for each version where the TLS structs within go actually change, so not even for every version. For instance, if a field is added, removed, or changes type then the location in memory where those pointers will be found changes. We can then calculate the actual offset at runtime where we know which architecture (amd64, arm64, etc) with a simple calculation. Within the eBPF probe, when the function is called, it uses pointer arithmetic to extract the location of the file descriptor and buffer directly.

The main benefit is complete coverage. In production systems there are many different workloads with many different binaries, each with different build processes. Leveraging eBPF enables seeing everything on a system without having to adjust the build pipeline.

Just run the qtap agent on whatever Linux machine has apps running on it and it will see everything through the kernel vs eBPF.

You can customize config and/or integrate with existing observability pipelines, but initially you just need to turn it on for it to work. No app instrumentation required.

We have Go support, but it is not open sourced yet. Go is a bit more complicated but we were able to get it after some cave diving in the ELF formats. To give you a little insight on how this works, because Go is statically linked, we need to pull several different offsets of the functions we are going to hook into.

We do this by scanning every version of Go that is released to find offsets in the standard library that won't change. Then when we detect a new Go process, we use an ELF scanner to find some function offsets and hook into those with uprobes. Using both of these, we have all the information we need to see Go pre-encryption content as well as attribute it to connections and processes.

Great point! Yes it supports both scenarios. Qtap scans the binary ELF (curl, rust, etc) and looks for the TLS symbols. If they were statically compiled the eBPF probes will be attached directly to the binary, if dynamically linked the probes will be attached to the symbols in the library (.so).

That's the highest requested feature! Should be available in Q1 of 2018.

fixing now. Thanks for the heads up

Some of those aren't PaaS, but container orchestration frameworks.

If you're reading this list of comparisons out of genuine interest, I would suggest also looking into Nanobox: https://nanobox.io

I don't mean to be controversial here, but I really don't think so. If you're a quality engineer, you should stay away from Magento at all cost. I recently tried to download M2 and take it for a spin. It's very apparent they haven't learned. As an example, Magento still requires flock as a form of application-level locking (ie: the locking semantics of the application depend on a file-system behavior that is often unavailable on network filesystems). The filesystem must be writable for Magento to work at all. The engineering team completely ignores the realities of running Magento on a multi-node setup, or in a cloud environment. Not that a 12-factor app is the end-all specification, but it seems like the engineering team doesn't even understand the challenges of running in a cloud environment at all. This is very discouraging to me. In the beginning, I had very high hopes for Magento and I devoted thousands of hours and dozens of modules back to the community. Sad.

Nanobox supports many languages. We are particularly excited about elixir though!

Nanobox is free for developers to use for personal and open source projects.

I think you're right. Thanks for the advice!

NFS will be the default adapter for nanobox, but can be disabled.

This is an issue we just became aware of. Working on a fix as we speak.

Thanks for the feedback. You might want to keep any eye on Nanobox Cloud (https://nanobox.io/cloud/).

Thanks for the heads up! Please keep in mind this is an open-source project in the pre-beta phase. Any contributions are welcomed!

Yes, nanobox will try to auto-configure your environment for you. If you would rather define your environment or if nanobox can't auto-configure your environment, you can either:

1- Explicitly define your app's environment with the Boxfile (https://docs.nanobox.io/getting-started/boxfile/)

2- Write your own engine that will actually setup the environment (https://desktop.nanobox.io/engine-dev/).

You're right, not every scenario can be handled automatically. For that reason, the Boxfile is king: https://docs.nanobox.io/getting-started/boxfile/

I couldn't agree more. We literally just introduced the nanopack cloud-initiative on friday (https://blog.nanobox.io/nanopack-a-new-vision-for-automated-...). Bear with us, we'll get there!

Everything that mist does is "right in erlang's wheelhouse". Erlang is awesome and the actual reason we moved golang had nothing to do with erlang vs golang. I responded to that in detail at another spot on this thread (currently above, but who knows if that is still the case).

That's a pretty accurate assessment. Mist could be conceptualized as a self-hosted replacement for pusher (https://pusher.com/). It's designed specifically to address building realtime web apps.

The actual reason is much less exciting than you might have hoped and actually has nothing to do with erlang vs golang...

The erlang version has been running successfully for about 2 years and we haven't had any issues whatsoever (excepting a wrestling match with mnesia early on). We are erlang/elixir advocates and have used the erlang vm successfully on highly critical multi-million-concurrency services for over 6 years.

When we set out to build nanobox desktop (https://desktop.nanobox.io) our vision was to provide a single pre-compiled executable that could be run without any configuration. The design required a push layer and needed the same functionality that the erlang project was already providing. It wasn't feasible to package the erlang application into the nanobox binary, so we emulated the original project into a consumable golang package. As time went on we were porting more and more of the features into the golang port until all that was lacking was distribution and authentication. At that point we made the decision to consolidate our efforts into a single project, that could be a standalone service or composed within a golang binary.

I regret to inform you that there isn't a mass exodus within our company to ditch erlang for golang. While that certainly would make for a fun thread, in this case it was simply a matter of fit and effort consolidation.

Yeah we hear ya. The nanopack cloud-initiative was just announced last friday (https://blog.nanobox.io/nanopack-a-new-vision-for-automated-...). We're getting there slowly but surely!