Node Summit: Walmart: Save Money, Use Node.js

James Watters, Group Manager Ecosystem Development at Cloud Foundry, talks with Walmart Vice President of Mobile Architecture Dion Almaer and Vice President of Mobile Engineering Ben Galbraith. Watch as they discuss Walmart’s mobile strategy and how they are leveraging Node.js at the largest retailer in the world.

This is very comfy, very nice. It's bright. Hey. So I'm joined by Ben and Dion. I thought I'd let them give a quick introduction who they are, what they're up to? Ben.

So I'm vice president of
mobile engineering at Walmart labs with my good friend Dion.

And I'm vice president of mobile architecture.

How did we wind up in Walmart by the way?

That's an interesting question.
You don't all often think that people are going to flock to Walmart. We made a list of sort of our dream employers and Walmart was at the top of the list, and that's what happened.

You stack ranked by revenue, I assume.

That's a good one.

Before Walmart, we
were running our own start up called Set Direction, which we started after leaving Palm where we did WebOS, and run developer relations. So it's just our work, it was all us.

Oh, yeah just us and like hundreds of great engineers.

Yes, we were just in dev
relations at HP Palm, and it was a fun ride for about a year, right?

And then so we did the startup and then we talked to Walmart, they were one of our clients as we did a startup, and as we got to know them better, we actually got really excited about joining full time and we've been there for eight months now, right?

Yes, almost ten, I think.


OK. And you guys even blogged, you've made a multi-year commitment to really go build something for real there.


And it's not, sort of a consulting
stop, where you give them a little advice, draw some triangles and move on, you went there to build.

Yes and I think one of
the big things, was when we were kind of talking to Walmart, we talked to people all the way up to the CEO and he's told me how important Mobile is, and how e-commerce is often kind of seen as its own channel, so there's stores and e-commerce is kind of like another store.


But with mobile customers are bringing
the internet into the store, and we can finally bridge the gap with online and offline, and that got us really excited.

Plenty of customers.
So you use Node.js, why'd you make that decision?

It's a good question. I'll cover a few, you want to jump in too?


So I think for
us, we've been fascinated for a long time about end to end JavaScript, and in our industry we've been chasing end-end for a long time, nothing new really there, and when we were doing our start up, we started this website called functionsource which we never really had a chance to finish because we joined Walmart, but one of the things that we did there that really excited us was pursuing an architecture where we could seamlessly mix where the logic was executed. And one of the reasons we wanted to do that, was to think about how you would have a website that can be rich and dynamic on desktop devices and on high-powered mobile devices but would also deliver a really rich experience visually for other devices, that weren't as powerful. And so we came up with this architecture where we could execute all the code, all the frontend code on the backend seamlessly, when for example, the Google Spider came in or we were targeting a low-power device. But at the same time for those higher-end devices, it was a really rich experience that delivered a lot of dynamic functionality on the client. And so for us, we're really excited to finally have a viable backend for that because really up until Node.js arrived and generated such excitement, the other sort of projects for doing JavaScript on the server side weren't really viable from our opinion.

So, that's one of the reasons why Node has really excited us, and at Walmart we're doing a lot with that style of architecture right now.

Another piece is kind of,
has nothing to do with the JavaScript side, and the fact that we use JavaScript and that's the evented structure. So, if you think about the mobile group, we rely on services from all over the world, services that sometimes are going all the way to a store to get local availability.

Sometimes we're going to, sometimes we're going to Asda in the UK, we've got third party sites that have rich review content that we want to show. We do not control all of those services, but we want to deliver a really scalable performant architecture. So Node allows us to front all of these different services and build an orchestration API server, so we can go in and we can cache this guy up, we can scale up very nicely.

Node is just perfect for what we happen to be doing in mobile.

Yes, it's kind of the unique
challenge that's happening in mobile and enterprise today which is how do I get all the assets I've spent 10 years developing, but how do I take them to this really fast moving new place where trends change every six weeks, every six months, and it seems like, Node is the lubrication you guys are using to get you there faster with the enterprise backend that you inherited.

