480 karma · joined February 15, 2013
Many of those bells and whistles are near-necessary in the enterprise world, but you have the accumulated mass of 'red zones' and developmental landmines in that ecosystem that can quickly turn you off it as a whole if you want to understand the whole system.
Thankfully, IPV6 can help mitigate this problem by extending the fragment id length from 16 to 32 bits. This gets you up to roughly 1.18 trillion bytes of 'safe' NFS traffic/second. There's plenty of reasons why IPv6 adoption is still fragmentary, but if you're running a high throughput network, this is certainly a motivator to move at least part of it to IPv6.
If you can make one that thinks in terms of git on the backend, great.
If you want to go a bit further, you could expose the underlying operations to the user. You will need to get them to reason around and interact with the minimal requirements inherent to a versioning system, namely explicit versioning and an explicit commit process, along with explicit merging and conflict resolution.
There are GUI clients that help with some of this, but you're not going to get away from some concept of dealing with branches and merges in any SCM. You hear about it less often, but you'd have the same troubles dealing with a chewed up repository in Perforce, ClearCase, or the like.
(edit: even Subversion!)
That said, running a refinery also has local costs that are usually externalized, in terms of local pollution and populace movement. Canada itself though has a fairly large amount of space, but perhaps a surfeit of people. Why doesn't TC energy (or other Canada producers) build a refinery somewhere in Canada and transport to there?
Granted, most of those are out of scope for cloud development, but the concept of externally cutting off a VM is different than even calling whatever power service you have to cut power. In the 'real' world, enough of those failure triggers above would probably also trigger an automated power cycle if you're in a managed environment.
You might be able to glean sources like court records for evidence of things like corporate data sources used at trial, or perhaps other secondary sources. Finding and compiling that data is much less straightforward than that which is manadated, at least in theory, to be in the public record.
The EFF has always been aimed at the government anyway, and its taken decades of pressure to reveal what it does. A different organisation is probably necessary to dedicate itself to corporate overreach.
Ansible is not as 'data-structure' oriented, so testing that is more difficult, but each element (modules, libraries, roles, playbooks) can be written to be fairly environment-neutral, which you could then use a test a fixture like BATS to easily check for regressions.
To answer your 'type-checking' expectation, its generally on the developer to implement those tests. In my experience, its rare that those are implemented in publicly available devops libraries, even though we have most of the tools to do so. It's definitely an area where the practice can improve.
When your target is a system image thats rebuilt entirely from source you can get away with the latter somewhat more easily, but its definitely no panacea. Just look at OpenSSL. (libmemcache is another personal 'favorite' of mine.)
Individually developers will be more expensive, but if you have a product that demands maximum leverage of concurrency (i.e. data-heavy api, whatever-in-the-middle services, multiparty real-time data), you will more than makeup the developer premium when you get to that point.
I havent hit Elixir yet, but it seems to make access to the Erlang runtime much easier. As far as SDKs/api, Erlang itself has primitives and libraries to build useful access to most APIs you can find. If you're worrying about what services you can access though, you probably don't need Erlang's features, at least not yet.