Austin API Summit 2019 Wrap Up

In May 2019, Nordic APIs hosted the 2nd annual Austin API Summit. This year, we had two tracks with over 40 speakers presenting on advanced API platform strategies. Compared to last year, the Austin API Summit doubled in size!

We’ll be uploading speaker sessions to YouTube here, and slides here. For now, below are the major takeaways from sessions I was able to catch. It’s by no means comprehensive, but I hope it highlights some key points. Stay tuned for in-depth features on the blog in the coming months. Thank you for a fantastic Austin API Summit!

API Design

James Higginbotham reminds us that Roy Fielding himself recognizes that while REST is great, it’s “not optimal for other forms of architectural interaction.” James says platforms should be open to adopting a combination of multiple API design styles, like gRPC, GraphQL, and REST.

“Our enterprise platforms are starting to grow… now we have to decompose things into business and technical capabilities that represent what our business does” -James Higginbotham

Before enterprise platforms become entrenched in a certain technology, they must think of design outcomes. James recommends an API-design first mindset that relies on empathy to solve and predict developer issues.

Boris Vernoff from ADP presented on how API specifications can drive the entire platform infrastructure. Most know ADP for its corporate payment processing, but its offerings encompass more than that; ADP has been transforming into a platform itself to offer SaaS.

ADP once had many conflicting API design styles like Swagger, Open API, JSON formats, and napkin notes (jk). They consolidated with JSON Schema to define their APIs, and Boris recommends others consider using it too.

“We’re heavily invested into JSON Schema; it describes everything” -Boris Vernoff, ADP

API Platforms

We also witnessed some interesting API platform case studies. One is industrial manufacturing. In his presentation, Matt Boyle from Shapeways described how we’re on the cusp of a new industrial revolution, powered by cyber-physical systems and on-demand 3D printing.

APIs in industrial manufacturing can leverage APIs for monitoring and reporting, to initiating builds, generate alerts, and much more. It turns out Industrial IoT uses much automation and modular components similar to microservices. As Matt says, “these are not the same industries but they do rhyme.”

What is API management? According to Karthik Krishnaswamy of Nginx, API management seeps into every single aspect of the API lifecycle; from security to monitoring, traffic management, and onboarding at the developer portal.

API Strategy

Anjana Fernando of WSO2 describes how platforms have become more desegregated and distributed. Nowadays, everything is designed as an endpoint to better work with business logic. This is powering a great number of microservices and serverless functions. Anjana recommends micro-gateways as a means to develop APIs with greater agility. To this end, WSO2’s new Ballerina programming language aids this process.

Gareth Jones, API Architect, Microsoft, isn’t completely convinced that contracts like OpenAPI Specification are tight enough. He asks: what even does breaking change mean?

“Our current API specifications have a lot of room for interpretation in term of behavior” -Gareth Jones

What it comes down to is supporting a provider-consumer model. A contract gives you a foundation to build upon, however, it might not be enough. You want your app to work in production and fail in development, not the other way around. To mitigate API unpredictability, Gareth recommends the following API testing techniques:

Providing a “chaos mock endpoint” to stretch every boundary case
Randomly disobey client requests to see what happens
Closely following logs and go deeper than watching error codes
Define what breaking change means to your organization

According to Asanka Abeysinghe of WSO2, agility is everything. To that end, he feels like an API-centric architecture is critical for driving both an internal control plane and data plane, global mesh, and local meshes. When it comes down to API style, Asanka recognizes that with the rise of event-driven protocols and streaming, REST isn’t enough:

“It’s not just about request and response; we have passed that level.” -Asanka Abeysinghe

Serverless sounds great, but it may not be the right strategy for every microservice. Jonathan Peck, a Nordic APIs veteran speaker, showcased backend operations for machine learning APIs. When it comes to machine learning, serverless function providers may not be optimized for machine learning languages, segmentation styles, dependency support, and other nuances. He notes that model-hosting solutions are more optimal than traditional serverless environments.

API Security

Jacob Ideskog from Curity feels like API security gets a bad rep. Though security is a concern, it shouldn’t be viewed as a pest, rather it should be viewed as an enabler.

Jacob’s view is that identity is the secret glue to hold all platform security together. To balance agility and reusability, he reminds us to consider a quote from the founder of Unix:

