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

121–130 of 140 posts

Re: How We Build Code at Netflix

#121

Post by agentgt »

vlucas wrote: post #39

For those wondering about how this applies to Node.js use a Netflix like myself, it's in there towards the bottom of the article: > "As Netflix grows and evolves, there is an increasing demand for our build and deploy toolset to provide first-class support for non-JVM languages, like JavaScript/Node.js, Python, Ruby and Go. Our current recommendation for non-JVM applications is to use the Nebula ospackage plugin to p…

Twitter has an agnostic tool called Pants [1]. I run a JVM shop and we are just now using some NodeJS so we are have been trying to figure out that as well.

[1]: https://pantsbuild.github.io/dev.html

Re: How We Build Code at Netflix

#122

Post by agentgt »

Scarbutt wrote: post #24

What are the reasons for Netflix choosing nodejs for their front-end server and not java like in their back-end?

Java even with webjars, hot reloading (jrebel), and what not just can't keep up with the superior Node tooling not to mention more and more frontend developers know node and not Java.

I still prefer Java/JVM languages though for backend work.

Re: How We Build Code at Netflix

#123

Post by agentgt »

igor47 wrote: post #118
mkobit wrote: post #61

I'm interested in knowing more about the "25 Jenkins masters" that they have, and how much they have modified/built for Jenkins to make it work for them. We are currently in a state of "big ball of plugins and configuration". A bunch of plugins have been installed, and lots of manual configuration has been put into jobs so that everybody has what they need to build their software. It has led to Jenkins being a "do ev…

I've spoken to multiple companies about how they do builds, and it's incredible (to me) how many of them use Jenkins. In the end, almost everyone ends up with the kinds of problems you can see on this thread: * Plugins are useless * Configuration drifts all over the place * Jenkins ends up just being used as a job runner to run shell scripts * Every repository or project implements similar but subtly different build…

However your not tipping your hat to the huge values Jenkins provides:

    * Reporting such as unit test reporting
    * Emailing and notification
    * A well known plugin system
    * User security
    * Master / Slave management
Jenkins is not just a job runner. Its a job runner that collects reports, maintains history of the job being run, manages user security, has a public api (REST) and plugin system. That is a lot of stuff to implement on your own.

Really Jenkins just needs to fix the configuration drift issue.

Re: How We Build Code at Netflix

#124

Post by riskable »

draw_down wrote: post #79
riskable wrote: post #53

Earlier quoted context omitted.

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

NIH is the opposite of "disposable engineers". It's saying your engineers are so much more precious and able than the barbarians outside the gate, that they should write their own test harness/DOM selection library/insert commodity software genre here.

To be fair most COTS solutions made for enterprises are absolute crap. It doesn't take much to improve upon them.

Enterprise tools are well-known to have absolutely horrible user experiences, extremely complicated configuration and architecture, and even worse documentation. I don't blame any manager/PM for thinking, "we can do better" with an internal team.

Re: How We Build Code at Netflix

#125

Post by riskable »

ArkyBeagle wrote: post #40
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.

Netflix cares about "it works" and they have to have tools.

They also seem to have technical management as well. That makes a huge difference in building out and maintaining your own tools and also in hiring and retaining effective engineering talent.

Re: How We Build Code at Netflix

#126

Post by riskable »

cyphar wrote: post #89
riskable wrote: post #20

Earlier quoted context omitted.

The other replies here are great but let me give you the layman's version of what "immutable infrastructure" means: If it works for me it works for everyone. You never patch or upgrade immutable infrastructure. You just replace what you've got with a new VM or container. Containers being preferred because they can be started & stopped near instantaneously and there's nothing like a virtual BIOS that could have differ…

> So when your security team freaks out because none of your hosts/containers are showing up in their systems you'll have a lot of explaining to do =D > "We need to scan your hosts so we can ensure that you're installing security patches." > "We don't do that." > "You don't install security patches?!?" > "Yeah, well, you see..." If you use a tool like zypper-docker, you can create a new image quickly that applies jus…

zypper-docker is kinda pointless. Just re-build from your Dockerfile using the latest upstream image. It takes like 10 seconds (depending on how many external dependencies need to be fetched).

Our Docker registry pulls down the latest images (that we use with our Dockerfiles) multiple times daily. So if the author of the Dockerfile just puts "FROM whatever:latest" they are guaranteed to have all the latest/patched software whenever they "docker build".

Re: How We Build Code at Netflix

#127

Post by oconnore »

simonebrunozzi wrote: post #86
oconnore wrote: post #36

Another Spinnaker: http://arxiv.org/pdf/1103.2408.pdf

Good point - curious what do you exactly mean by this though, and how did you compare Spinnaker with it. Can you elaborate a bit more?

Really just a naming collision. IBM Spinnaker is a data store, Netflix Spinnaker is a software builder. The paper I linked is interesting if you're researching distributed data stores.

Re: How We Build Code at Netflix

#128

Post by dominotw »

igor47 wrote: post #118
mkobit wrote: post #61

I'm interested in knowing more about the "25 Jenkins masters" that they have, and how much they have modified/built for Jenkins to make it work for them. We are currently in a state of "big ball of plugins and configuration". A bunch of plugins have been installed, and lots of manual configuration has been put into jobs so that everybody has what they need to build their software. It has led to Jenkins being a "do ev…

I've spoken to multiple companies about how they do builds, and it's incredible (to me) how many of them use Jenkins. In the end, almost everyone ends up with the kinds of problems you can see on this thread: * Plugins are useless * Configuration drifts all over the place * Jenkins ends up just being used as a job runner to run shell scripts * Every repository or project implements similar but subtly different build…

lets you have Jenkinsfile in your repo https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin

.ci.yml like .travis.yml https://github.com/groupon/DotCi

solves every single problem you have listed.

Looks like jenkins has discoverability issues. I am curious what kind of things you tried with jenkins before writing your own build system.

Re: How We Build Code at Netflix

#129

Post by ArkyBeagle »

riskable wrote: post #125
ArkyBeagle wrote: post #40

Earlier quoted context omitted.

Netflix cares about "it works" and they have to have tools.

They also seem to have technical management as well. That makes a huge difference in building out and maintaining your own tools and also in hiring and retaining effective engineering talent.

I think it's more interesting to note that they couldn't exactly buy that from anyone else.

Re: How We Build Code at Netflix

#130

Post by pyman »

This is how my company used to build software 10 years ago.

Now we have Docker containers, cloud VMs, GitHub, 1 click deployment, advanced metrics, Grafana, Go microservices, Slack bots, etc.

Sounds like Netflix is stucked in the past.

Post reply on HN