41–50 of 112 posts
The reason Facebook and Google built their own is that they're at such a huge scale both in terms of usage and number of engineers, that none of the off-the-shelf things work for them. For most companies that's not the case.
This article is dangerous in romanticizing the “not invented here” culture at many big tech companies and seems rooted more in the 90s than present day. The world of open source tooling and easily re-usable SAAS offerings means everyone has access to the best tools, whether you’re a small startup or a big company. Anyone who longs for internal, corporate tooling baffles me when they can use things that actually have…
The internal build tools I had access to at Amazon are unrivaled in the public domain. I DO miss them, at every job.
At one of the places I worked, a relatively large university-hospital, there was an entire Java-UI framework build based on C#s XAML. But it could also experimentally be compiled to html/css/js. Writing any type of UI in Swing is just painful - but this system made it so much nicer. It also had a WYSIWYG editor that you could interop with actually writing the code. Plus you could write either the 'markup language' or…
If you can't come up with anything, it's possible you're just beyond repair and too snarky to think reasonably Or perhaps that we've mostly worked in crap dev jobs/companies? There are easily enough of them around to encompass a career.
> but which didn't exist on the outside world.
> You're not allowed to include things you or your friends built
If you work for a service provider, you probably have zero to not much internal tooling, because you're usually solving the customer's problems, not your company's. When I did, we open sourced everything cool we built - sometimes tried and true defaults, or sensible Vagrantboxes or something like that. (Today that would be Dockerfiles, I guess) - and I consider myself lucky to have worked at a smaller company that was close to the FOSS scene, and not something like Accenture. Companies like ThoughtWorks might be an outlier here.
You're unlikely to build something so immensely cool in your first 1-2 years in a startup that it will change your live (as a developer) completely. (This is not about your company's product, but internal developer tooling, so if your startup does developer tools as a product, you're the 1% where this would apply).
And finally, if your startup grows.. you might probably still not be the next Google or Facebook where the internal team providing nice things to your fleet of developers is bigger than some companies. Internal tooling will often be seen more of a cost factor than a tool for productivity enhancement. And often it's actually the case. In my current company we just have so many software development teams creating parts of our products.. so many languages (with good reason) - the only internal things I could think about that would even make sense for all of them would be some code review tool, or anything targeting source control or maybe CI. Anything else would have to be really workflow-centric and language-agnostic. Anything regarding the mentioned borg/k8s/BigTable would be completely useless, for example.
That said, at my last company, I think we created some pretty cool things that made a lot of things a lot easier for the team. But we were two small teams, so point to "we built it ourselves, for ourselves" applies. Also it probably wasn't so revolutionary in the greater sense, but everything made sense for that company and I'm often still sad if I have to solve some similar problem these days and don't have my old setup (more than a specific tool).
For 99% of engineering organizations, internal engineering tooling is not your source of competitive advantage. Your advantage in the market comes from understanding the needs of your target user better than anyone else, and building a product that meets those needs. For every piece of infrastructure or developer tooling you need, you have to make a buy vs. build decision based on cost/benefit analysis. Your cost to…
> Very large engineering organizations like Facebook, Netflix, etc. > If you're at a mega-corp with a huge engineering staff: Netflix is an odd choice for number two on a list of two. I’d guess it has an order of magnitude fewer engineers than Facebook. So what’s the rough cutoff here? 1000 software engineers?
I'd miss the engineering machine shop. Those facilities only get developed by accident, for instance if a company gets rid of its professional machinist but keeps the equipment, or something like that. The machines and collections of tooling take a long time to curate. Any modern manager would refuse to allow that much stuff to be purchased if they were asked, and believe in the magic of outsourcing everything.
I prefer Kubernetes and Prometheus to Borg and Borgmon. Better interoperability, portability, and documentation. Does any other Xoogler have thoughts on this? The author didn't mention it, but I also prefer Capn to Proto3.
As for Prometheus, I like the rules engine VERY much (unsurprising, since they basically reimplemented borgmon, there). I'd take Viceroy any day over Grafana, though.
Wanted to see what Facebook Scuba was, and found this comment thread that really highlights the point of this blog. https://news.ycombinator.com/item?id=13463016
I think it's somewhat like Apache Druid.
Basically: structured log events with dozens or hundreds of columns, no write time aggregation, and arbitrary folding and slicing of data for investigation and debugging.
I just joined apple and I miss all the Linux tools