![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
liam_on_linuxIf you write code to target a particular OS in a compiled language that is linked against local OS libraries and needs to talk to particular hardware via particular drivers, then that code is going to be quite specific to the OS it was designed upon and will be difficult to port to another OS. Indeed it might end up tied to one specific version of one specific distro.
Notably, the lowest-level of high-level languages, C.
If, OTOH, you write an app that runs in an interpreted language, that never runs outside the sandbox of the interpreter, which makes a request to get its config from a defined service on another machine, stores its working data on another such machine, and emits its results across the network to another machine, all within one set of, say, Ruby modules, then you don't need to care so much.
This is, vastly reduced and simplified, called the microservices "design pattern".
It is how most modern apps are built — either for the public WWW, or VPNs, or "intranets" not that that word is used any more as everyone has one now. You split it up into chunks as small as possible, because small "Agile" teams can work on each chunk. You farm the chunks out onto VMs, because then, if you do well and have a load spike, you can start more VMs and scale to much much larger workloads.
From Twitter to Instagram, the modern Web is built like this. Instagram, for instance, was built by a team of 3 people, originally in pure Python. They did not own a single server. They deployed not one OS instance. Nothing. EVERYTHING was "in the cloud" running on temporary rented VMs on Amazon EC2.
After 1 year they had 14 million users.
This service sold for a billion dollars.
http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html
These aren't toy technologies. They're not little prototypes or occasional research projects.
So if you break your architecture down into little fungible boxes, and you don't manually create any of the boxes, you just create new instances in a remote datacenter with automated tools, then…
Firstly, some of the infrastructure that hosts those boxes could be exchanged if it delivered major benefits and the users would never even know.
Secondly, if a slight change to the internal makeup of some of the boxes delivered major improvements — e.g. by using massively less memory, or starting quicker — it would be worth changing the box makeup to save money and improve performance. That is what is driving migration to containers. Rather than lots of Linux hosts with lots of VMs holding more Linux instances, you have a single host with a single kernel and lots of containers, and you save 1GB RAM per instance or something. That adds up very quickly.
So, thirdly, if such relatively modest efficiencies drive big cost savings or performance improvements, then perhaps if you could replace those of your VMs with other ones that run a small set of (probably quite big & complex) Python scripts, say, with a different OS that can run those scripts quicker in a tenth of the RAM, it might be worth some re-tooling.
That's speculative but it's far from impossible.
There is much more to life than compiled languages. A lot of production software today — countless millions of lines — never goes near a compiler. It's written in interpreted "scripting" languages, or ones that run in VMs, or it just calls on off-the-shelf code on other systems which is a vanilla app, straight out of a repo, that just has some config applied.
Some of my English students here are training up to be developers. #1 language of choice: JavaScript. #2: Java. C? Historical curiosity. C++ a
more recent curiosity.
If one had, for instance, some totally-un-Unix-like OS with a working JVM, or with a working Python interpreter — CPython for compatibility - that
would run a lot of off-the-shelf code for a lot of people.
Old time Unix or Windows hands, when they hear "develop a new app", think of reaching for a compiler or an IDE.
The millennials don't. They start looking for modules of existing code that they can use, stitched together with some Python or Ruby.
No, $NewOS will not replace all uses of Windows or Unix. Don't be silly. But lots of companies aren't running any workloads at all on bare metal any more: it's all in VMs, and what those VMs are hosted on is a matter of convenience or personal preference of the sysadmins. Lots of that is now starting to move to containers instead, because they're smaller and faster to start and stop. Apps are structured as micro services across farms of VMs and are moving to farms of containers instead.
A container can be 10x smaller than a VM and start 100x faster. That's enough to drive adoption.
Well if you can host that container on an OS that's 10x smaller and starts 100x faster, that too might be enough to drive adoption.
You don't need to know how to configure and provision it so long as you can script it with a few lines in an Ansible playbook or a small Puppet file. If the OS has almost no local config because it's only able to run inside a standardised VM, how much setup and config does it need anyway?
Notably, the lowest-level of high-level languages, C.
If, OTOH, you write an app that runs in an interpreted language, that never runs outside the sandbox of the interpreter, which makes a request to get its config from a defined service on another machine, stores its working data on another such machine, and emits its results across the network to another machine, all within one set of, say, Ruby modules, then you don't need to care so much.
This is, vastly reduced and simplified, called the microservices "design pattern".
It is how most modern apps are built — either for the public WWW, or VPNs, or "intranets" not that that word is used any more as everyone has one now. You split it up into chunks as small as possible, because small "Agile" teams can work on each chunk. You farm the chunks out onto VMs, because then, if you do well and have a load spike, you can start more VMs and scale to much much larger workloads.
From Twitter to Instagram, the modern Web is built like this. Instagram, for instance, was built by a team of 3 people, originally in pure Python. They did not own a single server. They deployed not one OS instance. Nothing. EVERYTHING was "in the cloud" running on temporary rented VMs on Amazon EC2.
After 1 year they had 14 million users.
This service sold for a billion dollars.
http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html
These aren't toy technologies. They're not little prototypes or occasional research projects.
So if you break your architecture down into little fungible boxes, and you don't manually create any of the boxes, you just create new instances in a remote datacenter with automated tools, then…
Firstly, some of the infrastructure that hosts those boxes could be exchanged if it delivered major benefits and the users would never even know.
Secondly, if a slight change to the internal makeup of some of the boxes delivered major improvements — e.g. by using massively less memory, or starting quicker — it would be worth changing the box makeup to save money and improve performance. That is what is driving migration to containers. Rather than lots of Linux hosts with lots of VMs holding more Linux instances, you have a single host with a single kernel and lots of containers, and you save 1GB RAM per instance or something. That adds up very quickly.
So, thirdly, if such relatively modest efficiencies drive big cost savings or performance improvements, then perhaps if you could replace those of your VMs with other ones that run a small set of (probably quite big & complex) Python scripts, say, with a different OS that can run those scripts quicker in a tenth of the RAM, it might be worth some re-tooling.
That's speculative but it's far from impossible.
There is much more to life than compiled languages. A lot of production software today — countless millions of lines — never goes near a compiler. It's written in interpreted "scripting" languages, or ones that run in VMs, or it just calls on off-the-shelf code on other systems which is a vanilla app, straight out of a repo, that just has some config applied.
Some of my English students here are training up to be developers. #1 language of choice: JavaScript. #2: Java. C? Historical curiosity. C++ a
more recent curiosity.
If one had, for instance, some totally-un-Unix-like OS with a working JVM, or with a working Python interpreter — CPython for compatibility - that
would run a lot of off-the-shelf code for a lot of people.
Old time Unix or Windows hands, when they hear "develop a new app", think of reaching for a compiler or an IDE.
The millennials don't. They start looking for modules of existing code that they can use, stitched together with some Python or Ruby.
No, $NewOS will not replace all uses of Windows or Unix. Don't be silly. But lots of companies aren't running any workloads at all on bare metal any more: it's all in VMs, and what those VMs are hosted on is a matter of convenience or personal preference of the sysadmins. Lots of that is now starting to move to containers instead, because they're smaller and faster to start and stop. Apps are structured as micro services across farms of VMs and are moving to farms of containers instead.
A container can be 10x smaller than a VM and start 100x faster. That's enough to drive adoption.
Well if you can host that container on an OS that's 10x smaller and starts 100x faster, that too might be enough to drive adoption.
You don't need to know how to configure and provision it so long as you can script it with a few lines in an Ansible playbook or a small Puppet file. If the OS has almost no local config because it's only able to run inside a standardised VM, how much setup and config does it need anyway?
