Infrastructure as code
alexgallego.org
Infrastructure as code
1–10 of 23 posts
Re: Infrastructure as code
#2It's a nice line of thought, but I think there's a lot of existing work that's should be investigated. Essentially, it seems like another "wouldn't it be nice if everything were written in $LANG, even the OS?".
Erlang is mentioned as an example, since its VM certainly offers many features we'd like from an OS. Maybe comparisons to Smalltalk, LISP machines and even regular UNIX shells should be offered.
It's likely that all this has been done before, and I'm tempted to think that its major problems would stem from having too much power in the config language. For example, I'd imagine you could do this with SysV init's runlevels and shell scripts, but it would be pretty horrible. What would make the language du jour any less horrible?
Also related is, of course, the Nix ecosystem: Nix package management, NixOS configuration management, NixOps provisioning, DisNix distributed services, etc.
Re: Infrastructure as code
#3It's a nice line of thought, but I think there's a lot of existing work that's should be investigated. Essentially, it seems like another "wouldn't it be nice if everything were written in $LANG, even the OS?". Erlang is mentioned as an example, since its VM certainly offers many features we'd like from an OS. Maybe comparisons to Smalltalk, LISP machines and even regular UNIX shells should be offered. It's likely th…
> Essentially, it seems like another "wouldn't it be nice if everything were written in $LANG, even the OS?".
In all honesty, I'm not sure you read the article. The entire point is the idea to deploy tiny chunks of code, independently, in any language.
Re: Infrastructure as code
#4For this I would go with some J2EE or clustered framework. Erlang is nice, but is outdated and does not handle clustering that well. It is about migrating clients and threads, while multiple versions of the same library exist within system.
> The size of the code deployed matters
And I disagree with this. The hardest deployment I ever seen was 2KB of code. Sim toolkit is impossible to modify once it is flashed into 2 million SIM cards. :-)
Re: Infrastructure as code
#5The crew at Mailgun are kinda doing this, and its been enabled by vulcan proxy:
https://github.com/mailgun/vulcand
At first, sure, Vulcand is just another reverse proxy, but what they have been doing is registering individual HTTP handlers with the proxy -- into etcd:
https://github.com/mailgun/scroll
(there is a python implementation somehwere too, just can't find it)
What's neat about exposing these individual HTTP handlers, is now your reverse proxy can produce metrics, apply circuit breakers, etc, all in a central way, but your "micro" service just has to register with etcd:
http://blog.vulcanproxy.com/vulcand-news-circuit-breakers-be...
So, you end up with an architectural style where you can deploy a single HTTP handler as its own service, similar to what the article was pointing to, but in a multi-lanaguage approach, where HTTP is the communication method.
Re: Infrastructure as code
#6Sounds like you're looking for a distributed actor framework like AKKA
Re: Infrastructure as code
#7The crew at Mailgun are kinda doing this, and its been enabled by vulcan proxy: https://github.com/mailgun/vulcand At first, sure, Vulcand is just another reverse proxy, but what they have been doing is registering individual HTTP handlers with the proxy -- into etcd: https://github.com/mailgun/scroll (there is a python implementation somehwere too, just can't find it) What's neat about exposing these individual HTTP…
Very similar :)
We do use a proxy/router. The main difference is that instead of using etcd for service discovery we are deeply integrated with Mesos.
Our framework scheduler does the registration/deregistration, resource allocation/colocation, etc.
The main reason for a proxy at this point is to have unified metrics collection, distributed routing (each reverse proxy knows only its immediately connected downstream operators), tracing (think dapper), and facilitating the communication with other languages (c++, java, go, js - node, ruby, etc).
Re: Infrastructure as code
#8Sounds like you're looking for a distributed actor framework like AKKA
I would agree that on the surface the problem does seem to be solved by an actor framework.
The issue and main point is that I want that cross language, cross platform with isolation, tracing and debugging hooks.
Re: Infrastructure as code
#9For this I would go with some J2EE or clustered framework. Erlang is nice, but is outdated and does not handle clustering that well. It is about migrating clients and threads, while multiple versions of the same library exist within system. > The size of the code deployed matters And I disagree with this. The hardest deployment I ever seen was 2KB of code. Sim toolkit is impossible to modify once it is flashed into 2…
In what sense does Erlang not handle clustering well? It's true that you wouldn't run a "native" (ie EPMD-based) cluster of hundreds of nodes, but what would stop you from implementing a clustering architecture you'd build with, say, J2EE in Erlang?
Re: Infrastructure as code
#10For this I would go with some J2EE or clustered framework. Erlang is nice, but is outdated and does not handle clustering that well. It is about migrating clients and threads, while multiple versions of the same library exist within system. > The size of the code deployed matters And I disagree with this. The hardest deployment I ever seen was 2KB of code. Sim toolkit is impossible to modify once it is flashed into 2…
Erlang is nice, but is outdated and does not handle clustering that well.
Erlang's distribution was always designed for redundancy and fault tolerance first, thus features like location transparency and heartbeats across nodes. There is no inherent service discovery mechanism built in (tools not solutions), and I suppose large topologies could benefit from third-party process registries.
I'd hardly call it "outdated", just that its default mechanisms for organization are a little different.