API Longevity, Devious Drones, and Bourbon: Insights From the 2016 Platform Summit Bill Doerrfeld October 28, 2016 A packed house for a Spotify presentation by Horia Jurcut at the end of Day 1 Over 300 API practitioners. 53 talks. 6 demos. 3 workshops. 3 days. Endless coffee. Sound familiar? If you’re into APIs and were in Stockholm this week you were probably experiencing the 2016 Platform Summit — the Nordic region’s largest web API event to date. For this three day event we brought some of the most dignified API (Application Programming Interface) thought leaders together under one roof to discuss the digital transformation of modern enterprises with APIs. Roy T. Fielding once described REST as API design on the scale of decades, and the 2016 Platform Summit aimed to expand this idea, asking: how should API practitioners architect and design long-lasting APIs that stand for decades? Overarching theme: API Longevity. Speakers from Google, Microsoft, Airbnb, Spotify, Volvo, and other companies graced the stage, offering broad insights into API scalability, future reliability, and use case assessments of fine grained technologies like microservices, GraphQL, serverless architecture, and so much more. In the upcoming weeks and months, we’ll dig deeper into many of the talks with dedicated blog pieces, but for now, we’ll highlight the major lessons communicated at the conference. So let’s take the long view and see what was learned from the viewpoint of each API Practice Insight: API Platforms Zane Claes of Airbnb discussed consolidating their backend with API v2 An API-first methodology can accelerate business Zane Claes described the transformation of the Airbnb backend, from one consisting of two parallel tracks — the web controller and APIv1 — into a single “Graphist” API v2, in effect increasing platform-wide internal efficiency and reusability. Adopting a single API backend can amount to tremendous cost savings for a business in a similar situation, avoiding scalability bottlenecks as a platform evolves. Turn to automotive grade APIs for a lesson in longevity Software engineers at Volvo need to accomplish the unthinkable — they literally need to design web APIs that last for 30–40 years. For engineer Henrik Segesten, this means that longevity is a top concern. Software for IoT products (especially automobiles) must be backwards compatible to last for decades within the market, meaning that any change must be pushed to the server, and calls made consistent as versioning occurs. Use Bimodal IT to allow the “Castle” to decay and new code to grow Erik Wilde of CA Technologies described longevity as the need to build scalable systems with scalable interfaces. He contrasts this with the futility of Franz Kafka’s The Castle — a metaphor for how not to conduct API growth, perhaps. According to Wilde, Bimodal IT can preserve existing architecture so that over time, parallel development allows monolithic legacy code to stagnate, and new code growth to replace it. API Design New design trends will continue to affect how APIs are consumed A lot was said on design concepts. Speakers conveyed ideas on microservices choreography, GraphQL usage, the deconstruction of REST principles, decoupling hypermedia from the data response, and integrating API definitions like Open API specification into the API lifecycle. Whether it is a shim in front of microservices, or a more intuitive GET method call, the API access method is constantly re-envisioned to respond to architecture redesign and usability concerns. Jason Harmon at the Platform Summit 2016 Check out serverless backends Another clear trend this year was serverless backends. Both Peter Drougge of Microsoft Azure and Rich Jones of Gun.io discussed how to build serverless backends — which are essentially impermenant servers created in response to events. For Jones using AWS Lambda + AWS Gateway, no permanent infrastructure means no load balancing, security patches, no downtime, and no worrying. This event driven, reactive process is great for scaling microservices, and could signal a paradigm shift for traditional Ops. So which server provider is best for this? The debate is open. “Rather than maintaining machines to poll your event sources, use cloud services to respond to them.” – Rich Jones, Gun.io We are sliding away from Roy Fielding’s REST Model, but don’t feel guilty about it Fillippos Vasilakis believes that we are moving away from Fielding’s initial REST model, but we shouldn’t be ashamed of it. To Vasilakis, delivering true hypermedia APIs at runtime is simply not worth it. Providing hypermedia information (available attributes with data types, links with URI templates, and available actions) is complex, can causes performance issues, and could be completely useless information to the client. What can we learn from this API introspection? Separate hypermedia and documentation from actual modeling and offer hypermedia on demand. GraphQL, GraphQL… Did we mention GraphQL? The RESTful inquisition continued with speakers evangelizing the query language GraphQL. Joakim Lundborg of Wrapp impressed audiences by building an API that scrapes data from the Nordic APIs Platform Summit speaker page, inserting a GraphQL layer that made queries easily filterable by things like speakers, Twitter handles, company, description, talks, title, or time. Joakim and other speakers, like Zane Claes of Airbnb, demonstrated how GraphQL is being used at their companies to interface with APIs very easily. Audrey Neveu on Web Sockets and IoT API Polling, Web Sockets, and a devious drone Audrey Neveu demonstrated a code-heavy talk on Server-Sent Events vs. Web Sockets. Her code consumed Bitcoin data, and in turn affected the elevation level of a drone — a real life IoT experiment. Unfortunately, this devious drone doesn’t work on poor hotel WiFi throttled with hundreds of eager API fans. #lessonslearned Devious drone for sale! Bidding starts at 10 SEK @Audrey_Neveu #nordicapis pic.twitter.com/StnMrsOPDJ — Nordic APIs (@nordicapis) October 26, 2016 Warp into the API galaxy with the Open API Specification The Open API Specification (Swagger) is a robust tool that API Handyman believes API providers should be implementing. With Spockian delivery, the API Handyman (Arnaud Lauret) took us on a voyage through the benefits of using the Open API spec: Testing, ensuring consistency, checking security, allowing continuous delivery, and other features make API Fastness the logical conclusion to using Open API. API Security Protect the transport layer Within scary truths of cyber terrorism, hacking Pokemon Go, and forecasting identity management within the IoT, we witnessed real life cases that presented ample reason to invest in modern API security measures. A common thread from our security presentations this year was protecting the transport layer. You are your data Nordic APIs author Kristopher Sandoval presented a sobering reminder that terror groups, non-affiliated hobbyist hackers, as well as entire nations are engaging in cyber terrorism and espionage, motivating all API providers to fix code issues, test APIs, and decrease code vulnerabilities. Prevent reverse-engineering by planning for success The perpetrator isn’t always evil. The Pokemon Go case study is another reminder that attackers could be non-violent users who want to manipulate data for personal in-app rewards. As reversing an API is a means to do this, savvy users will find a way to do so if certain features within mobile apps, like GPS, aren’t made unalterable. For David Stewart of CriticalBlue, planning for success is necessary in order to scale API security. Build with open standards for everlasting IoT In tune with the event’s theme of longevity, Travis Spencer of Twobo Technologies forecasted 13 years into the future, predicting the widespread use of driverless cars, drones, biotech, 3D printing, and more in the year 2030. Though current devices will become obsolete as new ones emerge, what will always remain vital to securing these systems is knowing who is interacting with them. Travis Spencer of Twobo Technologies “Identity is fundamental to these IOT paradigm shifts; We need to know who it is that we are talking to.” For a lasting API security architecture, he recommends building upon open standards like OAuth, SCIM, JSON, and OpenID Connect, and allowing the neo security stack to adopt subtle changes as open standards mature. Use Attribute Based Access Control (ABAC) for federated authentication Securing the federation of permissions across a platform of microservices is extremely important; it brokers information in a cryptographically secure way. We saw an example of fine-grained access control with the Axiomatics policy server in conjunction with the CA API Gateway. We also saw Jacob Ideskog present the fastest OAuth integration ever — in 5 minutes — showcasing the power of Curity.io to provide an access control mechanism. API Business Don’t view APIs as a science project anymore Nordic APIs veteran Rob Zazueta believes that business and developers need to sync — APIs can’t be seen solely as an IT project anymore. As platform strategy and business direction will affect the end technical result, API technology has truly become “everyone’s responsibility,” meaning that teams from all angles need get a little friendlier. Rob Zazueta of TIBCO “If you give a developer bourbon, they become your best friend for life.” ROI is more complex than traditional dollars and cents Rob also reiterated his 5 potential business models, including charging for access, adding value for upsells, and driving revenue generating activities. However, once you transform into a platform architecture, you can leverage strategic partnerships and improve operational efficiency as well. Essentially, maximizing every opportunity to leverage the freedom of your data. In practice, we saw how Spotify’s payment infrastructure echoed the benefits of smart APIs for internal efficiency. API Marketing Serve developers a piece of the pie, not the crust What is an API that doesn’t get eaten? A very sad API. The way you encourage developers to use an API is extremely important. Seasoned developer advocate Adam Duvander of Zapier recommends highlighting what your API allows, not the functionality it entails. It’s not what your #API does, it’s what it allows other devs to do. Share knowledge not features. @adamd @nordicapis pic.twitter.com/PhIDukyiXV — Bill Doerrfeld ⚙ (@DoerrfeldBill) October 26, 2016 To create an online community, you must be the one to ignite discussion Shopify’s unflinching focus on developer experience has resulted in a very positive return for the platform, but Shayne Parmelee expressed that getting there has been a learning curve. 1–1 support, 100% community support, nor gamification completely did the trick. What worked was when his developer experience team began posting 200 posts per month in their own forums, leading to a 48% activity increase and bevy of new users. Maintain an excellent developer portal and resources Don’t take inspiration from the Library of Babel, the hypothetical library including every infinite permutation of the English language. Rather, have easy to find, easy to use documentation. Shopify’s beta API releases are fed into a feedback loop with a use-case-specific group of developers, enabling them to discover edge cases and nuances which in turn improve documentation. Elon Musk says: lesson jargon, cut the acronyms Oscar Santolalla taught us how to pitch an API without using too many contagious jargon or acronyms. To Santolalla, great API demos have a story arc, demonstrate shared values, provide live coding mastery, and have audience interaction. API Strategy Rethink your versioning strategy for maximum internal efficiency Instead of adopting a typical versioning strategy, such as api.example.com/v2/orders, Konstantin Yakushev explained how Badoo uses a continuous versioning strategy. Though beneficial for client developers and internal backend developers, our Q&A discussion found that this may not be an ideal method for public API providers. Improve your Microservices architecture with asynchronous APIs and Test-Driven Development Francisco Méndez Vilas of Hitch described how using a message broker can help choreograph your microservices to create asynchronous APIs. Nordic APIs veteran Jason Harmon described a shim for Backend-for-Frontend (BFF) to better interact with underlying microservices. Treat an API as a product, no matter if it is Private, Partner, or Public Though Airbnb’s API is internal, since they have a wide array of developer users, they still had to think of developing the API as a product. A part of this, for them, means having public-esque developer tools, like a developer sandbox, as interactive modes are most effective for testing even with inward stakeholders. Platform Summit Wrap Up Thank you for making this our best event to date! These were only a handful of the many many experiences shared at the conferences — more included analysis of specific sectors, like EU data regulations, FinTech and the rise of open banking, transportation in the IoT, and more. Thank you very very much to our superb speakers and attendees — we had zero speakers back out and had less than 5% attendee no show — out of 300+ people, that’s pretty amazing. Of course, we cannot produce events of this caliber without our sponsors — a very big thank you to CA Technologies, TIBCO, Apitek, Axiomatics, Axway, Microsoft, and Teks mobile for your participation! Download the free companion Platform Summit eBook! The core insights from this conference were compiled into an eBook entitled API Design on the Scale of Decades. It’s free to download directly from our site HERE. Or, name your price on Leanpub or purchase it through the Amazon Kindle store. As always, any proceeds from this Nordic APIs eBook benefits the Salvation Army in Sweden. We hope that attendees walked away with new insights that allow their developer programs to live long and prosper. If you are so inclined, please help us improve our next Summit by filling out our attendee survey. We expect much more to come with Nordic APIs, so if you haven’t yet, follow us, and sign up to our newsletter for curated blog updates and future event announcements! You can also view speaker session videos from this conference on our YouTube channel. Awesome Reactions Great talks, great attendees and a fantastic team @nordicapis … Many thanks for those extrordinary two days! See you soon I hope ;) — Audrey Neveu (@Audrey_Neveu) October 26, 2016 Impressive turnout at #nordicapis https://t.co/0RDQPObk2S — api_lifecycle (@api_lifecycle) October 27, 2016 Excellent workshop today, thanks to @nordicapis and the guys from Twobo Technologies! Contactlab was there… #nordicapis — psantori (@psantori) October 24, 2016 Extra: (un)Buzzword Table Was this your first API event? Jargon can be difficult, so we thought we’d help you out with more relatable definitions. Please help us build this knowledge base by suggesting other concepts and/or interpretations in the comments below. Buzzword Definition Twilio The trigger word for most API conference drinking games Microservices Really small lemonade stands you can only see through a microscope Attribute Based Access Control (ABAC) Some type of club bouncer that only lets you in if you have certain personality traits API Stands for American Petroleum Institute or Active Pharmaceutical Ingredients Backend-for-Frontend (BFF) This one just sounds a little dirty. Serverless A very destitute bar or restaurant GraphQL An old, outdated, monolithic programming language that not many people are talking about anymore. I think it’s a COBOL framework? Platform Summit An industry wide event typically held on a tall diving platform Bimodal IT A bicycle repair shop that can also fix your cracked iPhone screen SaaS ?