The crew at Mailgun are kinda doing this, and its been enabled by vulcan proxy:<p><a href="https://github.com/mailgun/vulcand" rel="nofollow">https://github.com/mailgun/vulcand</a><p>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:<p><a href="https://github.com/mailgun/scroll" rel="nofollow">https://github.com/mailgun/scroll</a><p>(there is a python implementation somehwere too, just can't find it)<p>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:<p><a href="http://blog.vulcanproxy.com/vulcand-news-circuit-breakers-better-metrics-and-anomaly-api/" rel="nofollow">http://blog.vulcanproxy.com/vulcand-news-circuit-breakers-be...</a><p>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.
The problem is that there's a certain essential minimum complexity to every interesting piece of software. You can't eliminate essential complexity - you can only move it around.<p>Monolithic architecture turns a configuration management problem into a coding problem. Eventually, coupling within the monolith makes it hard to develop.<p>Service-oriented architecture turns a coding problem into a configuration management problem. Eventually, the potential combinations of small services become unmanageable and untestable, making it hard to run operationally.<p>You have two kneecaps. Which one gets the bullet? Because you're gonna get kneecapped either way.
It'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?".<p>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.<p>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?<p>Also related is, of course, the Nix ecosystem: Nix package management, NixOS configuration management, NixOps provisioning, DisNix distributed services, etc.
This sounds a lot like CORBA (<a href="http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture" rel="nofollow">http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Ar...</a>).<p>The big problem with distributed classes is that network communication links are fragile and you need to bake how to deal with failures into your methodology. Erlang handles this in a way that Joe Armstrong explains here:<p><a href="http://armstrongonsoftware.blogspot.com/2008/05/road-we-didnt-go-down.html" rel="nofollow">http://armstrongonsoftware.blogspot.com/2008/05/road-we-didn...</a>
I don't get it. Is that yet another CORBA clone?<p>I think the CORBA clone currently in fashion is SOAP (or did we get something newer?). There probably are SOAP tools for Earlang, and you'll really get the possibility of using an heterogeneous system, like you said you'll want.<p>Yet, those things never work so well as people think they should. Keeping interoperability within a code-base is hard work, distributing it just makes it harder.
For 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.<p>> <i>The size of the code deployed matters</i><p>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. :-)