I put on my monocle and top hat and booked a ticket to London to attend my first conference. The topic of the conference was APIs, i.e. the stuff I develop and design at work. The trip took place in late April 2023 under the auspices of my employer, OP Financial Group. I attended a dozen or so lectures. What follows are the highlights of three of them.
The Myth of API Monetization - and How Companies Really Create Business Value With APIs
The first keynote I attended was on API monetization, which is a topic that has also been in the tech news lately. For example, Twitter has started to charge fees, and pretty hefty ones at that, for access to their APIs. For individuals, the price tag is \$100 per month. Access for enterprises costs \$42,000 per month. Ouch!
The lecturer, Matthias Biehl from API-University.com, advised against blindly following the big tech and aiming at this kind of direct monetization. Instead, one should look at the business model of a company as a whole and take it from there. It is more often the case that companies can make good money out of their APIs through indirect means.
Well, kind of obvious, I thought to myself. But then again, I started to think about the generic developer organization that is separated from the business end to its own unit — something I criticized in my previous post. Without visibility to production and not having compensation levels that reflect the bottom line of the business, the developers are in danger of adopting a “cost center mentality”. It is then very difficult to see how APIs can generate income.
This realization in turn made me rather grateful for the way our business unit at OP is organized. Stress-free it is not, but you get to see how a bank operates from a close range. It is basically a mental exercise in following the causal chain of money as it circulates in the economy. The agile demos we have typically involve a segment called the “latest figures” from the business side. Heck, nowadays I even know what “top line” means!
The lecture provided me with a nice closure to the debates I have had with my colleagues over the years. You see, there was a time when I wanted to design APIs for the sake of APIs. And I truly believed that we could profit from my work by simply going to some kind of an admin console and flicking a switch to charge the API clients as a kind of crowning achievement in the end. Then I learned that the situation is a bit more complex. Banking is a business built on trust, and a sure way to destroy it is to surprise the customer with stunts like that. On the other hand, a free solution can actually cause more harm than good, because it can start to cannibalize the business of a completely different business segment. But then, too costly APIs are not good either because they encourage API clients to cut corners and use non-compliant techniques like screen scraping.
The wisdom of banking APIs and monetization is: “Do not ever get between a man and his meal.” The purpose of APIs in finance, or in retail banking at least, is to lubricate the economy. When API-driven payments work well, the economy can run smoothly. And when the economy runs smoothly, companies make money. And when companies make money, they can actually pay back their loans instead of defaulting — the worry #1 for any banker. And when they pay back their loans, they pay it back with an interest — which is how a bank makes money.
Putting Yourself Out There - How to Secure Your Public APIs
The next lecture of interest focused on API security and was given by Dan Erez from AT&T. This is an important topic but a bit involved to explain in simple terms to the uninitiated. The difficulty is that the devil is truly in the details, and I’m afraid it’s only in my domain where security is really taken seriously.
The lecture highlighted some of the classic subtleties regarding exploitable code. Often it is a case of exposing too much data. This can mean either too much in the sense of violating the principle of least privilege, or too much in the sense of allowing clients to request for arbitrary amounts of data, thereby exhausting the server and causing a denial of service.
Other aspects of API security that were covered were the mechanisms by which we can harden our APIs. How TLS 1.3 provides Perfect Forward Secrecy is for example a nasty question I could ask in a job interview. How to implement mTLS is another. And finally there’s network level access control and network segmentation that are highly relevant topics in banking.
A particular highlight of the lecture was the mentioning of OWASP. If API security is a topic that you find daunting and too abstract, I definitely recommend checking out Checkmarx. It is a puzzle/reference app that provides you with a concrete examples of what vulnerabilities look like in practice.
We have worked hard to harden the security of our APIs. This is required already by legislation such as the PSD2 directive. I felt therefore relieved that our public APIs at OP tick all the boxes when it came to the best practices presented by Erez. This goes to show that “what gets regulated, gets done.”
A final and perhaps the most important aspect of API security has to do with the old adage “what is measured, gets managed.” If I was to audit an API, I would not focus on the code; I would audit the ways of working of the development team. You see, it takes keen eyes to spot a line of code that is exploitable, and it’s human nature to become blind to code. It therefore takes a joint effort by a team software developers to build secure APIs. Basically, you have to have the mindset of a baddie to be a goodie. Given that most teams cannot even agree on whether to use tabs or spaces for indentation, is it then any wonder that the products they ship are infested with security issues?
Browsers are the new containers!
The most interesting presentation of the conference was the second lecture by Dan Erez. It is pretty evident by now that going serverless offers some pretty big benefits in the world of distributed computing. For example, the vulnerabilities in the runtime OS are not really a concern of a software development team, and if the patching of the runtime images can be delegated to the cloud provider, it’s a win.
Yet, like I pointed out in my cloud native post, the contingencies of adopting the serverless paradigm are just too worrisome for any architect worth of their salt. A self-inflicted denial of service due to a vendor lock-in sounds just like the dystopian reality George Orwell could have written about if he had known REST APIs.
Using a Matrix meme picture, Erez then asks “What if I told you that you already have a free cloud?” The basic idea would be to leverage the existing compute capacity of a company by distributing computations to the workstations and laptops it already owns. Further, the computation would take place in the sandboxed runtime environment of the browser. After all, all devices have a browser and most devices are actually idle most of the time.
My immediate response was: “This sounds so wack it must be good!”
Erez pointed out the SETI project from the 1990s as an example where volunteers leased their computer for the search of extraterrestrial intelligence. He further painted a picture of a web3.0 world where we could get rid of the cloud providers for good. Instead, all clients in the network could participate in revenue sharing by leasing their computers to do the computations servers currently do.
Perhaps at this point it pays to read aloud the classic 8 fallacies of distributed computing to remind oneself what the issues are. It is perhaps also instructive to take a look at Roy Thomas Fielding’s original doctoral dissertation on REST Architecture, and how it specifically argues for a client—server model.
However, the idea of offloading computations to the client device is not completely without merit. I would water down the idea a bit, and tie the discussion to the architecture of the so-called ‘mobile super-app’. It is a mobile app that gets some its code dynamically from the back-end, and can for example act as a host for ‘miniapps’.
I was involved with such a P2P payment app some years ago. The contract was that the miniapps were written in JavaScript and would execute in their own React Native sandbox. The miniapps were versioned and could be independently deployed to the host app.
Sadly, the miniapps had limited use and we somehow could not realize their full potential. However, the basic idea remains interesting. Nowadays I could envision some kind of a “bring your own server” mobile app, that would be split to a frontend and serverless backend that would largely execute in the mobile app itself. I imagine an app that would receive an instruction stream from the server. Much like the OS syscalls, the server could instruct the app to execute serverless functions in the frontend. And like kernel code that executes in kernel context, the serverless functions could execute under the security context of the end user.
The offloaded serverless functions could be implemented in WebAssembly. The instruction stream could be implemented on top of a WebSocket connection.
The beauty of this approach is that not only is computation distributed but we would also distribute identity management. The user identity could be backed by a key pair whose private part could be stored securely on the mobile device, many of which have tailored hardware for this purpose. Network requests from the serverless functions could then be authorized using strong cryptography.
Going further, Erez’s lecture inspired me to think that web3.0 could be a thing in the end. It just got on a bad foot due to “cryptoshit”. If the user data would disappear once the user uninstalls an app, the user’s right to be forgotten would be trivially satisfied. I would also imagine that people would start to treat their data much like physical currency. I do not know about you, but I would actually find this a positive outcome.