Puppet Labs

Why we piggybacked on the open source Mattermost for Uber's chat needs, which we open sourced as uChat ( GitHub : https://github.com/uber-uchat/ -- contributing some of our changes back to Mattermost as well in the process.)

With operations in over 620 cities, it was paramount for us to identify a chat solution that would enable Uber employees to reliably communicate on desktop and mobile regardless of where they were in the world. To accomplish this, we established a few core requirements. To start, we needed something that could scale to support our growing employee population and, as a byproduct, control costs. We also needed a platform that could easily integrate with a variety of internal engineering, business, and operational tools.

While we evaluated Internet Relay Chat (IRC) and many other popular chat clients, it became clear that there was no turnkey third-party solution able to meet Uber’s core requirements.

So after testing multiple off-the-shelf alternatives, we built uChat, our custom in-house messaging platform, by leveraging open source platform Mattermost and Puppet Labs , the Uber standard for deployment configuration management. In this article, we discuss how in just three months our team transitioned the company to a new solution capable of reliably delivering over one million messages per day to tens of thousands of users, all in one unified chat environment:

https://eng.uber.com/uchat/

Configures or servers and allows us to be region independent we have 5 regions across the globe. Puppet Labs

Opstax uses puppet for role/profile based configuration management and the distribution of small/static code. Puppet Labs

I'm using puppet to configure my servers. This makes it really simple to ensure that I have the same environment. There is a bit of a learning curve, but the repeatability definitely makes it worth the effort. I found puppet to be a little easier to pick up relative to chef, but I've used both. They're both great solutions.

I really like that there are a lot of modules available on the puppet forge that are being actively maintained. Puppet Labs

By 2014, the DevOps team at Lyft decided to port their infrastructure code from Puppet to Salt. At that point, the Puppet code based included around "10,000 lines of spaghetti-code,” which was unfamiliar and challenging to the relatively new members of the DevOps team.

“The DevOps team felt that the Puppet infrastructure was too difficult to pick up quickly and would be impossible to introduce to [their] developers as the tool they’d use to manage their own services.”

To determine a path forward, the team assessed both Ansible and Salt, exploring four key areas: simplicity/ease of use, maturity, performance, and community.

They found that “Salt’s execution and state module support is more mature than Ansible’s, overall,” and that “Salt was faster than Ansible for state/playbook runs.” And while both have high levels of community support, Salt exceeded expectations in terms of friendless and responsiveness to opened issues.

By mid-2014, around the time of the Series F, Pinterest users had already created more than 30 billion Pins, and the company was logging around 20 terabytes of new data daily, with around 10 petabytes of data in S3. To drive personalization for its users, and to empower engineers to build big data applications quickly, the data team built a self-serve Hadoop platform.

To start, they decoupled compute from storage, which meant teams would have to worry less about loading or synchronizing data, allowing existing or future clusters to make use of the data across a single shared file system.

A centralized Hive metastore act as the source of truth. They chose Hive for most of their Hadoop jobs “primarily because the SQL interface is simple and familiar to people across the industry.”

Dependency management takes place across three layers: *** Baked AMIs, which are large slow-loading dependencies pre-loaded on images; **Automated Configurations (Masterless Puppets), which allows Puppet clients to “pull their configuration from S3 and set up a service that’s responsible for keeping S3 configurations in sync with the Puppet master;” and Runtime Staging on S3, which creates a working directory at runtime for each developer that pulls down its dependencies directly from S3.

Finally, they migrated their Hadoop jobs to Qubole, which “supported AWS/S3 and was relatively easy to get started on.”