Yeah there's a non technical component to that too.
I think a big part of success anywhere is the talent you recruit—the biggest single ingredient—and at Walmart we've got huge challenges to solve, which is one ingredient to attracting great talent, but we wanted to make sure that we had a technology platform that really energized people and that really gave us access to some of the best people in the industry. And to be pragmatic about it, Node has been that for us to on the recruiting side for the services that we're building to be able to go out into the industry and offer people the opportunity to work with Node at this large scale.

So I mean some of this problems in mobile which is I think the hottest technology space right now in the sector too on the client side has really been a great sort of ingredient for us to attract great talent, and we've been able to do that. We've got some great hires that have joined the team lately that are really exciting.

Yeah you're saying Portland was exploding for you.

Yeah some of the hires
we've had here in the bay area are exciting too. Eran Hammer who is one of the architects behind oauth is on the team and that's been a great hire, he's here in the bay area. We also have an office up in Portland where we have 19 people now, that was—we didn't set out to do that but we found that Portland market place for talent, it's really hot and we were able to get high quality talent really quickly. So when you're looking at hiring talent out of like the Node ecosystem, how do you start to think about who's thinking about the frontend, who's thinking about the backend.

Do you ask a backend guy, hey! how do you think about that front experience? Do they have to think the whole way through the API, how that's going to interact with the front side? What are the kind of questions or how do you filter through some of the talent that you run into?

We have a lot of people that are into different things, so we've got some of the guys on the team that came from more of the frontend view, came in through that maybe to Rails to now working in Node, and they really thrive on the kind of architectural things that we've setup like the function tools world of being able to kind of share these loads across client and server, and optimizing those experiences, and then we've got other people that are more traditional backend guys that are much more interested in building the backend API server framework, how to build this orchestration server, how to talk to all these different services, and they tend to find their time more focused on those things. We've got kind of a mix of those. A lot of the people that kind of send their resumes over, it is interesting to see, we see this in different ways.

On the Android side, we see people that say they know Android and then you look at it and they're Java server guys because they know Java, of course, they know Android, but they don't know the UI stuff or what's going on. We also run into the same thing on the Node world where you got people that know JavaScript that have done some jQuery so obviously I know Node, right?

And they've got no idea what it's like to build large scale backend systems, and so you definitely have to kind of weed through some of that, and sometimes there's people that come from that background that are incredibly talented and skilled people that make it through but it's kind of fun to see.

It's interesting talking to you both
because you really talk about the end to end JavaScript, and you talk a little bit more about the performance, and even in your architecture I can see where both of those things are very useful, but that's very common debate anytime I watch a Node Summit or talk, I see that so it's great to have both people sitting right here.

That also leads over to—in the mobile world—you've got iOS and Android and HTML5. So how have you worked through some of those decisions, and maybe what's been hot for you? Like where's the needle right now?

Yeah, so that's I think the question of our industry right now is how do you grasp with all these different client side platforms, and for us, our remit is larger than just the US, we're worldwide, and so as you plan out a matrix of the apps that you're building, and you look at all the different apps that you'd have to create, you've got iOS, which is really iPhone and iPad which are totally distinct user experiences. Then you've got Android, and someday Android tablets maybe something that as an industry we care about, and then there's mobile web, and then there's perhaps tablet optimized mobile websites, instead of just phone optimized mobile websites, and then Windows phone appears to be making some inroads, and so in one marketplace that's a daunting list. You explode that out worldwide, its almost impossible to wrap your head around it, so the solution that a lot of people go to is HTML 5 for the apps. You know we're web guys by background. That appeals to us viscerally, but we found that we haven't seen people create the experience that we'd like for retail in a pure HTML5 application. And so we are investing heavily in native UIs, but how do you solve that problem of scaling out to so many different clients? And so what interests us right now are these so called hybrid architectures.

