17 ms·

Am I the only one getting a bit fatigued by all of this now? I think when we hit containers I just got a bit tired of going even further down the rabbit hole. Y

• n0us 11y ago
  I'm thinking that for my smallish deployment setup I'm just going to do things the tried and true way for a while until the practices surrounding containers stabilize a bit and I don't feel like I would be playing catchup every week. The amount of time I would have to spend setting this stuff up is huge compared to the benefit. It's all still fascinating though to keep up with from an observer's standpoint.
• woah 11y ago
  Seems pretty weird that we think it's normal to run a computer that simulates several physical computers, each running an operating system built for the mainframe in a 70s university CS department closet that then only ever runs one user and one application. You just think it's easier because you're used to it. I'm glad that this development is happening. In a few years when it's mature, we'll all have a saner setup to work with.
  • hueving 11y ago
    >In a few years when it's mature, we'll all have a saner setup to work with. I'm happy you get to work in an environment with no legacy applications that require a specific old operating system but that's not the case for a massive portion of sysadmin jobs.
    • kbenson 11y ago
      From a recent post, here's a talk[1] about containers where they use SmartOS (Solaris/IllumOS derivative) to containerize Linux by just implementing the syscall table. The future of hosting legacy apps might be providing legacy interfaces on modern OS's (IMO). 1: https://www.youtube.com/watch?v=coFIEH3vXPw https://www.youtube.com/watch?v=coFIEH3vXPw
    • moonchrome 11y ago
      Well the legacy app is a solved problem - we have VMs - let them live there and be done with it. Expose the API trough network and call it from anything you want.
  • kozukumi 11y ago
    Yeah I certainly see the contradiction(?) in things. That is the world we live in though. I think the biggest issue is with the tools we use to manage things. Looking at things as "a computer" with storage/network/cpu seen as one unit is pretty natural now as it has always been that way pretty much.
  • nickpsecurity 11y ago
    Especially given there were more effective and efficient systems designed back in the 70's for doing exactly what we're doing now. Just better. ;)
    • pjmlp 11y ago
      And written in safer systems programming languages! :)
      • nickpsecurity 11y ago
        With one being on same PDP-11 as UNIX and more portable. The more I learn, the more I want to give modern computing stacks the Double Middle Finger. :)
  • fulafel 11y ago
    University CS dept people in the 70s probably thought the same thing at the time, having witnessed IBM get into it in the late 60s.
• detaro 11y ago
  Nobody is stopping you from using VMs instead of containers. I bet most deployments aren't using containers. And unikernels are very much experimental and research right now, especially since they aren't made to easily package an existing application. Containers, VMs and Unikernels all have different characteristics and philosophies, if one fits all your needs there is no need to make it more complicated by introducing another type. But if you need something specific, they are there.
