New View of Microservices • Hacker News Board

Re: New View of Microservices

#21

Post by ardemchenkov » Wed, Sep 02, 2015, 8:08 AM UTC

logicchains wrote: post #16

muhmi wrote: post #9

Earlier quoted context omitted.

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

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?

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.

Re: New View of Microservices

#22

Post by aikah » Wed, Sep 02, 2015, 8:56 AM UTC

gbog wrote: post #17

iofj wrote: post #10

Earlier quoted context omitted.

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 part…

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

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

Re: New View of Microservices

#23

Post by nailer » Wed, Sep 02, 2015, 9:24 AM UTC

ardemchenkov wrote: post #21

logicchains wrote: post #16

Earlier quoted context omitted.

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?

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.

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.

Re: New View of Microservices

#24

Post by hliyan » Wed, Sep 02, 2015, 9:27 AM UTC

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

I don't think the failure of one (or even two) implementations invalidates the concept itself. I see nothing fundamentally wrong with the idea of location transparency (where it matters)

Re: New View of Microservices

#25

Post by gbog » Wed, Sep 02, 2015, 10:14 AM UTC

aikah wrote: post #22

gbog wrote: post #17

Earlier quoted context omitted.

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

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

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?

Re: New View of Microservices

#26

Post by rossj » Wed, Sep 02, 2015, 11:00 AM UTC

nailer wrote: post #23

ardemchenkov wrote: post #21

Earlier quoted context omitted.

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.

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.

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

Re: New View of Microservices

#27

Post by ardemchenkov » Wed, Sep 02, 2015, 11:30 AM UTC

nailer wrote: post #23

ardemchenkov wrote: post #21

Earlier quoted context omitted.

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.

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.

I don't remember that it was harder actually. We were using Mochiweb (was replaced by Cowboy at some point in time), Chicago Boss and some other additional Erlang libs and people switched from it to Elixir and other way around.

Agree with rossj, there're some rules to remember and then it's not that hard.

Re: New View of Microservices

#28

Post by jschulenklopper » Wed, Sep 02, 2015, 12:01 PM UTC

Kiro wrote: post #18

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.

Really depends on your domain, but reading up on "bounded contexts" and "domain-driven design" will help you in determining which microservices might be named and designed in your area. For example in online retail, seperate microservices for Customers, Products (catalog), Product reviews and Orders might be a feasible distribution of responsibility, functionality and data.

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.

Re: New View of Microservices

#29

Post by muhmi » Wed, Sep 02, 2015, 1:06 PM UTC

logicchains wrote: post #16

muhmi wrote: post #9

Earlier quoted context omitted.

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

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?

Hi

We haven't measured the actual time. I would say the time learning Elixir has not been a hurdle or anyway limiting factor to the projects we are working on.

We basically switched as a company from writing servers in C#/nodejs/python to just Elixir. Did this gradually during end of last year and this spring.

Though I must mention that all of our developers were already familiar with multiple languages. And since we have multiple projects going on we can transfer knowledge easily. So YMMV.

Re: New View of Microservices

#30

Post by kasey_junk » Wed, Sep 02, 2015, 1:15 PM UTC

gbog wrote: post #25

aikah wrote: post #22

Earlier quoted context omitted.

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

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?

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.