Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New View of Microservices

github.com

Post reply on HN
Print view View original

11–20 of 41 posts

Re: New View of Microservices

#11

Post by lsm »

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.

Yes, you got the idea. We focus on providing developer the "ability to switch or mix between microservice and monolithic styles" so people get flexibility they need for different circumstances (e.g. development vs deployment vs testing).

Re: New View of Microservices

#13

Post by lsm »

ddoscampaign wrote: post #6
charlieflowers wrote: post #4

Earlier quoted context omitted.

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…

Really good suggestion for the API doc. I admit that writing documentation is much harder than code;)

Re: New View of Microservices

#14

Post by lsm »

iofj wrote: post #10
charlieflowers wrote: post #4

Earlier quoted context omitted.

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

I agree, the consistency problems should be handled inside each individual services and the layer before all the services should be as simple as normal balancer.

Re: New View of Microservices

#15

Post by roel_v »

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.

People could (and did) design robust CORBA and (D)COM objects, but the overhead was too high in some (many?) cases. Overhead in development time, but also run time. If I can pass a const pointer to a bunch of data (if I know the consumer will live in the same memory space), then that's way faster (in development and run speed) than having to marshal that data into a common byte-order and alignment etc., most likely requiring copying, keeping track of who changed what when, ...

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!

Re: New View of Microservices

#16

Post by logicchains »

muhmi wrote: post #9
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-...

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?

Re: New View of Microservices

#17

Post by gbog »

iofj wrote: post #10
charlieflowers wrote: post #4

Earlier quoted context omitted.

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

Re: New View of Microservices

#18

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

Re: New View of Microservices

#20

Post by ardemchenkov »

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…

Great idea, Erlang is very good for such tasks. Native communication between nodes, very high availability and fault tolerance (native as well) using "actor model"[1] and good performance. As an example, in one of my previous companies we built a message broker, which was able to keep 35K keep-alive connections on Amazon Medium EC2 instance and there still were reserves in CPU and Memory.

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

Post reply on HN