It is easier than ever before to build complex web applications. But developer tooling for understanding, testing, and maintaining these systems has not caught up. Something I heard over and over again when starting Akita was that developers could log, measure, monitor, but they have a hard time understanding what was really going on with their software systems. A major challenge comes from the fact that modern web applications run across many heterogenous components, often communicating via remote procedure calls. Current software analysis methods do not work here, as network calls across heterogeneous components subvert language-level modelings. And using network tools alone do not yield the full picture. The result is that developers end up piecing the whole story together through reading code, logs, and documentation. At Akita, we observe that network-based application programming interfaces (APIs) are both a root cause of what we call the Software Heterogeneity Problem—and also the key to the solution. The proliferation of APIs for both internal and external use, with the rise of service-oriented architectures and the growth of the API economy, have made it easy to quickly build applications that are amalgams of cross-service network calls. At the same time, there is consolidation around a handful of interface definition languages for web APIs. This makes it possible for us to address the Software Heterogeneity problem by applying programming languages techniques at the API layer. In this talk, I will introduce the Software Heterogeneity Problem, show how we at Akita are solving this problem at the API layer, and outline API-level PL problems we can solve as a community.

The discussion and AMA for this talk will be moderated by Satish Chandra.

Hi there. I’m Jean. I started Akita because I wanted to build practical, principled tooling for modern software systems. I’ve spent my career in pursuit of better software tools. I grew up programming—and it felt like magic that a kid like me could just conjure software. In college, I fell in love with programming tools: helping people make magic faster felt like pretty much the coolest thing a person could do. This was why I got my PhD in programming languages, at MIT. After that, I was a tenure-track professor at Carnegie Mellon University. The whole time I was in research, I wanted to build tools that could majorly help practicing software developers. Early in my PhD, I got obsessed with two problems around this that I couldn’t solve using application-level techniques. First, the legacy software problem: you can’t just easily port most code to a fancy new language or type system. And even if you could, you run into the second problem: the heterogeneity of software systems. Modern software is an ecosystem, with your data stores, data streams, services, and third-party APIs. This is how I became obsessed with APIs: APIs let you encapsulate any code written in any language—and you can apply language design principles, just one zoom level up. This is why, while at CMU, I started doing research about APIs. This takes us to Spring 2018. Cambridge Analytica happened. GDPR was just about to come out. I realized that we were entering into a new era of software, where people were realizing that not having visibility or control over your software can hold you back in a major way. I called everyone on my LinkedIn who would talk to me and asked them about their tooling needs. When I realized there were big and interesting problems I was uniquely positioned to solve with my API tooling ideas, I just couldn’t miss out on the action. I took leave from CMU, sold my furniture, and drove across the country to the Bay Area to start Akita.