Hybrid used to mean in the client space, something like phone gap where the hybrid was that you'd have access to native APIs but your UI would be entirely web. For us, hybrid is more interesting in the areas of what the LinkedIn App has done, what the Facebook App has done, where you have discreet areas of functionality like in the Facebook example, the News Stream which is implemented as with web technologies and is the same UI and experience in Android and in iOS and in a mobile website, but on those platforms, the rest of the app has a real native experience but you get that sort of cross platform leverage in these targeted areas, and we have been doing that in our work in Walmart labs, in particular, in the area of checkout where that makes a lot of sense but also in targeted areas in the API too, we've been able to get that targeted leverage where you don't miss the native experience, but you're still able to leverage across.

Yeah, so you're saying that you might have a native experience for everything except something that you don't want to control, transaction on or a checkout, and so the client side itself is essentially an integration point where you aggregate.

Yeah, and I think beyond
that—so if you look at our checkout system, the business logic is a flow of events. and you look at our mobile website, and it's just a web code, it's just all this backbone based code. But then, if there's a particular piece, even within the checkout flow, there's a point where you can go to a local store, and there the native iOS team said, we've got map kit, we've got this great experience, so I'm going to grab that event and I'm going to deliver in a native UI to give people the store picker.

But all of the logic and the core system doesn't even know that, doesn't even care. So that gives us the ability to really kind of fine grain, go in and add native experiences without having to rewrite the application.

So that conversation leads me
to a quick question on WebOS because I you guys have some pretty deep background there, and we even talked about it a little bit recently. So what is the story about the marriage between WebOS and Node, and how did that work, and can you give me a little bit more of a story there?

Sure. So in the original world of WebOS, the backend services piece on the device were actually Java—a hand built JVM, and that wasn't working for a variety of reasons, and so I think a lot of people in the WebOS engineering teams saw the opportunity with building this web system, "we should use JavaScript for these services," and so this actually started before Node even came about.

So they started to develop a framework that allowed you to build services on the device using JavaScript. Then Node came along and we quickly kind of realized that instead of coming out to the world with our own JavaScript stack that you could build on, maybe there's a way to leverage this. And so we actually invited Ryan to come in and meet with the guys, and kind of talk about our architecture and talk about the needs, and would Node fit on an embedded device, does that even make sense compared to the server, and based on those conversations everything kind of pivoted, and that's how we end up with having a Node 0.2 version on the device.

Dion is a real champion of that internally. I remember when we had an executive review talking about when we were going to ship the WebOS 2.0 release that had Node embedded in it, and at one point we got to the piece on the backend services architecture, and the CEO was talking to the engineering team, and they said, well this Node thing, we're having a hard time making it work and the CEO turned to Dion, "Dion what's the problem with Node?" But eventually that worked out.

Isn't it funny
how people always just want to pick a noun and blame it? You know? They don't want to see the complex stack dump,, they're just like, what's the noun that I can blame for this. Exactly, it's all block diagram. So how has Node affected your choice of kind of a backend? And I don't mean of the transactional backend that you guys aggregate, but like on a basic data or caching layer. Has Node influenced that choice, and what are you using now?

Yeah absolutely. So one of
the problems that we grapple with on the backend is just making sense of the big data landscape, and we've had experts come in and talk to us about how we should be storing our data, because we've got all these clients in the marketplace, and we just want to store a ton of events about everything from how people are using the device (anonymised of course) but just like how often do people scroll through here, how often do people look at that, how often does this advertisement lead to conversions for the next step? And so we've sort of narrowed it down to a couple of different pieces. Internally right now we use Mongo because it's such a great fit with Node.js, and it lets us have end to end data storage. But then we're also spinning up a new cluster for longer term data analysis because that frankly gives us better performance on running map reduce queries. Although I want to talk with the Intel guy to see how I can get more efficient queries running but it definitely has given us a natural fit for where we store some of our data that we generate on the client tier.

