The Rise of API Developers as First Class Citizens in a Microservices Era

The Emergence of the API Economy   

I spent a part of this weekend learning about the power of APIs on Udemy. Recommend these for everyone interested in learning about all things APIs. After consuming all that brilliant content, it was clear that we have arrived into an API economy.

APIs are everywhere – behind firewalls on corporate intranets consumed by partners, and/or internal developers, and open APIs that are being consumed freely by an extensive set of unknown developers. IoT has further accelerated the growth of this API economy. The economy that will determine the pathway to a bigger and a better digital world. It also means that organizations have a responsibility to spend significant cycles in nurturing and growing the ecosystem that is creating and consuming these APIs, SDKs, and libraries – the developers, of course!

In this blog, I’ll try to establish the ‘modus operandi’ to create that connection with this influential API workforce. There’s a need to provide them with a ‘system of engagement’ to thrive and excel so that they can bring all that digital transformation to your business quickly and efficiently.

APIs – Why, What, and How

Before we talk more about APIs, it would be good to understand what these APIs are? To explain APIs very simply – they are like user interfaces, but for machines. Just like we (the humans) interact with the web and mobile applications via a clean UI, machines and software talk to each other via a well-defined API – an application programmable interface.

So, it could be your smartphone or any other device talking to applications like SF.com, Dropbox, or Spotify. It could also be two servers talking to each other – like SAP and SF.com. Pretty much any system can connect to any system. And this exchange of information between the two systems happens via a contract. This contract determines the rules of engagement between the API provider (the server) and the consumer (web, server, desktop, mobile, and any other devices).

Why APIs? Simply put - it is to increase efficiency and throughput. Instead of writing a thousand lines of code, you can make one API call to bring large customizations to life - easy. And there are economies of efficiency driven by interchanging the systems of engagement. So, if you were running on IBM Mainframes spending billions of dollars to maintain the infrastructure, you could do an under-the-hood swap of the infrastructure with .Net and make an API call to without disturbing the application’s UI. Huge cost savings.

Types of APIs? There are different types – web (available over a network), product (different versions of API when the product gets installed), embedded, browser (APIs that are built into Chrome, Firefox and Safari that developers have access to) and standard APIs (standard bodies are setting APIs that organizations have to comply with).

From Monolith to Microservices and API Led Architectures

Monolith applications are large, complex applications. Multiple developer teams touch the same parts of the application with a possibility of submitting conflicting source codes. But with a microservices architecture and an API-driven economy, things turn around. With microservices, the behemoth application can be broken-up into consumable parts via a service-oriented architecture, abstracted via an API layer around each of these parts to communicate with the other parts and make transformation happen at the speed of light. And in the microservices era, which is pretty much now, API developers become first class citizens.

Productizing APIs 

When organizations start thinking about APIs, there is usually an impact on culture. Hence, the organization needs to be prepped up for it. There are decisions on the type of APIs. Is this a public or private APIs? Then there are the service tiers and SLAs for freemium vs. paid for the number of API calls. If a customer is paying you several million dollars for your API, then the SLAs have to be well defined for them. Security another very important construct that needs to be built into the planning phase, not as an afterthought.

The design of the API is a critical step. It has to be designed to create a top-notch developer experience. So, codified requirements, well-defined developer experience, tools for testing and collaboration, and all the documentation. And then comes the development by taking all the inputs from the design phase. Will it be on cloud or on-premises, who is going to drive the API stack and management, and how will the API operations and monitoring happen.

It will be essential to build enforcement around the tiers if there’s a freemium vs. paid model in play. API operations with user management, scaling, billing, DevOps tooling, and stack security – all things to consider in the management phase. Then there’s governance – controlling information and access based on policies for all the users. Managing API access and enforcement points across API keys, throttling, user-level security, application level security, and access control.

And of course, the measurement and testing of APIs via analytics and ongoing performance and regression testing are super critical.   

Developer Marketing – Nurturing and Supporting the API Developers

We’re all clear and sold on the fact that APIs are critical to bringing a rapid digital transformation. In that context, both API providers and API consumers need a support system to succeed in large scale implementations. Several companies like Alchemy have made APIs their mainstay by providing open APIs, for example. Their model of reaching to the developer ecosystem was so good that IBM Watson acquired them.

There’s a lot of love that needs to go into evolving and maturing this developer experience, and granted; it cannot be built overnight. Here’s a framework that I like, and it gives a macro view of all the moving parts.

Developer and Community Marketing – the most essential piece of the pie to drive both awareness and engagement. Refer to my article: No Deals on the 18th Hole, Winning Over Developers Differently that is a summary of a great book called Developer Marketing. It is a capsulation of developer marketing best practices learned from companies like Atlassian, Microsoft, Facebook, Arm, and Oracle.

In the context of API developers, it is essential to understand the exact developer persona – are they internal audience consuming LSUDs or external geeks looking at SSKDs. And then tailoring the programs for this audience for awareness via gamification and code hacks. It’s critical to create content that means impact via documentation, code samples, video tutorials, showcase, and mock APIs.

This content can go up on the API developer portal as well as used in campaigns. Next in the line is evangelism – and this is a combination of community marketing and high-impact content. Evangelism includes creating a powerful group of API gurus who are willing to talk and write about the subject intelligently at Meetups, code events, user group meets, and create blogs and technical how-to articles on various internal and external forums. These speakers and writers could have specialties on topics like API governance/security, Open APIs, API Design, API analytics, APIs on cloud vs. On-Premises, etc. Trainers, architects, and engineers can also get involved in running the code hacks, for example.

Then there are community managers who are moderating the various forums – to answer questions about your API and offer expert advice and support via your internal and external forums like Quora and Stack Overflow, for example. They can also be chartered to create and manage internal API developer communities. Email campaigns – yes, but with a difference, please. Standard marketing emails can usually land up in junk.

There’s a lot more that goes into core developer marketing, but so much about APIs from me for now. In the following blog, I’ll explore the building and consuming of APIs. I wanted to share the link to this guide to developer marketing e-book for all dev marketing aficionados. This is from Developer Media - a source I have trusted to run dev marketing over the years. Another source that I bank on for developer centric data is Evansdata. A few pictures here from a Dev Marketing Summit panel that I was a part of last year to share success stories on all things Dev + Marketing.

Stay tuned! And may the force of APIs be with you.                   

Few more articles that might be of interest: