NanoVMs, the company behind the Nanos unikernel, writes about debugging, profiling, and running workloads like Postgres as unikernels.
HN mostly mentions it in hiring posts and in questions about how its sites (nanos.org, nanovms.com, ops.city) relate; commenters are somewhat confused.
NanoVMs | Senior Software Engineer && Kernel Engineer | ONSITE | $100k - $200k | Full-time |
https://www.nanovms.com
Ready to hack unikernel infrastructure? Unikernels are widely considered the cloud of the future and we have large paying customers utilizing them in production right now.
Politicians talk about re-building bridges and roads but no one discusses the mess of what software infrastructure is today or the fact that is largely built by systems designed over 40 years ago. It's time to fix that.
The software stack today is completely ludicrous - please help us fix it.
We need both Go Engineers && Kernel Engineers. Whether it's hacking DMA drivers or figuring out what needs to be tweak to scale more than 2000 VMs on a single server we got really nice meaty engineering problems for you to solve. We're currently a small team of highly technical engineers complemented by a highly effective sales team.
We have a large existing Go codebase along with a growing base of C/ASM. Other languages you might find in our codebase - rust/lua.
The opportunity to level up your game is extreme as we are going off the deep end on the technical front.
We are looking for really smart driven engineers - eg: ones that can take charge and code like the wind.
We have quite a few really interesting secret projects going on right now - would love to tell you more when we chat.
We are all on-site in our Townsend office in SF, CA. We currently aren't doing remote. We're customer driven…
That article seems overly critical about young developers that don't know it any better because they grew up on containers.
I guess I am one of those so I got to ask, is the proposed solution of unikernels something we had before but lost in favor of containers, or is it something completely new anyways?
It does look like it might be the latter so why blame developers for using containers due to lack of choice? If unikernels are better and just as easy to use then I am sure people will convert.
He blames a lot on marketing and marketing lies but his company (https://nanovms.com/) seems to make it just as hard to figure out what's going on with the apparently only option being a schedule a demo button.
Come on, I remember Docker being that fancy new thing that people at university taught themselves and to each other around ~2014/2015. That hype was well deserved and if you want to compete with that you can't just decide to brush it off as wrong and misguided.
At the risk of pointing out that I also might be one of those that the quote above is referring to, I gotta ask:
Is there a technical reason why I shouldn't be able to eventually just replace Docker with a micro or unikernel? Same or similar style of image definition, completely different runtime technology?
Isn't it up to the kernel and platform developers to build the tools to make that happen comfortably for all of us naive container users?
MirageOS unikernels run directly on Xen, e.g. http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/
> I replace the [QubesOS] Linux firewall VM with a MirageOS unikernel. The resulting VM uses safe (bounds-checked, type-checked) OCaml code to process network traffic, uses less than a tenth of the memory of the default FirewallVM, boots several times faster, and should be much simpler to audit or extend.
NanoVMs has OSS tools for golang unikernels on multiple hypervisors and cloud platforms, https://nanovms.com/dev/tutorials/running-go-unikernels
> Why not? Most people won't spend the time to learn OS/distro building.
I don’t know how good they are and have never used any, but there’s tooling for building the ultimate stripped down kernel, unikernels (https://en.wikipedia.org/wiki/Unikernel)
A quick Google gives me https://nanovms.com/, https://github.com/solo-io/unik and https://github.com/rumpkernel/rumprun.
A disadvantage of such a stripped down system is that debugging such a system can be difficult. For example, if there’s only one process, you can’t open a shell to look around on a misbehaving system.
This is a common myth. Debugging unikernels is indeed possible[1][2]. It may not be the type of debugging you're already used to, but then again, unikernels are very different from containers and VMs, so some adjustment is expected.
As for observability, why is that the concern of unikernels? That's something your application should do. You're free to hook it up to any observability stack you want.
[1]: https://nanovms.com/dev/tutorials/debugging-nanos-unikernels-with-gdb-and-ops
[2]: https://unikraft.org/docs/internals/debugging
I am a bit confused, there are three sites:
* https://nanos.org/ The core technology?
* https://nanovms.com/ A company providing services and offerings around said technology?
* https://ops.city/ The orchestration?
And I am not sure what "thing" I am using. Is there some disambiguation? I know is OPS is the orchestration CLI, but I am confused at the difference between Nanos and NanoVMs. What should I call the section of my README that deals with this tech? Currently gone with Nanos/OPS but I am confused.