I'm working in an environment where we need to manage drive space, memory utilization, and processor efficiency. Just because computer gear seems inexpensive, when looked at scale, all those pennies add up. I am starting to encounter more and more discussions on what other's do for keeping their systems in check.
There are a number of ideas which, when linked together, produce a sum greater than the parts: Immutable Infrastructure and Unikernels.
For the company I work for, our IaaS management systems consist of a good number of virtual guests running specialized, individualized functions. Something akin to the adage of 'one service per server'. Even though security and flexibility contribute to the list of 'strong points', it has certain drawbacks: every server has the full operating system and all the associated trappings: logging, file systems, and many many unused packages, which are loaded by default.
Along comes docker, which makes use of the LXC approach one kernel, but protected run time environments, which reduces the footprint somewhat. But there still is the high over head of unused packages coming along for the ride.
Unikernels provide a DevOps pattern of getting your application as close to the metal as possible and reducing the overhead of unnecessary packages and drivers. This makes more efficient use of drive space, memory space, and processor utilization. Some call this design pattern Cloud Operating Systems.
Once you have these lightweight 'functional objects' available, you can start them and stop them as needed. If you need them changed, you don't change something in the object, you simply create a new one and replace the old one. This actually is extremely beneficial. Rather than undoing a change gone wrong, you roll back a change to the previous version of an object. This provides an inherent degree of versioning in a production environment. And allows for gradual roll-outs, rather than fork-lift style rebuilds.
Unikernels and Immutable Infrastructure written by Darren Rush goes into Unikernels and Immutable Intrastructure in more depth. At the end of the article, more links to more related columns. One of which lands at Florian Motlik's article of
Why you should build an Immutable Infrastructure, which expands on those same concepts, provides more links, one of which shines the spotlight on a different definition of the same subject: Disposable Components.
It is easy to get side tracked into further refinements of the same subject, namely Network Function Virtualization. At a past Usenix conference, there was a talk on
ClickOS and the Art of Network Function Virtualization, a Unikernel of sorts, based upon Xen and a custom network path, which makes 'network middleboxes' more efficient and flexible. Network middle boxes being things like firewalls, intrusion detection systems, shaping, inspection, monitoring, .... all running in various series/parallel designs.