And then we run into, there's certain things that we want to see in real time, and then redis is a natural fit, so we're kind of not looking at one thing to solve all of the problems but to kind of see what these different issues are. Like our analytics backend is hosted by Node, and so now suddenly, you've got all of the devices out there, all of the mobile web clients out there, they're all pinging lots and lots of events over to the server. Node has to handle all of this, so we have to look at how to scale that, where to put that data, where does that data migrate to, do we aggregate that data, what do the business users want to see and some fun stuff.

So you guys are generating a ton of data
from all these consumer interactions, and you've got to keep them snappy on the frontend, but then you've also going to deal with long tail analysis that comes out of them, it's kind of an interesting systems engineering challenge really when you think about solving both those problems at the same time.

Is it your team that looks at that scope? Do you have, kind of, purview over both of those?

Yeah, absolutely. We have, in Walmart labs we have this sort of a separate mobile team and we have our own separate business strategy team that's constantly looking at the data and trying to help us understand what we could be doing differently. We're seeing some interesting dynamics that we don't fully comprehend right now.

For example, we've got Android devices and iOS devices and mobile web devices and iPad devices, and we're seeing the rate at which people buy things really sort of dramatically different across the different platforms. iPhone and mobile web are kind of constant but we're seeing that Android's quite a bit lower and iPad's quite a bit higher, and so we're in the process of deconstructing that to understand whether or not those trends are inherent platform characteristics, you could generalize the app marketplace behaviors and say, maybe these are the same behaviors we're seeing in retail, or maybe there's just something about our app that makes it more difficult on Android and easier on iPad or use case scenarios, and so we're constantly looking at that sort of bigger picture stuff, and then on the macro details, we're constantly driving in and evaluating different hypothesis about why doesn't this work the way that we'd expect it to, how come we're seeing these behaviors happen? And frankly, the direction we want to go to is seeing how much we can solve algorithmically for this. So can we sort of extrapolate expected conversion behaviors across different activities? For example, when someone searches for an item, they typically click to search results this percent of time, and then they typically click to product details this percent of time, and they typically add to cart this percent of time, and then can we analyse our application in real time and find opportunities where hey, a lot of people are trending for a search term but not converting, which means that we're not supporting that.

For example, we've seen people do different search terms that you would think connect to a product but actually don't, and so having that real time data gives us an opportunity to solve the problem in real time by delivering customized search results for that immediate problem and then figuring out why our search engine was wrong. And so as we figure out where we're headed within the space, we hope to have more of these sort of real time detection algorithms in place to help us get more and more efficient.

And this fits in with the native plus web strategy. We want to be able to A/B test this stuff. The web is great for that. We have full control of what's going on, we can make changes all the time, we can change our algorithms for how do we deliver experience A or B, and the native world doesn't give us that. So that's where we can fit this in.

When you can convince me to do an update.


That slowly A/B tested.


Got it.
One last question. Do you guys see any regional differences? You do some interesting in the store kind of features on your mobile device now. Do you see any regional changes and how that's adopted to say West Coast, East Coast, Europe, Asia?

That's just a question I have.

Yeah, I think one of the
big things that surprised me a little bit was the difference between what we're seeing in the UK market which is under the brand of Asda, versus what we see over here. One of these is just the mobile web usage is massive over here in proportion to the apps.

Whereas over there, the apps are kind of 50-50 with the mobile web, and to be fair, the applications are little bit different, Asda in the UK is more about groceries than Walmart so it could actually be about that, that's part of the stuff that we need to kind of dive into. But we are also seeing that the android penetration is different in the UK versus here and all these kind of things. I haven't seen anything to do with regional within the US, I don't know if you have.

I haven't paid attention to any of those regional patterns yet but those are the kind of things we want to dig more into in the coming year.

We sell more giant stuff here than on the East Coast.

Well actually no. This is great.

Hey, well thanks for
coming out and giving us a little update on where you're going.

I look forward to hearing more in the future about you guys are using Node.

Thanks James.

Thank you.

Sign up now for Instant Cloud Access Get Started