11–20 of 23 posts
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:
http://armstrongonsoftware.blogspot.com/2008/05/road-we-didn...
This sounds a lot like CORBA ( http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Ar... ). 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: http://armstrongonsoftware.blogspot.com/2008/05/road-we-didn...
The point would be for an external system to handle communication.
I agree with what Joe says in that article.
Monolithic architecture turns a configuration management problem into a coding problem. Eventually, coupling within the monolith makes it hard to develop.
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.
You have two kneecaps. Which one gets the bullet? Because you're gonna get kneecapped either way.
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.
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.
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. Monolithic architecture turns a configuration management problem into a coding problem. Eventually, coupling within the monolith makes it hard to develop. Service-oriented architecture turns a coding problem into a configuration management p…
This way, you get most-every benefit of SOA whilst being able to reason about an application as a whole.
That's the approach we're taking with our microservices framework, wym: http://wym.io/
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. Monolithic architecture turns a configuration management problem into a coding problem. Eventually, coupling within the monolith makes it hard to develop. Service-oriented architecture turns a coding problem into a configuration management p…
Unless you have a framework sitting over the lot, defining that some set of (service, interface, version) tuples collectively makes up an 'application'. This way, you get most-every benefit of SOA whilst being able to reason about an application as a whole. That's the approach we're taking with our microservices framework, wym: http://wym.io/
Earlier quoted context omitted.
Unless you have a framework sitting over the lot, defining that some set of (service, interface, version) tuples collectively makes up an 'application'. This way, you get most-every benefit of SOA whilst being able to reason about an application as a whole. That's the approach we're taking with our microservices framework, wym: http://wym.io/
You add a layer of complexity to try to manage the complexity. Which works, but it ain't a free lunch.
The complexity is handed off to the framework authors/community and (web) development is revolutionised for everyone else.
This sounds a lot like CORBA ( http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Ar... ). 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: http://armstrongonsoftware.blogspot.com/2008/05/road-we-didn...
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. Monolithic architecture turns a configuration management problem into a coding problem. Eventually, coupling within the monolith makes it hard to develop. Service-oriented architecture turns a coding problem into a configuration management p…
The gist behind it is that we use Mesos/Yarn to handle the complexity of deploying and running things in a cluster. We - the framework - expose an API similar to that of map reduce and a set of CLI programs that allow you to submit 'work'. The complexity that we bring is that of mesos or yarn but if you already have it installed then is 0.
Right now we only support Mesos.
I don't get it. Is that yet another CORBA clone? 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. Yet, those things never work so well as people think they should. Keeping interoperability within a code-base is hard work, distributing it ju…
Happy to explain what you don't get. Definitely not a CORBA clone.