>>3) support for linking an arbitrary file system image into the binary

>>"3" is, AFAICT, useful only when you can't have a block device.  What are 
>>such cases?  I know Andrew used it for platform bootstrap, but adding an 
>>entire mechanism to support a small phase in platform bringup is out of the 
>>question.

>>How do you justify "2" and "3", and how do you plan to fix "4"?

Caveat, all this is subjective opinion of course, presented as fact, happy to 
have my points argued or my technical assumptions corrected. My initial 
expectation and thinking when approaching the topic of rump/unikernels in 
general is that 3 would be the primary use case. I only later gave much thought 
to attaching block storage. 

The baked in file system is at the core of realising the full promise of rump 
and similar unikernel technologies.

I use “self contained kernels” to refer to kernels where a read only file 
system has been baked in.

*****************Self contained kernels are easier to configure and deploy than 
those requiring block storage
It is vastly easier not to have to deal with block storage. A standlone kernel 
that can run without any dependencies is appealing because it is easy to start 
and stop and you need never give any thought to what is on the external file 
system, what files are required to be present on the external file system, 
versioning, backups, security of the external file system. 

*****************Self contained kernels are easier to manage without block 
storage
Managing running applications without file system dependencies is very easy. If 
you have the kernel, you can run it, end of story. With file system 
dependencies you must immediately answer a long series of questions before you 
can run and manage the application. With self contained kernels, if you have it 
you can run it.  This alone solves much of the ridiculous complexity in 
managing computing environments.

*****************Self contained kernels are more reliable
Block storage devices are a relatively fragile component of a system and might 
fail for a variety of reasons.

*****************Self contained kernels are more scalable
Creating 1,000 self contained kernels is easier than creating 1,000 kernels 
that require block storage.

*****************Self contained kernels can contain entire application 
ecosystems
A standlone kernel with a file system built in is able to include entire 
application ecosystems, for example Python with the interpreter, libraries and 
application source code can all live in the same self contained kernel.  Same 
for any other language such as PHP, Ruby, Java, whatever. Self contained 
kernels overcome all the fragility and brittleness when an application is 
deployed onto an external file system. Consider any web application for 
example, it needs just a few dozen or a handful of files and the ability to 
talk over the network to other database/REST API’s. PHP, Python, Java, Ruby web 
servers could contain all the needed files and talk over a network to the 
database. Nginx for example, it’s easily possibly to configure quite alot of 
application code in with it and run it standlone with no block storage. 

*****************Self contained kernels solve some of the resource intensive 
complexity inherent in testing and versioning
Testing of applications is often complex due to the brittle nature of the many 
components that go to make up and application. Creating and recreating 
application environments to a known state is a resource intensive process.  
Self contained kernels with no block storage dependency are easy to manage and 
version.  Testing against a known application state becomes easy and 
predictable because the entire application is one simple file, just run it.  
Just push each version of your self contained kernel into version control.

*****************Self contained kernels make the entire application ecosystem 
verifiable.
A self contained kernel ecosystem could have a hash that identifies that unique 
combination of application ecosystem components, useful for verifying 
authenticity.

*****************Self contained kernels are more secure
It is harder for security of an application to be compromised where there is no 
read/write file system.

*****************Self contained kernels are immutable and form ther basis of 
the concept of “”immutable infrastructure”.
Stand alone kernels are immutable and form the basis of the concept of 
“immutable infrastructure” 
https://www.google.com.au/search?q=immutable+infrastructure&oq=immutable+infrastructure
 Kernels with block storage are mutable.

*****************Developers will work to the strengths and weakness of the self 
contained kernel.
Some applications will of course absolutely require read/write external file 
systems. Many application developers and architects however will design their 
applications to avoid the requirement for block storage, to gain all the listed 
benefits of stand alone kernels.
 
*****************Self contained kernels will enable new, as yet unthought of 
paradigms for software execution
kernels that have no block storage dependencies might be used in ways that 
might be hard to anticipate right now, but their self contained nature and lack 
of block storage dependency means they could be effectively configuration-free 
can be moved around and launched in places and ways that are not traditionally 
though of at the moment.  Right now people think of a server application 
attached to a heavy, in-place server instance and things don’t change too much. 
 The self contained, kernel without external dependencies could change that 
formula.

In terms of blue sky possibilities, I was having some vague, not entirely 
formed ideas the other night about chaining kernels whereby for example the 
first kernel sets up its environment, attaches block storage devices, 
configures the network for example then chain boots the next kernel.  Perhaps 
there are applications in which multiple chains of kernels can run in parallel 
to get a task done.  That’s all going to work a whole lot more smoothly if they 
can package in some files into a self contained unit.

*****************Self contained kernels appear to be a good entry point for 
learning and understanding
It sounds trivial but I think it’s important that the entry point to this field 
for many people is to make a standlone website, typically a blog or something.

*****************Summary.
I’m hoping for an effective implementation for baked in read only file system 
to be able to do the above stuff.







Reply via email to