APIs have the power to disrupt the traditional supply chain. They’re enabling a more rapid velocity of features, opening up innovative channels, and helping to meet rising user expectations. “APIs are making new developer models for the edge. It’s bringing a new development environment entirely,” says Vijoy Pandey, Vice President, Cisco.
However, there are some challenges to a modern API approach. Namely, stability and security concerns plague APIs, posing significant roadblocks to digital transformation if left unchecked.
Recently, I met with Pandey to discuss how enterprises should evolve their approach to APIs. Pandey, who oversees an internal incubation division at Cisco, has a keen focus on progressing how developers manage their API fabrics. According to Pandey, API architecture will require continued investment into connectivity, security, and observability.
Customer Expectations Drives API Adoption
What is fueling the interest in APIs? Well, for one, the future of work is hybrid, says Pandey. In fact, this new era is already upon us. More distributed work means increased digitization, SaaS tools, and cloud-based operations, all contributing to an increase in web API usage.
End consumers now interact with nearly every brand through a digital intermediary. Digital expectations are high and studies show that apps have only one shot at winning a user’s trust. “The modern application is the face of the brand. This was not the case a decade ago,” says Pandey. “The experience a customer has in an app will define what the brand trust and reputation is.”
The fluidity of using a digital service may quickly dictate which business a user will support. For example, consider two types of banking apps for a loan application. In one, you manually enter all your details upfront: the loan amount, your financial information, W2s, and hit ‘Save.’ Then, the system says they will call you back once a representative has had time to review your material. However, in a second app, the system automatically populates fields by synchronizing with your financial accounts. It looks up your history and determines a loan approval right on the spot. It’s obvious which app users seeking a quick response prefer.
This scenario depicts how important high connectivity, availability, and performance are for user experience. We have the technology to enable such a transaction, but building such an automated process is impossible without the correct digital alignment. “That’s the reason I think an API-first world is crucially important,” says Sandey. By syncing with internal and external APIs, developers can pick and choose existing capabilities to avoid reinventing the wheel. This fuels the rapid development necessary to deliver a high velocity of features.
Increasing Complexity in an API-Driven World
Because of the need for increased feature velocity, we’re seeing a surge of various APIs to power each sub-system, increasing complexity across the board. For example, consider the technology required to build a completely contactless ATM withdrawal (much needed during the pandemic). Here, the customer journey is relatively simple: look up the closest ATM, drive to the ATM, authenticate, enter the amount, and pick up the cash. While this is straightforward for the user end, the back-end involves various API calls and synchronization between hardware and software.
- Front-end: Must interact with mobile APIs through an iOS or Android SDK. Camera as well as location sharing must be turned on.
- Back-end: AWS back-end in the cloud. Single cloud to store app.
- Interact: Must interact with APIs from SaaS providers, pull customer data from Salesforce, and utilize facial recognition API, calculating proximity of users to enhance authentication.
- Transactional: Must tap into core bank infrastructure to validate transaction. This is probably still a mainframe process.
- Local Edge APIs: Need to communicate with the local branch and confirm cash consistency of the ATM.
- Update: Finally, the system must update the edge, on-premise system, Salesforce, AWS, and the front-end before releasing the cash.
3 Problem Statements for APIs
When technology works like magic, it’s easy to take what’s occurring beneath our fingertips for granted. And as you can see from the example above, it takes many API connections to build a simple feature!
We see an explosion of APIs behind each application. Yet, for this new ecosystem to prosper, Sandey recognizes three main challenges to API-driven architecture: connectivity, security, and observability.
1. Connectivity
API consumption is quite variable. Developers must first discover the correct API for each task. After that, they must figure out how to consume the API and if it uses consistent policies. Lastly, they must support a networking layer to ensure that systems can talk to one another. Without consistent connective tissue, API integration could get dicey.
In terms of consistency, many different API design styles crowd the market. There’s REST, GraphQL, gRPC, and other communication styles, like Kafka and PubSub. There are also different ways to define and document APIs, namely OpenAPI and AsyncAPI. These nuances can make using one API compared to the other pretty different.
“Even with the modern cloud-native API layer, there is disparity and heterogeneity,” remarks Sandey. “There’s a whole gambit out there.” According to Sandey, improving consistency for communication with media endpoints and data endpoints as well as bringing the event-driven bus into a cloud-native world will be necessary elements to increase consistency for API connectivity.
2. Security
When your stack is built with APIs, your perimeter is essentially just an API call away from the external world. “The entire runtime of every modern application is the wide open Internet,” said Sandey. “All APIs are sitting everywhere.” It’s no wonder that Gartner predicts that by 2022, APIs will be the most frequent attack vector.
Sandey outlines two types of APIs in modern development and how they require a unique security response:
- Internally developed and exposed: A function is internally generated and exposed as an API. This service could be written using monolithic code and exposed with an API wrapper. Or, it could be a cloud-native microservice explicitly designed for developer reusability. Regardless, it’s imperative to secure internal APIs through code analysis. To spot vulnerabilities, Pandey recommends tools like Portshift to provide security analysis for internal assets. In addition, Pandy recommends solutions like AppDynamics for a broader range of protection.
- Cloud-based external SaaS: With the rise of mobile devices and the cloud, more assets will sit outside of the organization. Software projects continually link to external Software-as-a-Service, such as Twilio, Salesforce, Shopify, or Stripe through API calls. Sandey believes a reputation scoring engine could help evaluate these services to improve security control over said APIs.
Building out a reputation score, especially for third-party APIs, could enhance metrics and security. “Is there cross-side scripting? Are certificates fresh? Is it compliant with GDPR?” inquiries Sandey. He suggests that API reputation scores could be integrated into a local IDE or CI/CD pipeline. This would inform developers of security repercussions right off the bat, helping API security to “shift-left.”
3. Observability
Having a holistic view of the entire digital journey is essential to spot bottlenecks and debug. It’s part of the current mantra around decreasing Meant Time to Recovery (MTTR). Yet, full-stack observability that goes deeper behind API calls is still an area that requires maturity.
“First, the industry wanted to know ‘what’s happening’, then ‘where is it happening.’ Now, we want to know ‘why is it happening?'” said Pandey. “You cannot get to why before you have tracing. My belief is that tracing is going to be the defacto way of doing observability going forward.”
“A trace represents the entire journey of a request or action as it moves through all the nodes of a distributed system,” defines Samuel James. However, tracing can’t function properly in isolation. Complete tracing must also be scalable and deliberate, considering all layers and traversals over the web to expose issues.
For example, Pandey describes how developers behind a banking app noticed high traffic latency between two cloud instances. By using a robust observability system, they traced the issue to a memory instance misbehaving on an on-premise location in a private datacenter. “You need full stack observability to see all that,” says Pandey.
Final Thoughts
In today’s accelerating digital climate, the application experience is really what builds faith in a brand. Oftentimes, the responsibility for creating this trust falls on the developer’s shoulders. “Who is responsible? It’s the app developer,” says Sandey. “They are making sure all this is certain. They are under extreme pressure.”
APIs are one answer to alleviating this pressure. However, the new API paradigm poses new security risks. Instead of utilizing internal code libraries, an application may be interacting with a slew of cloud-based APIs, whose reputation isn’t always certain. Disparate API styles make connections difficult. Also, teams don’t always have complete insight into the bottlenecks behind web calls.
Going forward, we will likely see continued investment in areas like connectivity, security, and observability to maintain stable APIs. Furthermore, as integration reliance increases, these traits will become more essential to support continuous app development. Because, as Sandey describes, “if it’s not pushing features, a brand suffers.”
