Communication between nodes is transparent on the language level, its all message passing between processes.
There is a approachable language with great tooling on top of the Erlang VM [1] and a great web framework [2].
[1] http://elixir-lang.org [2] http://www.phoenixframework.org
Plus it's easier to learn it than it seems first time when you see it. Most of our Erlang-developers came from other languages, but they learned basics very quick: 1-2 days until the first commit on production.
The only one thing, it's not so easy to debug it in the beginning. But it's a question of practice, I think.
[1] http://learnyousomeerlang.com/introduction#what-is-erlang
I thought we all agreed CORBA style location transparency was a bad idea?
https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
In other words, the problem in the past was, we designed it as if it would be used locally, then we naively made it remote. But now, we're talking about designing it for remote use, but then using it locally.
Interesting.
Things like distribution are a tradeoff, an optimization : you should never split a monolithic application into 2 communicating parts until you have good reason to do so.
A monolithic system executing a given function is pretty much guaranteed to be simpler than a distributed system doing the same function.
A small amount of microservices is easier on the guy doing ops work for the system, because they can be individually replaced, upgraded or changed (IF the developers put in the constant amounts of efforts needed to make that possible. Every release should be able to deal with past versions of everything it talks to). These guys are also usually the ones doing load balancing and the like, so bonus points for being able to spread them over the network.
Of course, numbers of microservices always grow, and grow, and grow some more. Soon it's not easier anymore on the ops guy, and becomes a constant drag on progress for everyone.
Keep it really simple, until it breaks too often.
Now that I have my old fogey hat on anyway, I might as well state the 'old wine in new bags' feeling I get with articles like this. Encapsulation and separation of concerns is good you say? But inconvenient because there is overhead? So infrastructure to manage dependencies and deployment of sets of loosely coupled components is useful? Whodathoughtthat!
Didn't Vonnegut have a line about how it affects you to see the same mistakes repeat over and over?
Note that there's always a catch in going from a monolithic application to one with a more distributed nature. Distribution of data requires data synchronization and results in integration challenges, because of the unreliability and higher latency of networks.
Lastly, Martin Fowler c.s. wrote some nice articles on microservices: http://martinfowler.com/tags/microservices.html. That will help as well.
https://blog.codeship.com/exploring-microservices-architectu...
* Front end: Perhaps a basic Node.js or Rails app. It's UI only; all data handling is done through APIs to the backends.
* Admin: Completely separate app. Same here, UI only.
* Post backend. This is a data store for articles. It has APIs for creating, updating, deleting articles. It also has a permission system that connects users to the groups that they are part of. This could be a separate microservice, but it's natural to keep it close to the data (also for performance reasons, since every post lookup needs to check if the calling user is allowed to see it).
* Login backend. This has a user database and can do things like accept logins via other services such as Google and Twitter, via OAuth.
* Miscellaneus support services. For example, say you want to support upload images: Make it a microservice that calls into ImageMagick and stores stuff in S3. Or let's say you want to support importing WordPress exports (WXR archives). Make it a service that parses and uploads asynchronously to the post backend.
I have built this as a monolith, and as a microservice system. The microservice platform is much more flexible and clean.
It also allows us to reuse every part for other apps — and this is in my mind the number one benefit that microservices gives you. We've had several new projects completely unrelated to what we've built before, and we have simply reused the microservices we had already created, only swapping out the new front end.
Making reusable microservices is an interesting challenge, since core concepts (things like users and data objects) need to be generalized, and mechanisms built in so that you can make specific features that don't burden the microservices with too many conflicting concerns. For example, let's say that your CMS's public site wants users to be able to "like" individual articles. Instead of building this into the article store, create a microservice which abstracts the concept of "liking". Or let's say you want users to sign up for a newsletter version of the site that sends them a digest every week; again, don't build it in, but make a microservice that abstracts this into "subscriptions", with a registry of emails and what users are subscribing to, and so on. To generate well-formatted emails, simply let the front end provide an API for rendering templates, which this "subscription" microservice can invoke to do the actual rendering. Generalizing it this way makes it easy to then create new types of subscriptions, such as SMS messaging.
Another important point is that every microservice has to be multitenant; a single microservice can host multiple unrelated datasets, and they need to be partitioned in a way that allows the APIs to not comingle the data by accident. It's not rocket science, but it takes some planning and practice to make the APIs feel natural.
http://hook.io uses this approach see: http://echo.hook.io/source https://github.com/bigcompany/hook.io
At StackHut (www.stackhut.com) we're working on something similar, a micro-services based system that's provides a scalable, typed, JSON interface into JS/Python classes wrapped up in containers.
Can't wait to see where this microservices-based path ends up...
People interested in this should also check out JAWS: The Server-Less Framework Powered By AWS Lambda.
JAWS V1 is coming out in a few weeks and it is insanely awesome.
http://fmontesi.blogspot.com/2015/06/non-distributed-microse...
Very buggy especially when clients disconnect/reconnect. But, it's good starting point if you are interested.
