API Management: Additional Considerations

DZone 's Guide to

API Management: Additional Considerations

The API management landscape will change rapidly as the technology landscape changes.

· Integration Zone ·
Free Resource

To gather insights on the current and future state of API management, we asked IT professionals from 18 companies to share their thoughts. We asked them, "What have I failed to ask you that you think we need to consider with regards to API management?" Here's what they told us:

  • An API provider is not an opaque provider, we need to know where the process will execute for GDPR compliance. Need to know data does not leave the region. It becomes important to delve into the execution framework of the provider.
  • We see APIs at the core of what we do to build software faster — using microservices and for driving CI/CD environments to communicate with Kubernetes (K8s).
  • The vendor landscape is shifting quickly. Incumbent solutions that first hit the market aren’t keeping pace with new trends. Cloud providers have responded with their own native solutions, but developers using these will be locked into that particular cloud provider. Given the trend towards microservices and multi-cloud applications, we see a direct need for a new architecture. One that is significantly lighter weight and designed for the performance and cloud-agnostic environments companies will need to keep the cost of processing API calls low.

    This will become even more important as companies embrace serverless architecture where more and more code and business logic is executed via API calls. The primary question facing organizations of all sizes becomes: How do I manage the full lifecycle of my APIs in a way that doesn’t sacrifice performance and cost? Otherwise, organizations will simply see their costs will rise proportionately with the success of their new digital business offerings, hurting long term sustainability.
  • Distributed API management is the nature of modern application development which is massively distributed. API management has to be distributed. Allow services to be controlled centrally with a single pane of glass with all the reports that show who has access to what, what services are available, and where those services are in an automated fashion.

    Anything that’s not in line with the application itself will create an out of synch situation with your centralized management at some point. Have localized control and distributed execution. Each service reports back to the command center. When someone tries to access service it can then hit the centralized authentication server to determine whether or not the person should have access. Centralized command, distributed execution is how it needs to happen.
  • “What would you say to 'traditional' software companies that are still pondering whether or not they should go the API way?” The answer to that would be: they should seriously consider it now. Many tech enablers are mature now, many engineers are skilled in these technologies.

    Yes, it definitely is a paradigm shift when compared to standalone software applications running on a single workstation, or when compared to a black-box remote system that can only be interacted with via a UI. The stack changes, the economic model changes. The system would have to open itself so that other systems could interact with it. The benefits for customers — for all end-users — are tremendous, in terms of automation, of creativity.
  • “Knowing what you know now, would you still deliver microservices directly to customers despite the lack of vendor or standard support?” And my answer would be “sure.”  The benefits we’ve gotten from unconstrained developer productivity and agility have been well worth the costs to my team and all of our developers are more thoughtful stewards of their APIs because they all, in a very real sense, own their APIs.

Here's who shared their insights:

api management ,integration ,apis ,microservices ,future state of api management

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}