What APIs can and cannot do
Erik Wilde kicked off with his presentation titled ‘What APIs can and cannot do’. In his view, APIs are just packaging. His favorite metaphor is beer. You can change the packaging from tin cans to glass bottles, and you may even taste the difference, but without the beer the packaging is useless. You get the idea, even this early in the morning. Yes, there are many benefits that APIs can bring, but if you think about it more deeply, many questions still have to be answered. Personally, I would expect we are beyond the point of inflated expectations, and reaching the plateau of API productivity (indeed, this conference also didn’t escape the omnipresent Gartner hype cycle).
Serverless first mindset
Next, Jared Short had an interesting presentation about a serverless first mindset. If you have a use case that you cannot implement with serverless technology, you just have to think harder. There’s always a way. Yet, this is no excuse for building anything that can be used from other sources – the cloud (Connext, anyone?), or off-the-shelf solutions. Also, a thing that starts simply, over time tends to gain so much complexity that having it sourced would have made much more sense with hindsight. This is one of the most prominent root causes of serverless failure. So, the lesson is: always think a couple of steps ahead, and don’t take requirements analysis lightly.
API adoption
Our colleague Hans Bot was next to present on API Adoption. He took the issues Erik Wilde introduced a level further. In his view, providing just one can of beer is not really a business model. You want to offer many options for different people and perhaps for different use cases. You want to add value to it. After all, you do not sell a single glass of beer, instead you run a liquor store, bar, or restaurant. In his own words, if you design your APIs in independent teams, without overall planning and control, you will create more and more entropy (agreed, the uber sphere picture he showed titled ’spaghetti on steroids’ did look gruesome). Just a bunch of microservices doesn’t make an architecture (sure). The value of the architecture lies in adding synergy to the individual parts. In other words, just like Brexit, separation is simple, it’s the integration that makes it hard.
Hans also was brave enough to demo the beta version of WSO2 API Manager 3.0, which was released three days before the conference at the WSO2 Integration Summit in San Francisco. Boy, the API Developer Portal and the API Publisher are revamped almost beyond recognition. And because they’re built in React, customization is easier than ever before. Nice cloud theme, by the way. Tempting Connext promo too. And like in any good demo, not everything worked flawlessly. Yet it was an exciting peek into the future. After his presentation, we welcomed a lot of people on our booth, were we presented our new Cloud Platform, Connext.
Here you can view the slides of Hans’ presentation:
Event-driven APIs
Another presentation was about event-driven APIs, by Khallai Taylor. This may seem counter-intuitive, but in fact he presented a number of use cases where back-end systems should actively send information to (mobile) clients. Traditional pub-sub models do not scale. After all, there’s polling taking place in the background. Even Websockets do not meet de requirements with typical eventing cases. According to Khallai, the ultimate solution is to create a server-side hub that performs the polling, and maintains a connection with the client.
GraphQL IBM
IBM offered a look into their kitchen, particularly how they are integrating GraphQL into their API Management portfolio and how they complement Istio in a mesh architecture. On the latter topic, IBM has some catching up to do compared to other providers. For instance, take the upcoming WSO2 Cellery technology making massively distributed architectures manageable (as Hans clearly explained in his talk). GraphQL on the other hand, offered some fresh insights into the way IBM thinks about policy management on queries. They are opening the possibility to assign weights to elements in a query, and block any call that is ‘overweight’ as a means to counter malicious use. That sure looks promising.
Developer experience
Thilo Frotscher talked about ‘eine großartige Developer Experience’. This also tuned into the theme of developer engagement. After all, developers are the customers of APIs. And every provider of APIs must become customer centric to become successful. Consequently, APIs should be well documented, sparkle a sense of beauty, and if possible even fun to use. But foremost, APIs must be easy to use (which is manifestly not the same as easy to provide). Oh, and don’t forget to think hard about meaningful error messages. If there is one thing that your developers hate most, it’s investing time into searching the cause of errors. After this session, it was time for a casino night with drinks and pretzels at the exhibition floor.
Digital Transformation catalyst
Day two started again with two keynotes. Kay Lummitsch, self-declared digital transformation catalyst, kicked off with a presentation about selling APIs as an attitude, lifestyle and mindset. A digital mindset. Facing the future while embracing the past. But really opening up as a company will require a more fundamental change. A change of culture even. We need to build a world where one plus one is more than the sum of its parts. (It’s almost as if there’s a synergy virus in the water in Berlin). We, argues Kay, should shift from an API to a VPI – a Value Proposition Interface. Therefore, we need API Product Managers, claiming radical ownership. A book on that specific topic is due to be published shortly.
Holistic approach
Emmanuel Treny took a more technical perspective on providing APIs. Successful enterprises do modernize their integrations. Decentralized development, fine-grained services running on a hybrid integration platform, with different styles of integration. The real complexity behind the simple process of ordering a pair of shoes requires eventing, messaging and transactions. WSO2, of course, has been promoting a holistic approach to integration for years and years.
Bridging APIs and serverless
Bridging APIs and serverless was the other big theme of the conference. Jonas Schweizer spoke on invoking APIs as webhook to build that bridge, using his experience with an AWS Lambda filter in front of an SQS queue. Best tip: the serverless framework helps to set up your AWS configuration easily. It generates a CLI for you (cool!). Lambda itself is a great developer tool, albeit with some constraints. Lambda is well-integrated in the larger AWS ecosystem (just be careful what you wish for).
Wrap up
Kudos to the diehards who continued to visit sessions after the extended lunch break. For me, it’s time to draw conclusions. It was an interesting conference and we’ve met a lot of new people at our booth. API Management as a discipline is starting to mature. Most people we spoke to, consider bringing their APIs to the cloud. There were few surprises during the conference, and many best practices we’ve heard before. WSO2 Cellery was probably the only real innovation on API Management targeting massively distributed microservices. Serverless still feels like a solution looking to a problem to solve – while questions on privacy and security remain. Nevertheless, the attendees all seemed to be loving the experience. Developer engagement is important, and is more than just publishing your interface definition indeed. Interestingly, making use of APIs is all about the developer experience, while providing APIs is increasingly about product management. Maybe this is something to explore a bit deeper. Why is the use of API so focused on the development of an application, whereas API provisioning is an ongoing endeavor? Shouldn’t we start thinking about optimizing the DevOps experience instead?
