
New View of Microservices - nikolenkoanton
https://github.com/lsm/micromono
======
muhmi
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](http://elixir-lang.org) [2]
[http://www.phoenixframework.org](http://www.phoenixframework.org)

~~~
muhmi
[http://blog.plataformatec.com.br/2015/06/elixir-in-times-
of-...](http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-
microservices/)

~~~
logicchains
Question: on a scale of Go to Haskell, how long on average does it take for
devs only familiar with a couple of imperative languages (e.g. two of Python,
C, Java or Ruby) to learn Elixir to the point that they can be productive with
it?

~~~
ardemchenkov
Sorry, I'm not a person to whom this question was addressed. But in our
company we had 3 developers coming from PHP and Python world. They learned
basics in 1-2 days and started to commit in production repository. Then in 1-3
weeks they learned it much deeper. But in our case it was easier because we
already had high traffic and there were a lot of production examples to learn.

~~~
nailer
Do they ever have to use an Erlang lib and find the documentation harder
because they're Elixir programmers?

I love the Elixir syntax but worry it'd be like Scala: a better way for people
who already know Java, rather than a way to use BEAM / OTP etc for people used
to modern languages.

~~~
rossj
Most of my time I write Python, but I'm trying to spend more time with Elixir,
and I haven't found using Erlang libs that hard.

There are a handful of rules to remember, if that, and it's reasonably
straight-forward. module:func becomes :module.func, the erlang func probably
wants char lists rather than strings, atoms are lower-case and should be
changed to :atom, vars are upper case and should probably be lowered.

Learning the Elixir language is easy, thinking functionally less so (for me at
least).

------
hartror
> 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...](https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture#Problems_and_criticism)

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

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

~~~
gbog
> A monolithic system executing a given function is pretty much guaranteed to
> be simpler than a distributed system doing the same function.

And what about a monolithic system executing thousands of different functions?

If your app is a simple todo list, sure, go monolithic (but you should still
delegate storage to some other tool). If it is much more complex than a todo
list, then it is very likely that you have many packages containing many
modules developped and maintained by many programmers. And if one glitch on
one side of the monolith affects a remote module and functionalities depending
on it, or even breaks down the whole monolith, then you should go
microservices. Or split your code base. Or do whatever is needed so the thing
can still move forwards, if slowly, without breaking apart at each little
step.

~~~
aikah
> If it is much more complex than a todo list,

See , that's the problem with you people advocating micro-services , RIGHT
HERE. Your statement is ridiculous and make it hard for people like me to take
micro service advocates seriously.

~~~
gbog
I'm sorry, I do not understand why you find this statement ridiculous (I'm not
native English-speaker). Would you mind explaining a bit?

~~~
kasey_junk
Because we have decades of examples of monolithic apps more complicated than a
to do list, but very little time with micro services.

If you honestly believe you can't write robust & scalable monoliths _at all_ ,
that is an extreme position that is hard to square with many peoples
experience.

------
Kiro
OT but can someone give me an example of some microservices in a normal
application? I'm really stuck in the mindset of doing everything as a monolith
and have a hard time imagining how I could split things up in microservices.

~~~
brightball
Not to self promote, but I provided some examples in a blog post for Codeship
a month ago.

[https://blog.codeship.com/exploring-microservices-
architectu...](https://blog.codeship.com/exploring-microservices-architecture-
on-heroku/)

~~~
durzagott
Great blog post, thanks for sharing.

------
_Marak_
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](http://hook.io) uses this approach see:
[http://echo.hook.io/source](http://echo.hook.io/source)
[https://github.com/bigcompany/hook.io](https://github.com/bigcompany/hook.io)

------
mands
Great work - looks really cool, esp for ppl using the Node stack. Really
excited by the progress in the space, with products like this, JAWS
([https://github.com/jaws-stack/JAWS](https://github.com/jaws-stack/JAWS)),
hook.io and more.

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

------
ac360
Nice work, have my github star!

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.

[https://github.com/jaws-stack/JAWS](https://github.com/jaws-stack/JAWS)

------
hurrycoward
Non-distributed Microservices?

[http://fmontesi.blogspot.com/2015/06/non-distributed-
microse...](http://fmontesi.blogspot.com/2015/06/non-distributed-
microservices.html)

------
nbevans
Nobody said micro services are meant "distributed" in the first place.

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

~~~
lsm
There's a naive zmq RPC adapter here:
[https://github.com/lsm/micromono/blob/master/lib/rpc/zmq.js](https://github.com/lsm/micromono/blob/master/lib/rpc/zmq.js)

Very buggy especially when clients disconnect/reconnect. But, it's good
starting point if you are interested.

