PayPal has gone through a cultural transformation with radical transparency as a cornerstone of the plan.
Three years ago, PayPal was growing exponentially, staying profitable and was considered the most successful online payments company in the world. This should have been the recipe of a company that was attracting top talent across the globe, and keeping their core engineers happy, thriving, and innovative. But, at the time, the PayPal engineering team wasn’t where they needed to be to stay ahead of the curve — they didn’t have the process, the tools, or the resources to extend their talent and stay engaged in creating amazing products and services.
Leadership had encouraged the formation of engineering silos to “concentrate expertise,” but this made it incredibly challenging to get things done. At the same time, popular services such as Google and Amazon were raising the bar for everybody. All businesses — not just software-focused businesses — needed to have websites (and mobile apps) that were snazzy and responsive in addition to being reliable. PayPal engineering needed to push the proverbial envelope to stay competitive in a fierce and unrelenting industry landscape.
For PayPal, the transformation started at the edge of the stack. The Kraken project, which was started by an internal team to support a new checkout system, proved that an open source platform could reduce time to market and still perform at scale. This was achieved largely in spite of the silo culture that ran rampant and tended to restrict innovation and creativity. Support from senior management and perception of less risk at the edge of the stack helped the project and ultimately unleashed a gold rush of interest in repeating the win with releases of internally developed improvements to other open source projects. When I came into PayPal, I received an avalanche of mail from teams who wanted to “open source something.”
A suitable network topology for building automation.
Editor’s note: this article is part of a series exploring the role of networking in the Internet of Things.
Today we are going to consider the attributes of wireless mesh networking, particularly in the context of our building monitoring and energy application.
A host of new mesh networking technologies came upon the scene in the mid-2000s through start-up ventures such as Millennial Net, Ember, Dust Networks, and others. The mesh network topology is ideally suited to provide broad area coverage for low-power, low-data rate applications found in application areas like industrial automation, home and commercial building automation, medical monitoring, and agriculture.
Your views on full-stack development could be featured at OSCON. Here’s how.
We’re putting together a series of short videos that explores the trend of full-stack development from the point of view of people who consider themselves to be full-stack developers—as well as those who’d like to be.
This means your insightful perspective on full-stack development could be seen by new developers and industry experts alike.
Want to participate? Here’s what you need to do:
Submissions are due by the end of the day on Monday, July 14. Read more…
The Lambda Architecture has its merits, but alternatives are worth exploring.
Nathan Marz wrote a popular blog post describing an idea he called the Lambda Architecture (“How to beat the CAP theorem“). The Lambda Architecture is an approach to building stream processing applications on top of MapReduce and Storm or similar systems. This has proven to be a surprisingly popular idea, with a dedicated website and an upcoming book. Since I’ve been involved in building out the real-time data processing infrastructure at LinkedIn using Kafka and Samza, I often get asked about the Lambda Architecture. I thought I would describe my thoughts and experiences.
What is a Lambda Architecture and how do I become one?
The Lambda Architecture looks something like this:
If all companies are software companies, then all companies must learn to manage their online operations.
Two years ago, I wrote What is DevOps. Although that article was good for its time, our understanding of organizational behavior, and its relationship to the operation of complex systems, has grown.
A few themes have become apparent in the two years since that last article. They were latent in that article, I think, but now we’re in a position to call them out explicitly. It’s always easy to think of DevOps (or of any software industry paradigm) in terms of the tools you use; in particular, it’s very easy to think that if you use Chef or Puppet for automated configuration, Jenkins for continuous integration, and some cloud provider for on-demand server power, that you’re doing DevOps. But DevOps isn’t about tools; it’s about culture, and it extends far beyond the cubicles of developers and operators. As Jeff Sussna says in Empathy: The Essence of DevOps:
…it’s not about making developers and sysadmins report to the same VP. It’s not about automating all your configuration procedures. It’s not about tipping up a Jenkins server, or running your applications in the cloud, or releasing your code on Github. It’s not even about letting your developers deploy their code to a PaaS. The true essence of DevOps is empathy.