This week on the API Intersection podcast, we chatted with Balan Subramanian, Partner Director of Product for Azure App Platform Services at Microsoft. At Microsoft, he leads the product team that works on the Azure app platform. This includes microservices frameworks such as Dapr, cloud services such as Azure API platform, Azure Logic Apps for integration, Azure Cache for Redis, Azure Spring Apps, and a few other services.
Additionally, Balan is responsible for ecosystem enablement for Azure developers–meaning he works with some of the well-known names in the developer community, such as Elastic, Confluent, Redis, Nginx, etc., and enables them to bring their SaaS to developers with Azure-native integrations.
Balan provided a few insights on how Microsoft works to create an enticing partner environment, how they use the design-first approach internally, and how they help customers think of their APIs as products (even when they’re not monetized!).
Creating an Enticing Environment for Partners
Obviously, as one of the largest global technology companies, the Microsoft team works with a wide range of partners in several domains. When building out great partnerships, Balan likes to focus on creating a platform where partners can not only reach Microsoft’s broad customer base but also attract net new customers together through seamlessly integrated product value. Their goal all along has been to make Azure a great platform for companies, big and small, to build their next-generation of offerings.
Often, some of these companies contribute heavily to —and drive a business model around — open-source, and Microsoft’s goal is to enable that on their own platform. They make their opportunities for open-source integration a crucial part of creating an enticing partner environment and invest their own engineering resources in making these partners successful. Their philosophy is to provide equal access to strategic partner offerings as their own first-party services with the goal of enabling the best value for developers and customers.
So as they look at providing a holistic API Platform for developers everywhere, they are looking at open source and partnerships to bring the best capabilities to these developers. And speaking of open source, it’s exciting to see that Balan’s team is a fan of our own open-source linting tool, Spectral.
“In addition to driving key open source projects such as VS Code, .NET, and k8s, We use a lot of open source within Microsoft. So Spectral is something that we use quite broadly within Microsoft,” shares Balan. Balan’s team has built extensions on top of OpenAPI to make it easier for developers to use OpenAPI, but for the majority of their tooling, it converges around Open API.
Making “API First” Second Nature with a Design-First Approach
You already know we’re big fans of the design-first approach here at Stoplight, but we love to see other teams implementing that too!
“Within Microsoft, it’s been a journey of consistency and discipline,” shares Balan. “Before I took on my current role working on the Azure API Platform product, I ran the product team that was responsible for the Azure SDKs and for enabling consistency across the API surface area across all the Azure services. And we have 200 plus services built by dozens of engineering teams, some with hundreds of developers each!”
Balan’s team started out with tools that they built for their own developers to use as they built APIs. They discovered that many developers had already built the code. Now, they were trying to build a specification around that–so it was more about properly enabling that journey while also introducing the discipline of doing design-first before the actual implementation.
“So we were able to bring it all together into an engineering system that our internal teams could use to implement a design-first approach to API development properly,” shares Balan. Now as they broaden Azure’s API Management solution to a holistic API Platform, they are using these lessons learned as they observe the same patterns and behaviors across developers outside of Microsoft too.
Design-First: Consistency and Discipline
The end goal for Microsoft’s team has always been establishing consistency throughout. Internally, they have an architecture review board that looks at all the different APIs that are coming up. They pay a lot of attention to breaking changes, consistent interaction patterns, naming conventions, and policies around that, using the architecture board to catch those issues.
“When a customer looks at any of your APIs, we want them to have a consistent experience, whether that is how they authenticate with the service, the kind of payloads that they can expect to use the service, etc. We did this through a combination of programs and products,” shares Balan.
For further consistency and to keep design top of mind, Balan mentions they also run an end-to-end review process that focuses on workloads. They take a customer scenario that could span several services and then show how a customer would actually implement that solution in different languages. Then, it comes down to the commonality that those customers have across those languages, which ultimately turns into the API. The shape of the API defines the experience that a developer has with those SDKs.
“So these end-to-end experiences were really eye-opening for the service teams because now they understood nobody uses their service in isolation. It’s always used together with other services,” shares Balan, “It’s important that our service teams understand the user flow and all the pain points at every single touchpoint to design accordingly for our customers.”
Practicing their end-to-end reviews with a focus on design at every step proved helpful in encouraging the service teams to converge towards having that design-first philosophy and better consistency across the different services.
Best Practices for Establishing Policies for All Stakeholders
“Additionally, in terms of operating an API, figuring out things like what are the right throttling policies that we need to put in place so that we don’t inadvertently turn off developers from using the API has been another challenge,” shares Balan.
Balan’s team focuses closely on a solid balance between protecting not just their own service but also the developers’ code. It’s important to note that the same throttling policy cannot be applied to all services, so their team has to consider each individual API and code.
“For each case, you have to think about what that API is actually doing. Is the product behind that API meant to be a chatty product? So, is there a continuous interaction, or is it supposed to be more of a long-running request-response kind of pattern?” shares Balan. “Understanding that has been very helpful for us in terms of understanding what kinds of policies work when the API is used at scale.”
Balan’s team built some best practices around the kind of service and policies that work best for each use case based on those questions. After going through that process internally, Balan noted that they found many of their customers had the same issues with their own APIs. He noticed their customers had the same problems of understanding the usage of these APIs that their customers might be calling, delivering good documentation around those APIs, and being very explicit about what the policies are. This meant that those best practice guides ended up being way more useful for their external audiences too, and not just their internal team!
“In the end, I think the best practices that we’ve learned from operating Azure APIs apply to developers everywhere, which was extremely helpful,” shares Balan.
Treating APIs as Products, Even if They’re Not Monetized
“Often, when talking to customers who are going API first, we find that the term API monetization is overloaded. Even if the users of your API are not paying you for it, you still need to treat it like a product, which means it has a lifecycle,” shares Balan.
Time and time again we’ve reiterated the importance of treating your APIs as products to be successful. On many platforms, APIs can solve other customer and business needs such as improving customer retention by better integrating into their environment of related tools. Balan notes that APIs that aren’t directly monetized need the same discipline around deprecation policy and excellent documentation as those that are monetized. API product managers are just as important stakeholders in addition to the API developers and operators.
Additionally, treating your APIs as a product should also mean a focus on the discoverability of those APIs, even if it’s just within your own organization and not for external purposes. He also emphasizes that you want an easily discoverable API surface area because that is how other developers will find it, use it, and build on top of it. Discoverability enables users to start consuming APIs at scale within an organization but also means the APIs may be used in ways not originally imagined.
“Also, there’s a huge emphasis on not reinventing the wheel and building new value and new capabilities out of existing systems through composability. So I think all of these things kind of come together and if you’re a product manager working on any API, treat it as a technical product,” shares Balan.
Treating your APIs like a product means also understanding how your team will handle that scale when mass consumption comes. Thinking through things like that ahead of time (i.e. while in the design phase) will save you time and effort down the line. Picture your API from the entire end-to-end lifecycle and design for those capabilities.
It was an excellent opportunity to understand Microsoft’s thinking about API strategy, partnerships, and the design-first approach. I look forward to furthering potential opportunities down the line! As always, subscribe to the API Design blog or our podcast for more insights.
