Featured in DevOps

Adin Scannell talks about gVisor - a container runtime that implements the Linux kernel API in userspace using Go. He talks about the architectural challenges associated with userspace kernels, the positive and negative experiences with Go as an implementation language, and finally, how to ensure API coverage and compatibility.

According to Harrell, PayPal’s websites had accumulated a good deal of technical debt, and they wanted a “technology stack free of this which would enable greater product agility and innovation.” Initially, there was a significant divide between front-end engineers working in web technologies and back-end ones coding in Java. When a UX person wanted to sketch up some pages, they had to ask Java programmers to do some back-end wiring to make it work. This did not fit with their Lean UX development model:

At the time, our UI applications were based on Java and JSP using a proprietary solution that was rigid, tightly coupled and hard to move fast in. Our teams didn’t find it complimentary to our Lean UX development model and couldn’t move fast in it so they would build their prototypes in a scripting language, test them with users, and then later port the code over to our production stack.

They wanted a “templating [solution that] must be decoupled from the underlying server technology and allow us to evolve our UIs independent of the application language” and that would work with multiple environments. They decided to go with Dust.js – a templating framework backed up by LinkedIn – , plus Twitter’s Bootstrap and Bower, a package manager for the web. Additional pieces added later were LESS, RequireJS, Backbone.js, Grunt, and Mocha.

Some of PayPal’s pages have been redesigned but they still had some of the legacy stack:

… we have legacy C++/XSL and Java/JSP stacks, and we didn’t want to leave these UIs behind as we continued to move forward. JavaScript templates are ideal for this. On the C++ stack, we built a library that used V8 to perform Dust renders natively – this was amazingly fast! On the Java side, we integrated Dust using a Spring ViewResolver coupled with Rhino to render the views.

At that time, they also started using Node.js for prototyping new pages, concluding that it was “extremely proficient” and decided to try it in production. For that they also built Kraken.js, a “convention layer” placed on top of Express which is a Node.js-based web framework. (PayPal has recently open sourced Kraken.js.) The first application to be done in Node.js was the account overview page, which is one of the most accessed PayPal pages, according to Harrell. But because they were afraid the app might not scale well, they decided to create an equivalent Java application to fall back to in case the Node.js one won’t work. Following are some conclusions regarding the development effort required for both apps:

Java/Spring

JavaScript/Node.js

Set-up time

0

2 months

Development

~5 months

~3 months

Engineers

5

2

Lines of code

unspecified

66% of unspecified

The JavaScript team needed 2 months for the initial setup of the infrastructure, but they created with fewer people an application with the same functionality in less time. Running the test suite on production hardware, they concluded that the Node.js app was performing better than the Java one, serving:

Double the requests per second vs. the Java application. This is even more interesting because our initial performance results were using a single core for the node.js application compared to five cores in Java. We expect to increase this divide further.

and having

35% decrease in the average response time for the same page. This resulted in the pages being served 200ms faster— something users will definitely notice.

As a result, PayPal began using the Node.js application in beta in production, and have decided that “all of our consumer facing web applications going forward will be built on Node.js,” while some of the existing ones are being ported to Node.js.

One of the benefits of using JavaScript from browser to server is, according to Harrell, the elimination of a divide between front and back-end development by having one team “which allows us to understand and react to our users’ needs at any level in the technology stack.”

Sigh

Your message is awaiting moderation. Thank you for participating in the discussion.

I can't verify their tests ...

But they are ignoring that "backend" and "frontend" developers are still different. And due to the nature of JavaScript and the lack of tooling, they are looking at a bigger TCO. Their code base will increase because of the tests they will have to write.

As for "speed" when they use Node.js and plain Java, they are comparing apples and oranges. There are at least 3 Java async APIs.

There are multiple ways to code in Java for the client and still have it run as JS in the browser

Java or JEE problem?

Your message is awaiting moderation. Thank you for participating in the discussion.

It sounds to me as if Paypal are attributing to "Java" what is really a problem of JEE. The JEE stack is way past its due date, invented for a time when web apps were the only type of apps Java developers did, and where they looked much simpler than they do now (with AJAX calls, WebSockets etc).

Simply combing UI engineer and JEE developer may not be a good idea

Your message is awaiting moderation. Thank you for participating in the discussion.

I think you may be coming from UI team and are lack of full view of the "architecture".

After having the prototype on hands, some guys like you may be thinking that "great, the work is almost done" and then hand over to the development team for the detail implementation. To your surprise, the JEE developers plan a longer timing than what you expected, so you hate these guys and are thinking to combine them with all UI/javascript guys.

It's dangerous. Again, you may not have a full view of the whole system's architecture.

Replacing JSP is good idea as it's not a good templating technology. But doing so doesn't mean that you're replacing Java, especially backend components.

The backend roles are definitely necessary as they're thinking different ways.Improving the roll-out efficiency doesn't mean just to simplify the team as one or two roles that you like.