Surge 2012: Pete Emerson presents “Load Balancers at High Scale: A Disappearing Act”

Posted on October 11, 2012 by Jessica

Pete Emerson, our Director of Tech Operations, spoke at Surge Conference 2012.  He discussed our scale engineering challenges and solutions to a crowd of 400 technologists and engineers.

Pete’s presentation walks through the costs and benefits of using load balancers versus building a custom solution, including scalability, flexibility and trading off development time vs.  packaging, predictability and the capital expense of out-of-the-box solution.  He then dives into how we rid ourselves of load balancers and built our own custom solution using Keepalived and GSLB, which we continue to use to this day.

comments (0)

How to Create HTML & PDF Prototypes Using OmniGraffle Pro

Posted on May 4, 2012 by Julie Blitzer

An important step in the Lean UX process is continuous validation of design ideas, especially early in your process. We are lucky enough to have a UI Engineer (shout out to Dan Hahn!) on our team who builds high-fidelity prototypes, but sometimes it is best for the designer to spend a few hours cobbling together that prototype and not ask the engineer to code and recode a prototype several times if testing the first design iteration.

The best prototypes seem the most real and finished to the test subject. If the user thinks your prototype is not live, the data is fake, he/she may be more forgiving and less critical. It is important that a table of data has numbers that look real, not a series of #### and that your text is not lorem ipsum. The best prototypes are built with HTML/CSS and JS, but as a designer, I do not code often enough to be able to churn out a full-fledged prototype for a complex feature in a few hours. Earlier on in your design process, when you need to validate your hypotheses and your general design direction, something more lightweight built from your design file or a paper prototype is sufficient.

In Prototyping: A Practitioner’s Guide, Todd Zaki Warfel does a fantastic job of covering the why and how of prototyping within the UX design process. He spends several chapters walking through prototyping with various tools: Powerpoint, Keynote, Visio, Fireworks, Axure RP & HTML. What he misses is OmniGraffle Pro. It is mentioned briefly, but never fully explained.
Continue reading…

comments (2)

On RESTful API Standards – Just Be Cool: 11 Rules for Practical API Development (part 2 of 2)

Posted on May 3, 2012 by Larry

I posted a few days ago about my ideas for 11 rules for practical API development. Let’s jump back in with rules 6 to 11.

6. Make it easy to understand and navigate through child objects. The fact is it can be really easy to confuse your database fields as API fields. You might have a field in your table called color_id that represents a color in the color table. Your service returns color_id and you expect your users to somehow know to hit the color service to find out more information about the color. It will behoove you to represent the color as an object since it is an attached object. Also, including a URL where the user can get more information about the color is super helpful. And if you have an extra minute, throw in the URL where they can see all the colors in the meta part of your response. For example: {…”color” : {“id” 3, “name” : “blue”}…}{“meta” : {“urls” :  [{“color” : “http://yourcoolapi.com/color/”}]}}. Use a convention like that and developers will be able to add code to automatically pull in more information about the object as well as pull all objects for a picker list.
Continue reading…

comments (1)

On RESTful API Standards – Just Be Cool: 11 Rules for Practical API Development (part 1 of 2)

Posted on May 1, 2012 by Larry

There are many articles floating around the internet right now about defining RESTful API standards. I’m guessing this is because Ruby on Rails makes it so easy to build an API that everyone and their mom has started building one. These articles talk about the RFC on HTTP and how REST should fit in. They outline how current implementations are “broken” and want to come up with certain “standards” for governing how a RESTful API should work. These articles make all sorts of claims about how the return type of the data should only be set in the request headers, how the obscure “PATCH” HTTP method should be used, and how doing XYZ does not follow HATEOAS. The problem with these discussions is they propose solutions that are more academic than useful.

I have a response to all of this - ENHANCE YOUR CALM!

Let’s take a step back and think: What is the real purpose of creating an API? The “real purpose” is to increase your user base by making it easy for developers to plug into your system. How does an API accomplish this? By making it simple for developers to integrate with your systems and build awesome applications on top of your systems through all of the functionality you provide. If you make people jump through too many hoops to use your API, they might just not use it – and you get zero new users from that. As a developer who has been building and consuming APIs for several years now, I have found the following rules to be practically (not just theoretically) useful for both the development and consumption of an API:
Continue reading…

comments (25)

Project Hydra – Scaling an API Globally



Posted on April 10, 2012 by Larry

At AppNexus we provide our clients with a RESTful API that allows people to manage all of their data in our adserving echosystem.  The API is built on a LAMP stack with memcache sprinkled in to help out with session management and cacheing some commonly used objects.  We have the typical cloud backend with various servers behind a load balancer with all of our servers housed in our East Coast data center.

When the time came for global expansion, we needed to spool up instances in our West Coast and European data centers.

Our Expectations:

Using our cloud backend, we could just spool up some virtual machines for Apache, memcache, and MySQL slaves replicating from the master in the East Coast.  GET requests to the API will use the local MySQL slave and memcaches while POST/PUT/DELETE calls will go to the master database in the East Coast. Pretty damn simple, right?

Wrong!  You didn’t think it would be that easy, did you?  
Continue reading…

comments (1)