API Federation: Unified Interfaces for Agile Service Ecosystems

Interview with Daniel Kocot

As organizations continue to adopt microservices architectures and leverage cloud technologies, effective API management becomes paramount. API federation aims to provide a centralized approach to managing and orchestrating APIs across diverse environments to keep pace with the ever-increasing need to manage our APIs closely. API Federation is a fundamental part of modern API management.

Fostering a cohesive environment with diverse API services, API Federation is often governed by different policies and designed for various functions. At the heart of API federation is a focus on designing APIs with the end-user in mind (think APIs as a product), ensuring they offer true value, which is especially crucial in federated models with diverse API sources and purposes.

API Federation encompasses a collection of design principles, tools, and infrastructure that enable the exposure of services and event streams within a specific bounded context as a cohesive and standardized API for external customers. API Federation allows individual services within the bounded context to evolve and adapt without imposing additional limitations or constraints.

The TL/DR of it all is that API Federation provides a unified and consistent interface for external users while promoting flexibility and agility within the internal service ecosystem.

Ok, but what does that mean? Not to fear, our latest Livin' On the Edge podcast guest, Daniel Kocot, Head of API Consulting at codecentric AG sat down with us to walk us through it all and the two major concepts that are impacting API Federation today, including shifting mindsets and the language style you choose to code in.

Shifting Mindsets: User-Centric Design & Treating Internal APIs as Public:

Internal API Treatment

“Every internal API is a public API in a certain sense. It's important to make organizations aware of what will happen when you do things in regards to security and to really make your users understand the impact," shares Daniel.

Two things that will make a big difference for your API Federation goals are to always apply user-centric design and seek to treat your internal APIs as you would your public ones. Traditionally, organizations have treated internal APIs differently from external ones, often neglecting the importance of proper design and documentation. We like to equate it to how the house is always clean and uber-tidy when we have guests come over, but when it’s just us homeowners—best practices can easily fall to the wayside and get buried under that third pile of clothes on the bedroom floor.

However, Daniel emphasizes the need to treat internal APIs as if they were public, ensuring they are well-designed, secure, and scalable. This is an easy and fast mindset to adopt organization-wide that will make API federation a breeze. Build the habit of future-proofing your internal APIs, avoiding the need for extensive rewrites when the APIs are eventually exposed externally or when the product evolves.

Also, don’t overlook the potential of gRPC, a high-performance, open-source universal remote procedure call (RPC) framework, for internal APIs. Daniel touted its type, safety, and precision as major advantages over more ambiguous options.

By this point, we all know the importance of treating our “APIs as Products,” but be sure that this applies to your internal APIs as well. Many are shifting toward a decentralized, user-focused API design in the API industry.

Be User-Centric

Treating your APIs as products means adopting that user-centric approach when designing APIs and building them like you would any other product. Rather than focusing solely on the backend implementation, it is crucial to understand the needs and expectations of API consumers.

“When you have some kind of interface, nobody is looking at the code of the backend of the interface. So, it's really about being user-centric and mindful of that,” shares Daniel. “Being user-centric is really about bringing people to the right point and not just doing things because it's easier. It's about hearing what users need, adapting, and learning from feedback.”

By actively involving potential users and gathering feedback, organizations can iterate and improve their APIs, ensuring they meet the requirements of the intended audience. This user-centric mindset also helps in avoiding versioning issues and breaking changes down the line.

The Limitations of REST & the Rise of Alternatives:

The language you choose to write your APIs in can also impact developer productivity and your API federation goals as well. Remember: the point of API federation is to create a unified and consistent interface that also promotes flexibility and agility within the internal service ecosystem. The language you choose to code in can impact both flexibility and consistency equally.

“Look-on the one hand, please only use a language you or your team is really proficient with… because in the end, when I have to learn something new, they’ll be slower because they don't know all the tricks and best practices immediately,” shares Daniel. “There's always a temptation to use the latest and greatest technologies or frameworks, but that may slow your team down.”

Remember, pretty much any developer, if you give them enough time, can write an API in any language, but it’s the quality of the API that is going to suffer based on how long and how much they've used that language in the past. Daniel recommends saving yourself time and quality by sticking to what you know if you’re under a time constraint. This can be the best option to maintain that unified and consistent internal service ecosystem across your developer team.

However, sometimes, what you know may not be the best long-term choice. For example, REST (Representational State Transfer) has been the dominant API language style for many years, but Daniel suggests that organizations should explore alternative approaches long-term when it comes to the limitations of REST. He notes the lack of cache-ability and the potential for ambiguity in API design that often comes with REST.

“Don’t be afraid to consider other styles, such as gRPC, which offers stronger type safety and more efficient communication through protocol buffers (protobufs). By embracing a wider range of API styles, organizations can choose the most suitable approach for their specific use cases in the long run,” shares Daniel. A newer language style may give you the flexibility and agility you’re looking for, which is equally as important in API federation.

Which route to go depends on the goals of your developer team. Smoothing out your API federation best practices means selecting a language style that will keep your developer productivity high while balancing the opportunity for more innovation with new approaches.

In the End: API Federation is Your Friend

In the end, API federation emerges as a solution to the challenges faced by organizations managing APIs across diverse environments. By centralizing API management and orchestration, organizations can ensure consistency, security, and scalability across their API landscape.

At the heart, API federation is about autonomy, allowing for the seamless integration of APIs from different sources, enabling organizations to leverage the full potential of their interfaces. It also simplifies the process of exposing internal APIs externally, as the federation layer can handle the necessary transformations and security measures.

It’s clear that API federation represents a paradigm shift in API management, emphasizing the importance of well-designed, user-centric interfaces that are agnostic to specific technologies.

How will you use API federation to provide a centralized approach to managing and orchestrating APIs? It’s time to unlock the full potential of your interfaces in a secure and scalable manner.

For more insights on the Kubernetes world, APIs, and developer experience, visit our podcast.