Why Cloud Native Is Vital to Your Organization's APIs: The Impact Could Be More Than Expected

Editor's Note: The following is an article written for and published in DZone's 2024 Trend Report, Modern API Management: Connecting Data-Driven Architectures Alongside AI, Automation, and Microservices.

A recent conversation with a fellow staff engineer at a Top 20 technology company revealed that their underlying infrastructure is self-managed and does not leverage cloud-native infrastructure offered by major providers like Amazon, Google, or Microsoft. Hearing this information took me a minute to comprehend given how this conflicts with my core focus on leveraging frameworks, products, and services for everything that doesn't impact intellectual property value.

While I understand the pride of a Top 20 technology company not wanting to contribute to the success of another leading technology company, I began to wonder just how successful they could be if they utilized a cloud-native approach. That also made me wonder how many other companies have yet to adopt a cloud-native approach… and the impact it is having on their APIs.

Why Cloud? Why Now?

For the last 10 years, I have been focused on delivering cloud-native API services for my projects. While cloud adoption continues to gain momentum, a decent percentage of corporations and technology providers still utilize traditional on-premises designs. According to The Cloud in 2021: Adoption Continues report by O'Reilly Media, Figure 1 provides a summary of the state of cloud adoption in December 2021.

Figure 1. Cloud technology usage

Image adapted from The Cloud in 2021: Adoption Continues, O'Reilly Media

Since the total percentages noted in Figure 1 exceed 100%, the underlying assumption is that it is common for respondents to maintain both a cloud and on-premises design. However, for those who are late to enter the cloud native game, I wanted to touch on some common benefits that are recognized with cloud adoption:

• Focus on delivering or enhancing laser-focused APIs — stop worrying about and managing on-premises infrastructure.
• Scale your APIs up (and down) as needed to match demand — this is a primary use case for cloud adoption.
• Reduce risk by expanding your API presence — leverage availability zones, regions, and countries.
• Describe the supporting API infrastructure as code (IaC) — faster recovery and expandability into new target locations.

Making the transition toward cloud native has become easier than ever, with the major providers offering free or discounted trial periods. Additionally, smaller platform-as-a-service (PaaS) providers like Heroku and Render provide solutions that allow teams to focus on their products and services and not worry about the underlying infrastructure design.

The Cloud Native Impact on Your API

Since this Trend Report is focused on modern API management, I wanted to focus on a few of the benefits that cloud native can have on APIs.

Availability and Latency Objectives

When providing APIs for your consumers to consume, the concept of service-level agreements (SLAs) is a common onboarding discussion topic. This is basically where expectations are put into easy-to-understand wording that becomes a binding contract between the API provider and the consumer. Failure to meet these expectations can result in fees and, in some cases, legal action.

API service providers often take things a step further by establishing service-level objectives (SLOs) that are even more stringent. The goal here is to establish monitors and alerts to remediate issues before they breach contractual SLAs.

But what happens when the SLOs and SLAs struggle to be met? This is where the primary cloud native use case can assist. If the increase in latency is due to hardware limitations, the service can be scaled up vertically (by increasing the hardware) or horizontally (by adding more instances). If the increase in latency is driven by geographical location, introducing service instances in closer regions is something cloud native providers can provide to remedy this scenario.

API Management

As your API infrastructure expands, a cloud-native design provides the necessary tooling to ease supportability and manageability efforts. From an infrastructure perspective, the underlying definition of the service is defined using an IaC approach, allowing the service itself to become defined in a single location. As updates are made to that base design, those changes can be rolled out to each target service instance, avoiding any drift between service instances.

From an API management perspective, cloud native providers include the necessary tooling to manage the APIs from a usage perspective. Here, API keys can be established, which offer the ability to impose thresholds on requests that can be made or features that align with service subscription levels.

Cloud Native !== Utopia

While APIs flourish in cloud native implementations, it is important to recognize that a cloud-native approach is not without its own set of challenges.

Cloud Cost Management

CloudZero's The State Of Cloud Cost Intelligence 2022 report concluded that only 40% of respondents indicated that their cloud costs were at an expected level as noted in Figure 2.

Figure 2. Cloud native cost realities

Image adapted from The State Of Cloud Cost Intelligence, CloudZero

This means that 60% of respondents are dealing with higher-than-expected cloud costs, which ultimately impact an organization's ability to meet planned objectives. Cloud native spending can often be remediated by adopting the following strategies:

• Require team-based tags or cloud accounts to help understand levels of spending at a finer grain.
• Focus on storage buckets and database backups to understand if the cost is in line with the value.
• Engage a cloud business partner that specializes in cloud spending analysis.

Account Takeover

The concept of accounts becoming "hacked" is prevalent in social media. At times, I feel like my social media feed contains more "my account was hacked" messages than the casual updates I was tuning in to read. Believe it or not, the concept of account takeover is becoming a common fear for cloud native adopters.

Imagine starting your day only to realize you no longer have access to any of your cloud-native services. Soon thereafter, your customers begin to flood your support lines to ask what is going on… and where the data they were expecting to see with each API call is. Another potential consequence is that the APIs are shut down completely, forcing customers to seek out competing APIs.

Remember, your account protection is only as strong as your weakest link. Make sure to employ everything possible to protect your account and move away from simple username + password account protection.

Disaster Recovery

It is also important to recognize that cloud native is not a replacement for maintaining a strong disaster recovery posture.

• Understand the impact of availability zone and region-wide outages — both are expected to happen.
• Plan to implement immutable backups — avoid relying on traditional backups and snapshots.
• Leverage IaC to establish all aspects of cloud native — and test it often.

Alternative Flows Exist

While a cloud-native approach provides an excellent landscape to help your business and partnerships be successful, there are likely use cases that present themselves as alternative flows for cloud native adoption:

• Regulatory requirements for a given service can often present themselves as an alternative flow and not be a candidate for cloud native adoption.
• Point of presence requirements can also become a blocker for cloud native adoption when the closest cloud-native location is not close enough to meet the established SLAs and SLOs.

On the Other Side of API Cloud Adoption

By adopting a cloud-native approach, it is possible to extend an API across multiple availability zones and geographical regions within a given point of presence. 

Figure 3. Multi-region cloud native adoption

In Figure 3, each region contains an API service instance in three different geographical regions. Additionally, each region contains an API service instance running in three different availability zones — each with its own network and power source. In this example, there are nine distinct instances running across the United States.

By introducing a global common name, consumers always receive a service response from the least-latent and available service instance. This approach easily allows for entire regions to be taken offline for disaster recovery validation without any interruptions of service at the consumer level.

Conclusion

Readers familiar with my work may recall that I have been focused on the following mission statement, which I feel can apply to any IT professional:

Focus your time on delivering features/functionality that extend the value of your intellectual property. Leverage frameworks, products, and services for everything else.

—John Vester

When I think about my conversion with the staff engineer at the Top 20 tech company, I wonder how much more successful his team would be without having to worry about the underlying infrastructure being managed with their on-premises approach. While the other side of cloud native is not without challenges, it does adhere to my mission statement. As a result, projects that I have worked on for the last 10 years have been able to remain focused on meeting the needs of API consumers while staying in line with corporate objectives.

From an API perspective, cloud native offers additional ways to adhere to my personal mission statement by describing everything related to the service using IaC and leveraging built-in tooling to manage the APIs across different availability zones and regions.

Have a really great day!

This is an excerpt from DZone's 2024 Trend Report, Modern API Management: Connecting Data-Driven Architectures Alongside AI, Automation, and Microservices.

Read the Free Report