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

How We Build Code at Netflix

techblog.netflix.com

Post reply on HN
Print view View original

51–60 of 140 posts

Re: How We Build Code at Netflix

#51

Post by conorgil145 »

neduma wrote: post #45

How do they 'externalize config' with respect to http://12factor.net/config ?

There are many ways to accomplish an external configuration. I do not know how they do it at Netflix, but one could have the prebaked AMI reach out to a service discovery tool to pull its configuration at run time. For example, Consul [1] or etcd [2].

One advantage of this approach is that you can use the exact same AMI in testing as in production. All you would have to do is change the configuration which is pulled. You could determine which configuration to pull based on AWS tags on the EC2 instance, for example.

[1] https://www.consul.io/

[2] https://github.com/coreos/etcd

Re: How We Build Code at Netflix

#53

Post by riskable »

draw_down wrote: post #37
riskable wrote: post #22

Earlier quoted context omitted.

What's amazing is that Netflix let their teams develop solutions from scratch. Usually at big companies when their developers say something like, "can't we just build a solution ourselves?" they're laughed out of the room or, more likely, marked down as candidates in the next round of layoffs.

I've been in so many places where that response would be the correct one. I've spent a lot of time decommissioning some rather horrible outcomes of "can't we just build it ourselves".

When companies treat engineers like disposable commodities they should expect solutions that will be disposed.

Re: How We Build Code at Netflix

#54

Post by bmoyles »

neduma wrote: post #45

How do they 'externalize config' with respect to http://12factor.net/config ?

A combination of things such as Spinnaker providing granular environmental context to an instance by way of user data (things that the ec2 metadata service doesn't readily provide to an instance without API calls), dynamic properties which can be controlled down to the instance-level (http://techblog.netflix.com/2012/06/annoucing-archaius-dynam... ), and other solutions depending on a team's needs.

Re: How We Build Code at Netflix

#55

Post by bmoyles »

hitekker wrote: post #3
mattiemass wrote: post #2

Very cool article. Amazing how much tooling Netflix has built themselves.

I believe at least some parts of the tooling were developed by an embedded team from Pivotal Labs.

Not that I am aware of. It's possible they contributed to some of our OSS efforts, but I don't believe anything used internally was developed in that manner.

Re: How We Build Code at Netflix

#56

Post by alistproducer2 »

riskable wrote: post #29
chei0aiV wrote: post #18

Earlier quoted context omitted.

> Immutable infrastructure is the future Are there any downsides to immutable infrastructure?

I'm on a team developing an immutable infrastructure solution with (Docker) containers at a large financial institution. The biggest downsides so far: * It can get complicated very quickly since it involves a lot of stages, systems, and loads of brand new tools where you're unlikely to be able to hire existing talent (you need people who can just read the docs on a complicated tool/architecture like Kubernetes and th…

Thanks for sharing your insight. Comments like this is why HN is my favorite place on the net.

Re: How We Build Code at Netflix

#57

Post by markbnj »

I'm a Netflix fan, as a consumer and an engineer, and this blog post just reinforces my fanboi status. Amidst the descriptions of deployment tools and pipelines one thing stood out for me: the fact that AMI bake times are now a large factor, and that "installing packages" and the "snapshotting process" were a big piece of this. Containers are definitely the answer to this problem. You can deploy base images with the OS and common dependencies, and have the code changes be a thin final layer. Of course with such a sophisticated pipeline based on AMI deployment this change would not be trivial for Netflix, but the bottom line is they have described the primary container use case perfectly, imo.

Re: How We Build Code at Netflix

#60

Post by tracker1 »

jfindley wrote: post #35
riskable wrote: post #29

Earlier quoted context omitted.

I'm on a team developing an immutable infrastructure solution with (Docker) containers at a large financial institution. The biggest downsides so far: * It can get complicated very quickly since it involves a lot of stages, systems, and loads of brand new tools where you're unlikely to be able to hire existing talent (you need people who can just read the docs on a complicated tool/architecture like Kubernetes and th…

We are doing something very similar (mesos rather than k8s), also in a financial organisation. Our main issue is also security - as docker containers aren't very good at actually containing, from a security PoV, we're using SELinux MLS, assigning each container a unique SELinux level/category (fedora-atomic sets this up nicely for you if anyone wants to try). This is great for security, but breaks so many things - lo…

Along a similar grain, I'm curious if anyone's used Joyent's infrastructure stack internally... I know they offer it, but not familiar enough with it. It seems Solaris containers as a base for docker containers is a better security model, but not sure what parts, if enough is open to implement without paying consultation from Joyent to get started even. It's definitely a compelling model.

I am only slightly surprised that there's still a lot of bugginess in this aspect, though I haven't had to deal with that level of security need on the infrastructure side in a number of years. I'd rather be doing app-dev over ops-dev.

Post reply on HN