“Write programs that do one thing and do it well. Write programs that work together.”

Jacob advocates for reusable microservices components that are built on open standard components. At Curity, Jacob calls it the Neo Security Architecture, which combines an authentication service, token service, federation service, user management service, and user repositories.

Francois Lascelles from Ping Identity followed this with a sobering fact – you’re probably being breached right now. Breaches can go undetected for years; take the recent Marriott breach as a recent example. It went undetected for 4 whole years!

“API security matters. You are being breached. And AI can be applied to augment that foundational API security” -Francois Lascelles

Francois notes that if you’ve put a modern sheen on a legacy service, you are more likely to have a vulnerability in your application that your team is unaware of.

API Testing

Constant testing and monitoring is necessary to maintain API security. In his presentation, Richard Porter from IBM used a simple mantra to remind API practitioners they must both vet the API and the tools used to monitor them.

“Inspect what you expect” – Richard Porter

Patrick Poulin from API Fortress wonders if we’re even asking the right questions when it comes to API testing. For context, he recited a few hilarious gaps in API security. One eCommerce shop’s ordering API was so open that anyone (with minor coding experience) could edit the “discount” field in a POST request to 100%, essentially allowing them to buy anything they wanted on the store for free.

Hacks like this, among many others we see news, aren’t really “hacks.” They’re more of a gap in the API logic that was poorly designed. To avoid such holes, Patrick recommends creating functional tests for every endpoint. Keith Kasey, API Problem Solver at Okta, recommends we think like the “Bad Guy” to imagine every possible way someone would terrorize your API.

API Marketing

We’re still seeing developer experience a top concern for adopting the API-as-a-Product mentality. In that ilk, James Messinger from Shipengine focused on how we can increase the usability of our API documentation. He defines 4 types of documentation that API practitioners should implement: Tutorial, How to Guide, Explanation, and Reference.

He adds that techniques like a Postman button, OpenAPI support, JSON Schemas, SDKs, SEO discoverabiliy for dev portals, and more will help you meet developers where they are, optimizing your developer-facing channels. Since native environments need SDKs, Jason adds that your real product might actually become the SDK, not the API.

Developer outreach is also an important tool for growing the platform. Karen White of BigCommerce argues that if you are listening to developers and repeatedly see workarounds (something they call a Texas Exit in, you guessed it, Texas), they may be trying to communicate something to you. Collect developer feedback when possible, and look to where your developers are using workarounds to embrace and improve your solution, rather than deny and govern.

How do we ensure developers can even discover the APIs we produce? In his session, James Higginbotham notes that capturing the metadata around API specifications could help drive discovery of APIs within an organization. Especially since some organizations could have 10s of thousands of APIs, tools like APIs.json or DISCO could help drive internal API discovery.

API Business

Marco Palladino from Kong notes that the business is the true driver for decomposing the monolithic architecture into microservices.

“Refactoring a monolith is an activity that unlocks team productive and business scalability.” -Marco Palladino

API business expert Alan Glickenhouse of IBM even foresees the business team eventually driving all API initiatives. However, most API providers still need more guidance when it comes to business strategy.

When Alan meets with clients, one of their most common questions are what goes into creating an API business strategy? and why would we do this? Well, when it comes to API economy business drivers, Alan sees benefits in speed to market, expanded customer reach, innovation, and domain utility. He sees mobile and data internal APIs as a very common first start for digital transformation and sees public & partner APIs coming later on in the journey.

Alan predicts that business will soon lead API development, similar to how business eventually took the reigns from IT to drive the Web. When asked what year this will occur, he replied that separate sectors will jump at different timelines.

“If you’re resisting APIs, you’re behind” – Alan Glickhouse

We’re seeing growth in digital ecosystems, impacting how B2B is handled. Alan foresees a future where business relationships are automated with more self-service. Essentially, the ecosystem authority to consume B2B APIs will supersede discussions with partners over the phone.

2019 Updates & Reminders

Thank you for a great Austin API Summit! Huge thank you to all our speakers for the high quality, illuminating talks. Thank you to the attendees (local, and global) who made it out. Thank you to our venue, great A/V crew, and to the organizers and sponsors that made it possible. Hope to see you and many others return to the Austin API Summit in 2020!