I had the pleasure of presenting on apiman at the recent Microservices Architecture Developer Day, with our colleague Kurt delivering a short demo of our software running within Fabric8. It was particularly enjoyable meeting developers who are interested in, or are already using, apiman - so, thank you for your insightful questions both during, and after, the presentation.
Given the packed schedule, there was a limited amount of time to explore apiman plus microservices, and hence this seems like a good opportunity to write a blog post expanding upon the themes I touched upon.
So, if you’re interested in understanding the value API management can have in a microservices architecture; please, read on!
Services, services, everywhere!
A microservices architecture encourages the decomposition of problems into small, isolated and reusable chunks; much in the same spirit as UNIX’s do one job and do it well philosophy. This brings with it a whole raft of benefits, for instance: we can scale each component independently, avoiding unnecessarily dragging along other components which just happen to reside in the same monolith; we can easily have a single team wholly responsible for a single microservice’s lifecycle, simplifying debugging and allowing them to use their skills and technologies of choice; and, we can easily create new functionality via composition. However, this proliferation of heterogeneous services poses some challenges, a significant subset of which API Management is a key solution to.
Avoiding reimplementation of cross-cutting functionality
A problem that can quickly become apparent is that key pieces of important common functionality are required that are difficult or undesirable to reimplement in every API. Good examples of this would be security concerns like authentication and authorization, or business concerns like rate-limiting, billing and auditing [1].
It’s quite clear why we would want to avoid this situation. Imagine we have hundreds of microservices we need to expose to the outside world; the nightmare scenario is that we have to implement complex and prone-to-change authentication and authorization schemes on each of them. Quite aside from bloating and complicating our microservices, it is going to be extremely difficult to guarantee that each service has implemented all of this common functionality consistently and correctly - we could quite plausibly be leaving holes in our system simply by virtue of surface area.
Instead, we can drastically improve the situation by using apiman to relieve individual services of that burden; simply configure and manage those tasks in a single, well-known location. We register our APIs with apiman, apply appropriate policies, and route public traffic through the gateway. We leave apiman to deal with these common problems, and let the microservice’s developers focus on their core task, rather than burning time on ancillary concerns.
Fickle business requirements
Access to APIs often has business requirements which are independent of the core functionality the service itself offers. For instance, whilst a mapping application might only be interested in coordinates, its business requirements could dictate that we need to capture metrics; initiate contracts with, and issue keys to, API consumers; and, audit their interactions with the system. Quite aside from the microservices faux pas of contaminating a service with external business logic, we generally want to avoid this situation, as business requirements tend to change rapidly in response to events which are unrelated to the service’s purpose.
For instance, marketing decide that the service is so popular that they’re going to offer two levels of access a gold plan and a silver plan; one of which allows 1000 requests per minute, the other 500. The developers trudge off and implement this in their service. Six months later, they decide they want to change this to bandwidth limits, and the silver plan should be able to do only GET requests. The developers of a variety of services are taken off their existing tasks to implement these changes.
Shifting business requirements are a natural part the software industry, however, the implementation burden is amplified in a microservices architecture. Thankfully, we can delegate that workload to our API Management solution, and even better, with the apiman UI it’s possible for non-technical people to create and manage the entire process. This is excellent from both standpoints, as the developers can concentrate on their core tasks, and the business people can take direct ownership and responsibility for implementing their policies; the two domains are kept entirely separate.
Naturally, there will be cases where the in-built policies don’t meet your specific needs. Apiman was designed grounds-up with the assumption that many users would want to write custom policies, and as such, we’ve written a number of guides on the topic. It’s extremely easy to create, install and version control your own policies, including UI components that make it trivially easy for non-technical people to drive.
Clear demarcation
Of all the microservices constituting an entire system, it is likely that only a subset of those should be exposed to the outside world. The rest are there to provide internal or compositional functionality. The apiman gateway can provide a natural boundary between public and private; only those services that are explicitly being offered through the gateway are visible, and the rest can be walled off (either at the network level, or via mutual authentication mechanisms).
Watching the world go by
If we want to determine the value of a service to our organisation, then we need some objective metrics to determine how it is being used and whether it is performing as well as we hoped. Ideally, metrics should be collected in a manner that is consistent amongst all services to ensure that comparisons can be made fairly. The apiman gateway is in a unique position to collect lots of interesting data; siting at the transit point between the outside world and the services being offered. We collect, amongst other things, timing information; round-trip latencies; detailed error information (error codes, error output); application, service and organisation IDs. These can be analysed to produce a rich set of information which you can use to characterise the behaviour (or misbehaviour) of your services, including how external applications are interacting with them.
Metrics collection, analysis and visualisation is an area we’re actively working hard on: in the community we’re looking to provide interesting opportunities to tie in with popular open source data-sinks and visualisers, whilst in integrated environments, we look to play well with native metrics collection infrastructure.
Papers, please
You may have lots of services to offer, but unless people can find them, they won’t know about how useful they are. Hence, it’s important to have a well-known service registry through which internal and external consumers can find and consume your APIs. Developers can easily log into the apiman UI to browse and search for registered APIs, and we also make it easy to integrate into any other registry, such as Fabric8’s.
In conclusion
API Management will be at the heart of many successful microservices setups. It unifies common functionality; provides a place to discover, register and manage services; reduces the scope for costly errors and inconsistencies; and, provides a natural barrier between internal and external where it can collect valuable metrics and audit information.
It was a pleasure to meet all of those developers who are interested in apiman - and it was particularly interesting to hear your use-cases. I would encourage you to keep giving us your feedback, as it directly impacts our features, priorities and schedule.