{"id":489,"date":"2012-01-28T16:15:15","date_gmt":"2012-01-28T21:15:15","guid":{"rendered":"https:\/\/danieljacobson.net\/blog\/?p=489"},"modified":"2024-09-07T11:35:53","modified_gmt":"2024-09-07T15:35:53","slug":"netflix-engineer-daniel-jacobson-the-api-at-the-root-of-your-business","status":"publish","type":"post","link":"https:\/\/danieljacobson.net\/blog\/489","title":{"rendered":"ReadWriteWeb : Netflix Engineer Daniel Jacobson: The API at the Root of Your Business"},"content":{"rendered":"\n

This article originally posted by Scott Fulton on ReadWriteWeb on January 28, 2012<\/a><\/p>\n\n\n\n

The first place I had ever seen an API actually at work was as part of an operating system. It was a strange OS at that, a permutation of CP\/M that used a graphical front end called GEM, which would later be ported to the Atari ST. The definition was explained to me like this: An \u201cinterface,\u201d as everyone knows, is a specification for how electrical components interconnect. Well, now it\u2019s possible for an application program \u2013 the part that does what users need \u2013 to interconnect with the operating system, which does what the computer needs. This way the operating functions don\u2019t have to be built into every program, they can just be handed off to the OS and the connection will look seamless. The principle was called a layer of abstraction<\/em>. It was 1984, and it was the first time I\u2019d heard the term.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

It would be wrong to call the concept \u201crevolutionary,\u201d unless you measure time in units of eons. Nearly three decades after its introduction, only recently have businesses come to realize how widely this architectural principle could be applied. No longer do complex processes have to be bound to precise, policy-intrinsic procedures. If teams can work independently, and computer resources devised to suit each team individually, then all that needs to be specified is the exchange of information between them.<\/p>\n\n\n\n

So it is that a software designer ends up becoming one of the public faces of the ideal of API architecture as a business tool. Daniel Jacobson is the lead API engineer for Netflix \u2013 arguably the largest single consumer of bandwidth on the entire Internet. His O\u2019Reilly book, APIs: A Strategy Guide<\/em><\/a>, co-authored with Apigee CTO Greg Brail and research editor Dan Wood, deals with the implementation of APIs not so much for software\u2019s own exclusive purposes, but moreover as a means of realigning and renovating business\u2019 resources overall.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

\u201cAPIs should not be geeky \u2018science projects,’\u201d reads the first paragraph of Chapter 4. \u201cThey are critical business tools. Successful APIs need clear objectives that relate directly to business objectives and track closely to key performance indicators for the business at large.\u201d<\/p>\n\n\n\n

More open on the inside<\/h2>\n\n\n\n

We\u2019ve written here in ReadWriteWeb in the past about the value of APIs in providing transparency and accessibility to businesses, mainly through enabling them to develop mobile apps that connect more directly to their customers. Jacobson has a different perspective, which derives from his experience with Netflix, and earlier as the creator of the API for NPR. It was in 2002 that Jacobson and his NPR team made discoveries that he describes as part logic, part luck.<\/p>\n\n\n\n

\u201cAt that time, a lot of publishers would be buying these CMSes, off-the-shelf products like Interwoven or Vignette,\u201d Jacobson relates to RWW. \u201cAnd the flexibility, and the opportunity for thinking in these [new] kinds of ways, was somewhat limited.\u201d<\/p>\n\n\n\n

Subsisting sometimes from month to month on public and government funding, NPR didn\u2019t have the budget to go big and invest in a colossal, support-intensive CMS like Vignette \u2013 an investment which, at that time, often cost bigger businesses tens if not hundreds of thousands per year, after including maintenance costs. Faced with no other obvious option, NPR was forced to go it alone, building its own CMS. And in recognizing the need to maximize its efficiency, Jacobson and his colleagues decided that their system had to be designed from the beginning to be flexible enough to publish to any platform, including those that had not yet been created.<\/p>\n\n\n\n

So NPR adopted a design philosophy called COPE: Create Once, Publish Everywhere.

\u201cThat was the really fortunate decision that we made\u2026 We didn\u2019t think about iPhones and tablets, and things like that, in 2002. But we were thinking that we could imagine a case somewhere down the road where the Web site would need to change again<\/em>, or we\u2019re going to do another redesign\u2026 It was really important for us to have this COPE model, so we can actually capture all the metadata that\u2019s important to us in a very modularized way so that, regardless of what the display is going to look like, we can publish to it very easily. So conceptually, we separated the idea of capturing the data from presenting the data.\u201d<\/p>\n\n\n\n

It was NPR\u2019s first abstraction layer<\/em>. But it was not yet an API, mainly because the CMS and the database were still tightly bound. To this day, businesses that invested in content management systems around the year 2000 are wrestling with the headaches of data portability, because their CMS is too tightly bound to its database, and the database has become a rusty, misbehaving vault.<\/p>\n\n\n\n

The interface as publishing<\/h2>\n\n\n\n

It was 2007. While NPR had a system that could publish anywhere, the create-once part was giving it problems. The creation was becoming a frightful mess.<\/p>\n\n\n\n

\u201cIt was that moment in 2007, I think, when we said, we\u2019ll need another abstraction layer to separate out the direct access from the presentation layer to the database, even though we had conceptualized them as being different, that binding to the database was still there. That\u2019s when we created this new abstraction layer of the API, and shortly after that, [we realized] we could open this thing up quickly.\u201d<\/p>\n\n\n\n

The process of integrating the abstraction layer was entirely internal, and its goals were focused on how NPR could retool itself. But in making that change, the organization realized it could effectively publish<\/em> the benefits of that abstraction in a way that was entirely in keeping with the goals of its COPE methodology. Dan Jacobson tells us that, in this phase of the project, he incorporated another important ethic, this time straight from the world of broadcasting: Know your audience. More specifically, build each component of the system in tune with the needs of its consumer.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

Jacobson\u2019s API project enabled NPR to publish stories and excerpts through its own cross-platform app, entitled \u201cInfinite Radio.\u201d<\/a><\/em><\/p>\n\n\n\n

Jacobson\u2019s book suggests that more businesses either nurture or hire someone who can serve as the technologist<\/em> for their company, and make it this person\u2019s job to know the audience \u2013 to understand how data is being consumed and who is doing the consuming. \u201cAnd then understand what abstraction layer, like an API, needs to be put in place,\u201d he explains, \u201cto basically be the glue between the capturing of the data and the presentation to its users.\u201d<\/p>\n\n\n\n

One term Jacobson often borrows from the software development world and applies to the business world is context<\/em>. He uses it to mean the breadth of a person\u2019s influence in the company, and there are reasons that influence may be limited. But only through understanding the different contexts of business units, he feels, can a developer build an API that enables them to interoperate.<\/p>\n\n\n\n

\u201cPublishers are thinking about how can they create an organization that will put them in a position for this kind of rapid growth,\u201d Dan Jacobson continues. \u201cAt Netflix now, we have several hundred devices running off our API. Many publishers of various kinds would love to have that kind of distribution. You need your technologists in a position to have the context and the trust of the superiors, and basically everybody on board with making smart decisions and allowing them to execute. The larger the company sometimes, the more bureaucracy there is, and the more they need to have these discussions. They\u2019re basically, potentially, shackling their people\u2026 Here, you\u2019re putting them in a position to make decisions for you.\u201d<\/p>\n\n\n\n

Fate has an interesting way of making itself appear coincidental. Had NPR not been so constrained by its own budget limitations, it might never have hired the team that designed their CMS and that implemented COPE in the first place. And it might still be bound by the same tight, complex information architecture that binds so many bigger commercial enterprises to this day.<\/p>\n\n\n\n

\u201cI think it\u2019s the confluence of a range of things \u2013 the financial restrictions, having good people, good context, good control of the situation, and making smart decisions \u2013 and a little bit of luck,\u201d says Jacobson. \u201cWe could have made some smart decisions at the time that weren\u2019t quite as lucky down the road. We were very fortunate.\u201d<\/p>\n","protected":false},"excerpt":{"rendered":"

This article originally posted by Scott Fulton on ReadWriteWeb on January 28, 2012 The first place I had ever seen an API actually at work was as part of an operating system. It was a strange OS at that, a permutation of CP\/M that used a graphical front end called GEM, which would later be […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,97,60,34,61],"tags":[54,73],"class_list":["post-489","post","type-post","status-publish","format-standard","hentry","category-apis","category-article","category-engineering","category-netflix","category-technology","tag-api","tag-readwriteweb"],"_links":{"self":[{"href":"https:\/\/danieljacobson.net\/blog\/wp-json\/wp\/v2\/posts\/489","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/danieljacobson.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/danieljacobson.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/danieljacobson.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/danieljacobson.net\/blog\/wp-json\/wp\/v2\/comments?post=489"}],"version-history":[{"count":2,"href":"https:\/\/danieljacobson.net\/blog\/wp-json\/wp\/v2\/posts\/489\/revisions"}],"predecessor-version":[{"id":610,"href":"https:\/\/danieljacobson.net\/blog\/wp-json\/wp\/v2\/posts\/489\/revisions\/610"}],"wp:attachment":[{"href":"https:\/\/danieljacobson.net\/blog\/wp-json\/wp\/v2\/media?parent=489"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/danieljacobson.net\/blog\/wp-json\/wp\/v2\/categories?post=489"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/danieljacobson.net\/blog\/wp-json\/wp\/v2\/tags?post=489"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}