• alextgordon 11y ago
  I don't think containers are related to unikernels. The whole point of containers is to sacrifice a bit of performance in order to gain convenience. Whereas for unikernels, it's the opposite > Unikernels leverage the advantages of virtualisation to create an operating system that's as specialised and optimised as possible. It makes no sense to craft a hyper efficient kernel and then run Ruby on it. If your requirements are such that Linux is too slow, you are probably an HFT. Or Google.
  • mahyarm 11y ago
    Or if you want to remove a potential layer of security issues.
    • alextgordon 11y ago
      I am exceptionally sceptical that "specialised" and "secure" are anything but opposites. "One hundred novel implementations of /dev/random" is a security nightmare. What you want is one implementation of /dev/random that everybody uses. Like uh, Linux. Same goes for every other element of the kernel. A secure kernel does not come from using (I'm sorry to say) a hipster programming language, it comes from decades of abuse that is thrown at mainstream kernels.
      • mahyarm 11y ago
        It wouldn't be 100 implementations of /dev/random, but one implementation per language. Security with a C / C++ based system that has to be everything to everyone is pretty much intractable. If you have a java unikernel server for example, you only have one programming language which you can understand from top to bottom with a lot of well written open source libraries. Then you have a hypervisor, from what I understand can be far simpler than the linux kernel, POSIX and everything else. You only have two smaller layers to understand, versus the huge unix ecosystem stack to understand. Also changing something inside your unikernel stack would be a git commit & deploy away. Patching a kernel vulnerability which you probably don't understand is a significantly longer undertaking.
• joseph 11y ago
  In time there will probably be mature build tools to compile unikernels from application sources. Instead of running maven or gradle to output a jar, you'll output a unikernel VM image. Containers complicate things because they add an extra layer onto a host OS. With unikernels there will be a layer removed, the host OS itself. You'll still need tools to manage and orchestrate the VMs running the unikernels, but I think things will get simpler, not more complicated.
• crb 11y ago
  My simplified version: A container is a way of sharing the resources of a kernel, with some resource isolation. A unikernel is a way of sharing the resources of a hypervisor. There are pros and cons to each: a container lets you run other things on the same kernel, and introspect the running process (as well as do interception of things like sysdig does.) However, root-on-container generally means root-on-all-containers. So we use VMs to host containers in. x86 is much smaller in terms of instruction set to a Linux kernel, there are historically fewer vulnerabilities, many fewer LoC, etc. The unikernel compiles your OS and libs together, meaning you can share a hypervisor - which is good for security. You lose some of the convenience of management of containers in order to get this.
  • amirmc 11y ago
    > "You lose some of the convenience of management of containers in order to get this." Not necessarily... http://unikernel.org/blog/2015/unikernels-meet-docker/ http://unikernel.org/blog/2015/unikernels-meet-docker/
    • crb 11y ago
      You lose the ability to monitor by introspection: all you know is "this VM is using X CPU and X RAM", you can't look into what it's doing inside the VM. It's the same as a VM without an agent, today. This can be considered a security win and a usability loss.
  • musha68k 11y ago
    Does the xen hypervisor offer same-page merging? I believe kvm as well as lxc/cgroups do, at least to some extent and in their own idiosyncratic ways. From the point of view of a former sysadmin and current "private cloud" enthusiast that's a crucial question that likely leads to intricate discussions on security as well.
• dwc 11y ago
  I pretty much stay away from all this stuff, but I keep a keen eye on it. The whole virtualization space is pretty interesting (potentially), but it seems like people aren't too clear about the different use cases. Rather, they promote whatever bit of tech they learned as The Solution, even though VMs, docker, unikernels, et al obviously have different characteristics.
• erikpukinskis 11y ago
  There's a huge spike of value created when you cross the threshold of "you really don't need to think about sysadmin stuff, you can just focus on the application layer." Heroku was the first to cross it, and they do a bang-up job with Rails apps, but ever since it came out there has been this sort of question hanging in the air of "how does this generalize?" A VM on something like Amazon EC2 was the best we could do at that time. It certainly generalizes, but you have to do quite a lot of sysadmin work to keep an app running healthily. Docker was an improvement on that, taking away some underlying system work. But then losing the security benefits of VMs and still, in the end, requiring a bunch of systemsy stuff. Of course Heroku kept firing with its buildpacks supporting lots of platforms and a host of infrastructure provided as a service. But that doesn't really provide all of the control application developers need. You're sort of at the mercy of what infrastructure there's a market for, at market prices. So what's happening is both sides are sort of pressing in to the middle... On the docker side trying to build general-purpose containers that can run on a shared foundation of rock solid system images, and on the IaaS side trying to do as much as possible over a network connection. We will eventually meet in the middle, with a set of secure, well-defined interfaces between an application and the infrastructure it relies on, which is robust enough to handle the vast majority of software. Then again, if you squint your eyes that's kind of what we already have. We're just slowly decreasing the surface area of those interfaces and increasing their security. What you're feeling is the pain of that surface area being still pretty big and the job of surveying daunting. Luckily you don't need to map the whole thing, just know enough to make good decisions this week. And honestly, I think for most people, focusing on how to build more human-relevant software is going to be way more helpful to your career than learning about the successor to Docker. But that's just some unsolicited career advice. :)
  • rodgerd 11y ago
    > There's a huge spike of value created when you cross the threshold of "you really don't need to think about sysadmin stuff, you can just focus on the application layer." Right up until you discover that availability and data integrity and security are still problems, as you discover when it turns out your understanding of Amazon's AZs is faulty and your business goes offline.
• amirmc 11y ago
  Depends on where you imagine the work to be. I tend to think of unikernels as having to 'front-load' more of the work. That's why you can treat the end artefact as almost disposable. With a traditional stack, it may be easier to set up, but you're then committing to acting as caretaker for the code that runs on that machine, inc. patches, upgrades, version constraints, etc. There's probably more work there over the long term. This is kind of where the distinction of 'cattle vs pets' comes from.
• andrewstuart2 11y ago
  You're very likely not alone, but this is just a symptom of an underlying truth that in engineering, there are always trade-offs. Even with fundamentals like sort algorithms or hash tables, the best implementations for general cases may not be the best choice for some individual cases (mostly-sorted inputs, for example). Quicksort and universal hash tables use randomization to avoid problems that arise with pathological sets of data, and so their performance can only be given on average. If even simple CS primitives have such trade offs, then those are certainly going to propagate up the complexity tree as we engineer solutions on top of them. In general, it's probably best to just know that these things exist and what their strengths and weaknesses are (they will almost certainly always have both) so that you can pick the right tools for the job at hand.
• derefr 11y ago
  Unikernels are about security by auditability, mostly. Where containers have all of the security problems of two layers of operating systems and a container daemon and a complete OS kernel (before you even get to a hypervisor), unikernels are just your app and the drivers it needs sitting on the hypervisor. Or even on bare metal. It's a fairly different philosophy—I don't think anyone really cares about the performance aspect of it (those people care more about getting zero-copy low-level IO in userland while still reaping the "control-plane" benefits of having an OS, using e.g. Snabb Switch.) It's more like the philosophy behind Erlang releases or black-box "appliance" VMs. Which is, basically, that you don't maintain "the OS" as a thing separate from your app; you just maintain "your app", and any bits of OS are basically part of the vendored deps of each successive app release.
  • pjmlp 11y ago
    If one looks at how many OSes evolved in the early days of computing history, there was always an overlap between rich language runtimes and the OS. The language runtime and libraries built on top of it were the OS. Seen by this lenses, POSIX could be seen as the C runtime, if one would stretch this example. So for me, it is quite natural that when one has languages with rich runtimes, the OS is just another layer that can be taken out and we can go back to the days when runtimes were mostly targeting bare-metal.
• hvidgaard 11y ago
  I can certainly see a lot of benefits with this. We host for some of our customers, and this would allow us to isolate each customer completely from each other. That is worth a lot when they store sensetive data in the application. Seperate VMs would as well, but it's not really feasible to run a full Windows Server for each customer.