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

Adopting Microservices at Netflix: Lessons for Architectural Design

nginx.com

Post reply on HN
Print view View original

71–76 of 76 posts

Re: Adopting Microservices at Netflix: Lessons for Architectural Design

#71

Post by lil_cain »

danudey wrote: post #28
davidkellis wrote: post #8

Earlier quoted context omitted.

But what about the situation where you have an entity service that owns the data for one piece of the domain, for example a People service, and then other services, like the Address service and the Billing service, reference a particular person. In that scenario, I can imagine the Address service and the Billing service would have a foreign key referencing a person in the People service. Then, what happens if the Per…

The People service can also store Addresses. Call it the Identity service. Include People, Businesses, Relationships, and Addresses. The Billing service can then reference People or Businesses (and if Businesses, then sub-People), bill to an Address, etc. No one's saying every object should be a service; you need to find the correct lines to divide across. In our system (which has been service-oriented for five years…

Do you have EU customers? And if so, how do you deal with data protection?

Re: Adopting Microservices at Netflix: Lessons for Architectural Design

#72

Post by Xorlev »

threeseed wrote: post #56
Xorlev wrote: post #53

Earlier quoted context omitted.

That assumes the network is always good and services are up. Welcome back to eventual consistency (or none at all)

If the network is bad then your monolithic app wouldn't work either. The problem of services being up/down has been solved with service discovery e.g. Consul, Etcd, Zookeeper.

What @saryant said.

In addition, the network isn't just up or down. It's varying shades (dare I say, 50 shades?) of down or broken. A single machine might not be accessible due to a switch issue. An entire rack or aisle might be compromised by a bad router or faulty routing table. A network cable might be flaky. The truth is you just don't know, and that's all inside a single LAN.

Your service discovery system could be able to see service {A,B,C}, but service A can't talk to B or C due to network issues. It happens.

http://www.rgoarchitects.com/Files/fallacies.pdf

Re: Adopting Microservices at Netflix: Lessons for Architectural Design

#73

Post by chiph »

mercurial wrote: post #40
chiph wrote: post #35

Earlier quoted context omitted.

You could have a service bus, where you publish a "PersonDeleted" message that the other services would subscribe to. It decouples the Person service from all the other related entity services. You'd have to allow for propagation delay. Plus the possibility of a message storm if you delete something fairly fundamental.

> You could have a service bus, where you publish a "PersonDeleted" message that the other services would subscribe to. It decouples the Person service from all the other related entity services. You're still screwed if you complete a transaction on the deleted person's still-existing account, now that your system is no longer transactional...

Yeah, if you're an ACID person, this approach is going to present conceptual challenges. The propagation delay is a mostly-solved problem, which I know because lots of high-scale sites work. Getting a summary of their design decisions around this would be a huge time-saver, but I don't know of one.

Re: Adopting Microservices at Netflix: Lessons for Architectural Design

#74

Post by jacques_chester »

alxndr wrote: post #62
jacques_chester wrote: post #33

Earlier quoted context omitted.

The problem is that microservices are not objects. They leak reality into your problem domain in a way that simply cannot be made to go away. If regular object oriented programming languages had method calls that randomly failed, were delayed, sent multiple copies of a response, changed how they behaved without warning, sent half-formed responses ... then yes it would be the same. Distributed systems are hard, becaus…

One of the things I've heard about Erlang is that its processes can be distributed very easily. The paper you cite was written four years before Erlang was open-sourced; I wonder if Erlang/OTP would hold up to their analysis.

If you look, one of three strategies they examine is "treat all calls as remote", which is the approach taken in Erlang.

Re: Adopting Microservices at Netflix: Lessons for Architectural Design

#75

Post by doktorn »

cam- wrote: post #60
polynomeal wrote: post #57

My team recently added a microservice to support our fairly monolythic backend service. The big challenge we found was that it takes a lot of effort to make a new (micro)service. We need to create a system of alarms (instead of relying on existing catch all defaults). We need its own test environment, we need to find ways to send traffic to pre-prod. We needed to figure out how to bootstrap the new service into the c…

Front End teams tend not like micro services, there is too much overhead in getting too little data. As an example we integrate with one micro service where get back a boolean and and a date. We have the overhead of an http call and all the error handling that goes with it for two pieces of data which would be better aggregated into another service. We story point an integration with a new service as an 8, but adding…

It is by no means a new fashion. In an interview from 2006, Werner Vogels (CTO & VP of Amazon) talks about it. http://queue.acm.org/detail.cfm?id=1142065

Re: Adopting Microservices at Netflix: Lessons for Architectural Design

#76

Post by vampirechicken »

davidkellis wrote: post #8
shanemhansen wrote: post #7

Earlier quoted context omitted.

Ideally you don't have to sync the data because one service owns that data. Other services request that data via api. In a RESTful world those api requests are cacheable.

But what about the situation where you have an entity service that owns the data for one piece of the domain, for example a People service, and then other services, like the Address service and the Billing service, reference a particular person. In that scenario, I can imagine the Address service and the Billing service would have a foreign key referencing a person in the People service. Then, what happens if the Per…

You wouldn't so much delete them, as deactivate them (mark them inactive but keep them in around for retrieval). The consuming service would react differently to an inactive person as an active person.
Post reply on HN