Systems | Development | Analytics | API | Testing

TBC Bank is a technology-driven company in Georgia. We are happy to announce that we have chosen Kong to improve our API ecosystem and leverage its technological resources, expertise and international footprint to further simplify the daily lives of our users. TBC wanted to partner with a company that, in addition to providing the technology platform required to publish APIs in our bank, would also offer a strategy for developing and implementing API management principles.

This is the second part of our three-part blog series on APIs, sustainability and climate change. Missed the first part? Check it out here. In this blog, we examine ways to consume and embed APIs to make our own processes greener and show how APIs are the building blocks of a new wave of green innovation. The API economy – and therefore the ways we can use APIs to cut carbon emissions and make technology more sustainable – is not just about building APIs but consuming them too.

The proliferation of microservices has led to many new innovative approaches in the software world. However, building robust, quality APIs that consistently deliver the business outcomes you desire can be a complex task. It’s no wonder a recent survey of organizations adopting microservices found that nearly 30% of the respondents listed “API quality” as one of their biggest challenges. API-based applications don’t just come in one flavor.

The quest for resilience and agility has driven us into the modern age of microservices. Bringing services to market on a microservice architecture demands utilization of sprawling technology offerings and tooling. While daunting at first glance, we can break down the process into 3 major categories: In this hands on series, we will use.

The API management space is changing – fast. In the past couple of years alone, we’ve seen huge changes in the deployment patterns that our customers are adopting. In the past, when the use cases were fairly simple, organizations would deploy an API gateway as a SaaS monolith in the cloud, sitting at the edge of the network. They did this because it was the best option available at the time, and the first wave of API management vendors like Apigee had a solution that could support it.

I’ve just got off a call with one of the largest banks in Sweden, and my brain is racing with ideas. I need to get this down on paper. I want to drop everything I’m doing and spend the next week in that mental headspace where all you do is explore and live and breathe a topic, with occasional breaks for sleep, after which you race out of bed so you can go back to where you left off. You know what I mean. What’s got me so fired up? Climate change.

It’s not uncommon for organizations to have to deploy solutions across (or among) multiple security domains. Here, we use the term “security domain” to refer to a segregated network environment, like a restricted internal network or a DMZ. This post will explore some design considerations when deploying Kong Mesh (and Kuma, the CNCF-hosted open source project upon which Kong Mesh is built) in environments with multiple security domains.

Today, we’re excited to announce the release of Kong Gateway 2.8, which further simplifies API management and improves security for all services across any infrastructure. This announcement demonstrates Kong’s continued commitment to our customers and community by providing a next-generation service connectivity platform to intelligently broker information across modern architectures.

In applications built on a system of microservices, developers should always be on the lookout for opportunities to eliminate unnecessary use of resources, such as database queries, network hops or service requests. API gateway cache (or response caching) is an excellent place to start. For many microservices, identical requests sent within a window of time will yield identical responses. For example, consider a request to an Orders API for the list of orders submitted yesterday.