Live data from Hacker News

How We Build Code at Netflix

techblog.netflix.com

101–110 of 140 posts

Re: How We Build Code at Netflix

#101
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 think most people do. We did a couple of things to get out of that state at Conjur. First, we made all of our builds into docker containers. Under this system, slaves (we call 'em executors now) only contain very basic software - docker, git, and make to be specific. This means that our builds are entirely self contained, and we don't have to worry about, for example, messing around with RVM on executors. If the co…

You might like to look at Concourse[1], which makes explicit, checked-in pipelines of containerized builds its central model.

I am very bullish on Concourse.

[1] https://concourse.ci

Re: How We Build Code at Netflix

#102
post #87
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 seen something similar happen, switched to https://www.go.cd/

GoCD is very difficult to version-control and the interface is, to put it politely, in need of some love.

At Pivotal my colleagues working on Cloud Foundry poured a lot of engineering effort into making GoCD scale across multiple teams, repos, sites and so on, and it just never worked out.

Alex Suraci wrote Concourse, dogfooded it on a project team, and now pretty much the whole of Cloud Foundry is being built with Concourse pipelines.

Re: How We Build Code at Netflix

#104
post #78

> The Netflix culture of freedom and responsibility empowers engineers to craft solutions using whatever tools they feel are best suited to the task. I absolutely love that. I'm a huge fan of what Hastings and company have done over there in terms of culture and making Netflix a unique and desirable place to work. I think it's time for another round of "find a way to make Netflix hire me."

The real interesting thing to me is the language around "paved road"s, and management support for tools teams to maintain those paved roads.

It's easy to say, "Engineers should use the tools they deem appropriate" and make the engineers happy. What's harder is to support those individual efforts with attention and money to build a common consensus and a shared toolchain.

"Paved roads" is nice language to describe the utility of consensus without condemning those who depart from it. I dig it.

Re: How We Build Code at Netflix

#105
post #78

> The Netflix culture of freedom and responsibility empowers engineers to craft solutions using whatever tools they feel are best suited to the task. I absolutely love that. I'm a huge fan of what Hastings and company have done over there in terms of culture and making Netflix a unique and desirable place to work. I think it's time for another round of "find a way to make Netflix hire me."

There's an open house coming up. Let me know if you'd like to come (if you're in the bay area) zgtjyizv@abyssmail.com

Re: How We Build Code at Netflix

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

Jenkins DSL plugin and/or configuration management (chef/puppet) is necessary.

Re: How We Build Code at Netflix

#107

Earlier quoted context omitted.

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…

HashiCorp also has a pretty complete solution called Atlas : https://www.hashicorp.com/ ( different from the Netflix Atlas http://techblog.netflix.com/2014/12/introducing-atlas-netfli... )

Joyent's Triton looks cool: https://www.joyent.com/ as does CoreOS's Tectonic (built on top of k8s): https://tectonic.com/

Re: How We Build Code at Netflix

#108
post #78

> The Netflix culture of freedom and responsibility empowers engineers to craft solutions using whatever tools they feel are best suited to the task. I absolutely love that. I'm a huge fan of what Hastings and company have done over there in terms of culture and making Netflix a unique and desirable place to work. I think it's time for another round of "find a way to make Netflix hire me."

There's an open house coming up. Let me know if you'd like to come (if you're in the bay area) zgtjyizv@abyssmail.com

Awesome. I just sent you a message. Thank you!

Re: How We Build Code at Netflix

#109
post #3

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.

Huh? The article describes a massive system and there is a lot of abstraction here, are you suggesting Pivotal was a part of the large abstraction or just grabbing credit for some minor part?

Re: How We Build Code at Netflix

#110
post #94

Major outage being reported worldwide. http://downdetector.com/status/netflix Anything interesting deployed in the last hour? Something in the CI/CD tool chain, Spinnaker, failed for it to move all the way to Live without being caught.

There are many reasons that a site can go down, aside from a code deployment.
Post reply on HN