[beat]

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 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.

[tekacs]

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/

[beat]

You add a layer of complexity to try to manage the complexity. Which works, but it ain't a free lunch.

[tekacs]

Yes, absolutely. Much in the same way that web frameworks do this. :)

The complexity is handed off to the framework authors/community and (web) development is revolutionised for everyone else.

[agallego]

Good thoughts. I didn't talk about our operational complexity, but we are definitely working on both ends.

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.