New View of Microservices

hartror wrote: post #2

> The most critical thing is being able to use any services locally or remotely without knowing the difference or changing the code. I thought we all agreed CORBA style location transparency was a bad idea? https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

That was my 1st reaction too ... but hold on. If you design the 2 components to be non-chatty and have robust error handling, then it can be safe to make it location transparent.

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.

Re: New View of Microservices

#5

Post by ddoscampaign » Wed, Sep 02, 2015, 5:47 AM UTC

Hopefully, they'll do rpc adapters for zmq and rabbitmq.

Re: New View of Microservices

#6

Post by ddoscampaign » Wed, Sep 02, 2015, 5:53 AM UTC

charlieflowers wrote: post #4

hartror wrote: post #2

> The most critical thing is being able to use any services locally or remotely without knowing the difference or changing the code. I thought we all agreed CORBA style location transparency was a bad idea? https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

That was my 1st reaction too ... but hold on. If you design the 2 components to be non-chatty and have robust error handling, then it can be safe to make it location transparent. 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.

Top-down configuration (as opposed to discovery like UDDI) via something like zookeeper or dns solves this problem. And APIs shouldn't do WSDL either, the code and docs should document the API. It's possible to add so many over-engineered layers of YAGNI flexibility that almost no one can understand what the heck is going on or how to hack on it, e.g., Eclipse plugins.

Keep it really simple, until it breaks too often.

Re: New View of Microservices

#7

Post by _Marak_ » Wed, Sep 02, 2015, 5:59 AM UTC

I've found the best design for creating microservices is to limit the service to one exported method ( the service handler ) and one URL path.

http://hook.io uses this approach see: http://echo.hook.io/source https://github.com/bigcompany/hook.io

Re: New View of Microservices

#8

Post by muhmi » Wed, Sep 02, 2015, 6:03 AM UTC

Have a look at Erlang and OTP framework which makes it really easy to compose your application of smaller applications. At least for learning.

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

Re: New View of Microservices

#9

Post by muhmi » Wed, Sep 02, 2015, 6:08 AM UTC

muhmi wrote: post #8

Have a look at Erlang and OTP framework which makes it really easy to compose your application of smaller applications. At least for learning. 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.phoenixframewor…

http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...

Re: New View of Microservices

#10

Post by iofj » Wed, Sep 02, 2015, 6:44 AM UTC

charlieflowers wrote: post #4

hartror wrote: post #2

> The most critical thing is being able to use any services locally or remotely without knowing the difference or changing the code. I thought we all agreed CORBA style location transparency was a bad idea? https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

That was my 1st reaction too ... but hold on. If you design the 2 components to be non-chatty and have robust error handling, then it can be safe to make it location transparent. 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.

It still has all the other disadvantages of remote services, like consistency problems (everybody always assumes that RPC calls are as reliable as 2 phase commit, and they're not), more and more complex code that's harder to change, less flexibility on all fronts except for the one, ...

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.