FEATURED STORY

Transparency and transformation at PayPal

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.”

Read more…

Comment

Next-generation Web apps with full stack JavaScript

Power scalable Web apps with 100% JavaScript

stones-1652-BSince its introduction, JavaScript was often seen as a limited object-oriented language that had many “bad” parts. The situation today is almost the opposite.

In competition with Java, C#, and Ruby, JavaScript is developing one of the largest ecosystems for web applications today. Why, as it seems, is a language made for web browsers gaining traction for building next-generation web applications on the server-side too?

In fact, you can see another example of disruptive innovation at work. As Clayton Christensen explained in his innovation theory, affordability and access are important drivers behind technology shifts. While the LAMP stack and its peers with Ruby, Python, Java, and C# provide the foundations for many server-side web applications today, JavaScript ships natively with web browsers, which enables a much larger part of the digital population to experiment with web development. In addition to lower costs of infrastructure and easier installation, companies get access to a larger pool of web developers.
Read more…

Comments: 2

It’s time for a web page diet

Site speed is essential to business success, yet many pages are getting bigger and slower.

Illustration of scaleEarlier this year, I was researching online consumer preferences for a client and discovered, somewhat unsurprisingly, that people expect web sites to be fast and responsive, particularly when they’re shopping. What did surprised me, however, were findings in Radware’s “State of the Union Report Spring 2014” (registration required) that showed web sites, on average, were becoming bigger in bytes and slower in response time every year. In fact, the average Alexa 1000 web page has grown from around 780KB and 86 resources in 2011 to more than 1.4MB and 99 resources by the time of the early “2014 State of the Union Winter Report.”

As an experiment, I measured the resources loaded for Amazon.com on my own computer: 2.6MB loaded with 252 requests!

This seemed so odd. Faster is more profitable, yet companies were actually building fatter and slower web sites. What was behind all these bytes? Had web development become so sophisticated that all the technology would bust the seams of the browser window? Read more…

Comments: 2

Roll-your-own database architecture

Making the case for blended architectures in the rapidly evolving universe of advanced analytics.

Kenny_Louie_Squares_Circles

Two years ago, most of the conversations around big data had a futuristic, theoretical vibe. That vibe has been replaced with a gritty sense of practically. Today, when big data or some surrogate term arises in conversation, the talk is likely to focus not on “what if,” but on “how do we get it done?” and “what will it cost?”

Real-time big data analytics and the increasing need for applications capable of handling mixed read/write workloads — as well as transactions and analytics on “hot” data — are putting new pressures on traditional data management architectures.

What’s driving the need for change? There are several factors, including a new class of apps for personalizing the Internet, serving dynamic content, and creating rich user experiences. These apps are data driven, which means they essentially feed on deep data analytics. You’ll need a steady supply of activity history, insights, and transactions, plus the ability to combine historical analytics with hot analytics and read/write transactions. Read more…

Comment

Cloud security is not an oxymoron

Think your IT staff can protect you better than major cloud providers? Think again.

I just ran across Katie Fehrenbacher’s article in GigaOm that made a point I’ve been arguing (perhaps not strongly enough) for years. When you start talking to people about “the cloud,” you frequently run into a knee-jerk reaction: “Of course, the cloud isn’t secure.”

I have no idea what IT professionals who say stuff like this mean. Are they thinking about the stuff they post on Facebook? Or are they thinking about the data they’ve stored on Amazon? For me, the bottom line is: would I rather trust Amazon’s security staff, or would I rather trust some guy with some security cert that I’ve never heard of, but whom the HR department says is “qualified”? Read more…

Comments: 7

From the network interface to the database

All systems are distributed systems, and we’re starting to see how they fit into Velocity's themes.

Laser_Lighting_Ian_Barbour

From the beginning, the Velocity Conference has focused on web performance and operations — specifically, web operations. This focus has been fairly narrow: browser performance dominated the discussion of “web performance,” and interactions between developers and IT staff dominated operations.

These limits weren’t bad. Perceived performance really is dominated by the browser — how fast you can get resources (HTML, images, CSS files, JavaScript libraries) over the network to the browser, and how fast the browser can execute those resources. How long before a user stops waiting for your page to load and clicks away? How do you make a page useable as quickly as possible, even before all the resources have loaded? Those discussions were groundbreaking and surprising: users are incredibly sensitive to page speed.

That’s not to say that Velocity hasn’t looked at the rest of the application stack; there’s been an occasional glance in the direction of the database and an even more occasional glance at the middleware. But the database and middleware have, at least historically, played a bit part. And while the focus of Velocity has been front-end tuning, speakers like Baron Schwartz haven’t let us ignore the database entirely. Read more…

Comment: 1