API days London: day 1 roundup

by Dan Cutting

The API days London event is running today and tomorrow (September 23rd and 24th, 2015). This is a conference about building public and internal APIs for the Banking, Finance, Insurance, and Payment industries.

The venue is Level39, a technology accelerator based on level 39 of the One Canada Square building at Canary Wharf. The view is amazing!

There were 300 attendees today; it is completely sold out. Most are suited and booted. There are two starkly divided styles of slides: the first is video-peppered, meme-heavy, API-ing-all-the-things; the second is staid and dense. I suppose this isn’t surprising given the conference sits at the intersection of corporate banking and agile, disruptive technology.

This is a conference sponsored by tech. companies that have built platforms for managing, deploying, and testing “APIs” for the “developer economy”, so I’m not surprised to find most of the talks pitched to the decision makers within banks.

That said, I came away learning something from each talk today. Although there was a “technical” track and a “business” track, both were quite focussed on the business side.

As an outsider to the banking industry, it is fascinating to catch a glimpse of some internal machinations and hand-wringing. Today’s overall message was essentially “for god’s sake, you’d better turn your bank into a platform, because the low-friction, no-baggage challenger banks are almost here, and they’re going to eat your lunch”.

Highlights from the day

Gartner’s Kristin Moyer gave the first keynote:

  • “Programmable business models” that let people and “things” create their own bank
  • Nice example of a vending machine that is its own “Profit and Loss” centre, operating as a micro-business using banking APIs, and offering other services like cash dispensing to improve its individual financial situation

AXA Banque’s Arnaud Lauret gave an engaging and funny keynote:

  • ROAST APIs: services built by SOAP people who’ve only vaguely heard of REST (200 OK!)
  • The dude abides” style of hypermedia: API responses should include links to next actions, including those that shouldn’t be invoked along with the reason why not. A nice twist on “traditional” hypermedia

Akana’s Sachin Agarwal pointed out the importance of walking before you run:

  • Publish, share, and use common services internally
  • Make searchable catalogues of the services you make
  • Run internal hackathons to discover what’s really useful and to build enthusiasm
    • (This was a common theme throughout the day, the main gist being that you should provide pizza and beer, and should not bastardise the purity of the hackathon by exploiting your developers.)

Alfa-Bank’s Aleksandr Tarasov made the case for Docker:

  • If a container fails, it’s because the team that built it failed to build it properly (not an ops problem)
  • Freedom to try new technologies

Liam Ó Móráin’s talk was refreshing and frank:

  • Retail banking sucks for the customer
  • Compliance and regulations need to be kept buried, not exposed to customers
  • But banks have huge customer bases with low churn and lots of data which could be appealing to developers if they’d only make a good platform

Mike Kelly, creator of HAL, was one of the main reasons I wanted to attend the conference. (HAL is a terrific hypermedia format for web services.)

  • Treat developers well and they’ll repay the kindness
  • Developer sites should be built like any public website: employ designers, A/B testing, SEO, etc.
  • Provide sandboxed APIs that don’t need authentication

Ronnie Mitra spoke eloquently about some guiding principles for API design:

  • Every design decision trades flexibility for usability
  • Be forgiving: can you provide an “undo” feature?

Carlo Longino implored us to ask ourselves why we want to build APIs: what do we want developers to actually do with them?

My favourite speaker of the day was probably Irakli Nadareishvili, who gave an engaging and somewhat technical talk about microservices in practice, and data decentralisation in particular:

  1. Think of capabilities, not data models (bounded contexts from DDD)
  2. Consider event sourcing & CQRS
  3. Sagas are one antidote to the “this needs to be atomic, but can’t be if we use microservices” argument
    • E.g., a travel agent booking a flight, hotel and car: they all need to succeed or fail together
    • Do car rental step first which completes, but includes a link to a “compensating transaction” which can be used to roll back if the hotel or car booking fails

Are you attending the conference? Comment to @dcutting!

Hi, I'm Dan Cutting. I mainly write Swift for iOS but love working on Mac apps, web APIs, and programming languages too.

Follow me on Twitter, Micro.blog, or GitHub or subscribe to the feed.