fn VS skywalking

Not always. Check out how Oracle Cloud does it. It's a hosted version of an open source stack called fn, which you can run fully locally via a simple CLI tool.

https://fnproject.io

There's not much info out there but I'll describe what I got from reading the blog posts and searching for it.

"Serverless" stuff like the (proprietary) Lambda or (open source, https://fnproject.io/) OCI Cloud Functions are based on a few ideas:

1. Use Linux syscalls+x86 as the target ABI/ISA. Thus programs are Docker containers and because the kernel is a bit too much C to trust, maybe also custom virtual machines for sandboxing.

2. Because downloading a full blown Linux userspace and starting it up inside a new virtual machine can be slow, then add a variety of hacks on top to try and make a start/stop model look like an always on service. For example by having always-on instances (which means serverless now has servers again), by using Docker layers and other stuff.

GraalOS asks the following question: what if we toss Linux and x86 as the API? Is there a way to do server-side computing better?

This question just leads to more questions:

• What do we replace it with?

• What are the benefits?

GraalOS starts by saying, let's replace Linux/native code with the Java specifications instead. This gives you a relatively large and consistent yet open source surface area for doing all the server-side basics you need like IO, threading, memory management and so on. You can then layer Truffle (from the same team) on top to get other languages like JavaScript, Python, Ruby, WASM, Rust or C++ (via LLVM bitcode) and so on. All of these running on top of the JVM rather than Linux.

In this model the JVM isn't an operating system, exactly, but it might as well be because you don't have access to the underlying kernel at all. There's no way to make system calls in this model that aren't mediated by the standard libraries of your language. And this is enforced via two very different sandboxing technologies:

1. The server controls the compiler.

2. Intel MPX and whatever the AMD equivalent is.

Controlling the compiler is how you implement software level sandboxing. Because all code running on the CPU is created by your own compiler which the developer cannot choose (like in a browser), you can implement and impose whatever policies you like. The most obvious is no syscalls, no unsafe memory accesses and so on. But then you may want more than that, for example, how do you stop Spectre attacks extracting secrets from the address space? To which the answer can be the CPU's "Memory Protection Keys". This is a very, very fast and lightweight way to do a kind of in-process context switch. You can associate page ranges with a "key" and then put that key into a special register to control what memory ranges are currently accessible. It's like an additional set of permissions over what the kernel has set up. Because you control the compiler, you can ensure that only system code can alter the current memory protection key, and then this lets you compile and execute untrusted code without worrying about speculation attacks.

So that's the theory, what's the benefits?

The first benefit is that you don't need containers anymore. GraalVM has the "native image" tool that produces native Linux standalone executables from JVM apps, like Go does. And those JVM apps can be interpreters or JIT compilers for other Truffle languages as well. So now, you no longer need to drag around half an Ubuntu install for each app you run. It means programs can be moved between servers way faster because there's less to copy, and anyway Oracle Cloud has notoriously excellent networking, from what I've read, so new instances can be spun up much faster than before. And native images start ~instantly because they are fully native code and have a persisted heap snapshot computed as part of the build process, so they effectively start already initialized. And then finally in some cases they can do snapshotting post-startup too, for fast suspend/resume, and the compiler knows how to do MPX keys.

So with all this done, you can produce a server side infrastructure in which programs are just shared libraries loaded and unloaded into pre-warmed HTTP servers, yet still isolated and protected from each other, and because things are way faster you can actually just start and stop these servers genuinely on demand on a per-request basis. There's no need to charge users for idle minutes as you try to avoid a shutdown/startup cycle. In turn that means a lot of complexity just boils away.

BTW, I just checked and it turns out that Oracle's "free cloud" deal applies to functions as well. You get like 2 million free activations a month or something, and 400k "gigabyte memory-seconds". So if that pricing is sustained with this then it means a lot of types of JVM servers will just be completely free to host, because native image also reduces memory consumption a lot.

At least that's my guess as to what's going on. But it's not launched yet, just announced. I guess we'll have to see what it's like for real when it's available.

Functions: Scalable, multi-tenant serverless functions based on Fn

OpenFAAS or FN Project are options

Install fn (refer to https://fnproject.io/ for latest instructions)

I disagree, microservices are an architectural concept related to the software, not to the infrastructure.

Whether you are using containers or VPS or serverless or bare metal for your infrastructure, that's completely unrelated to the concept of microservices: you can deploy either a monolith or microservices in any of the above.

As an example you can deploy a monolith on Lambda[1] or you can deploy microservices on bare metal using one of the several self managed serverless engines available[2].

[1] see e.g. https://claudiajs.com/tutorials/serverless-express.html or https://blog.logrocket.com/zappa-and-aws-lambda-for-serverle...

[2] see e.g. https://fnproject.io/ and https://knative.dev/

Still, for today I would like to talk to you about the FN project, an open-source alternative.

When choosing distributed tracing tools, considerations include your technology stack, business requirements, and monitoring complexity. Zipkin, SkyWalking, and OpenTelemetry are popular distributed tracing solutions, each with its unique features.

Apache SkyWalking is an APM tool, focusing on microservices, Cloud Native apps, and Kuernetes architectures. It builds its architecture on four kinds of components:

Trying to play devil's advocate here.

> It needs at least a stable set of users, but maintaining a set of users is essentially managing the set of people onboarding and the set of people migrating off.

I could say that I don't care very much about how much users a piece of software has, only that it has enough information on how to use it and enough maintainers to patch any security vulnerabilities and do occasional releases with updated dependencies, as well as address any serious issues or bugs.

For example, Apache Skywalking is an APM solution that most people haven't even heard of (in contrast to something like Sentry), yet it fits those qualities and I see few to no issues with it: https://skywalking.apache.org/

> If you're shrinking then a competitor is providing better options, or your problem space has shifted.

Again, as a user, I might not care that Sentry or another piece of software is better in any number of ways than Apache Skywalking. Similarly, I might not care that something like PostgreSQL is more correct or has a large market share (at least on HN) in comparison to something like MariaDB/MySQL.

If a piece of software meets the needs of my project and won't effectively rot with time, then it's quite possibly good enough as it is, even if it's not the market leader. For my small project's APM needs Apache Skywalking is enough. For my CRUD database needs, something like MariaDB/MySQL will be okay until the time Sun burns out (or PostgreSQL if I'm feeling fancy, but even that's not one of the modern and hip solutions).

Ergo, those better options only become relevant once they're closer to being must haves than nice to haves. Same as how Docker Swarm might be enough for many, even if Kubernetes basically won in the "container wars" and has a way more active community. Swarm will only stop being an option for me once it hits EOL, at least for certain projects where simplicity is appreciated.

Then again, a counterpoint to my own argument here could be the story of LibreOffice and OpenOffice, where the latter was basically donated (instead of the rights to the name being given to the folks behind LibreOffice) and is now in decline while LibreOffice is flourishing - but at the same time they were so close to one another feature wise, that maybe it's not a good point, same as with Gogs and Gitea.

> Where's Java primarily used these days?

I've seen a lot of enterprise-y webdev projects use it for back end stuff (Dropwizard, Spring Boot, Vert.X, Quarkus) and in rare cases even front end (like Vaadin or JSF/PrimeFaces). The IDEs are pretty great, especially the ones by JetBrains, the tooling is pretty mature and boring, the performance is really good (memory usage aside) and the language itself is... okay.

Curiously, I wanted to run my own server for OIDC/OAuth2 authn/authz and to have common features like registration, password resets and social login available to me out of the box, for which I chose Keycloak: https://www.keycloak.org/

Surprise surprise, it's running Java under the hood. I wanted to integrate some of my services with their admin API, seems like the Java library is also updated pretty frequently: https://mvnrepository.com/artifact/org.keycloak/keycloak-adm... whereas ones I found for .NET feel like they're stagnating more: https://www.nuget.org/packages?q=keycloak (probably not a dealbreaker, though)

Then, I wanted to run an APM stack with Apache Skywalking (simpler to self-host than Sentry), which also turns out to be a Java app under the hood: https://skywalking.apache.org/

Also you occasionally see like bank auth libraries or e-signing libraries be offered in Java as well first and foremost, at least in my country (maybe PHP sometimes): https://www.eparaksts.lv/en/for_developers/Java_libraries and their app for getting certificates from the government issued eID cards also runs off of Java.

So while Java isn't exactly "hot" tech, it's used all over the place: even in some game engines, like jMonkeyEngine, or in infrastructure code where something like Go might actually be more comfortable to use.

> What should people use?

I recall Apache Skywalking being pretty good, especially for smaller/medium scale projects: https://skywalking.apache.org/

The architecture is simple, the performance is adequate, it doesn't make you spend days configuring it and it even supports various different data stores: https://skywalking.apache.org/docs/main/v9.0.0/en/setup/back...

The problems with it are that it isn't super popular (although has agents for most popular stacks), the docs could be slightly better and I recall them also working on a new UI so there is a little bit of churn: https://skywalking.apache.org/downloads/

Still better versus some of the other options when you need something that just works instead of spending a lot of time configuring something (even when that something might be superior in regards to the features): https://github.com/getsentry/self-hosted/blob/master/docker-...

Sentry is just the first thing that comes to mind (OpenTelemetry also isn't simpler due to how much it tries to do), but compare its complexity to Skywalking: https://github.com/apache/skywalking/blob/master/docker/dock...

I wish there was more self-hosted software like that out there, enough to address certain concerns in a simple way on day 1 and leave branching out to more complex options like OpenTelemetry once you have a separate team for that and the cash is rolling in.

Personally I've also used Apache Skywalking for a decent out of the box experience: https://skywalking.apache.org/

I've also heard good things about Sentry, though if you need to self-host it, then there's a bit of complexity to deal with: https://sentry.io/welcome/