Learn how APIClarity allows you to monitor the API calls within and outside your application service.

Where we came from

Over the last decade we have been moving to Cloud Native deployments for most of our application and API deployment. This has mostly been an effort to break legacy monolithic application and service models into what we commonly refer to as microservices. Most of that move has been most successful under Cloud Native technologies utilizing containers and container orchestration. This move has been handled utilizing Kubernetes, Docker, and other similar technologies.

The current state

We have utilized a lot of benefits of moving to a microservices model using Cloud Native technologies. We can iterate on specific pieces of our apps and services while not having to touch other correlating and parallel apps and services that help provide experiences to our end users. We can better utilize agile and lean methodologies of software development. We can deploy dev environments more easily and test more frequently giving us the ability to move fast and break things.

The problem is, deploying and exposing our APIs with Cloud Native technologies has been a source of security breaches and penetration into our applications and services.

TLDR?… Enter APIClarity

So, we want to use Cloud Native technologies for all of the benefits they bring to microservice software development. However, we also want to have better visibility to see when our APIs are being utilized properly (or improperly). This will help improve our security posture. It will also improve software delivery, and testing in general to our API services that are deployed.

This is where APIClarity really shines. APIClarity helps monitor API usage and utilization by using service mesh technologies, like Istio, to capture API endpoint traffic. It does this without having to modify existing API services, which is where service-mesh infrastructure is utilized.

APIClarity helps to sync current API usage with existing OpenAPI Spec docs. This is important because you can then detect shadow or undocumented APIs that applications or other services are using on your API microservice. It detects the use of zombie / deprecated APIs that should have been killed off. And it allows you to be alerted when a discrepancy occurs.

APIClarity allows you to construct OpenAPI specs through observation of your APIs that do not currently have an OpenAPI spec. This is huge! Because you can then upgrade your API services to utilize OpenAPI spec docs. Thus, allowing for better documented APIs for your developer teams and customers.

Check out this demo. You’ll see how APIClarity allows you to monitor the API calls within and outside your application service, and how quickly you can get started with adding APIClarity to your application deployment using GitLab.

To get started with APIClarity…

1. Watch the short Snack Minute videos to see how you can manage multiple APIs with the new open source API observability tool APIClarity
2. Check out the site and docs
3. Checkout the Github repo

If you really want to take it further you can utilize this repo, where we guide you to build a private kubernetes cluster using k3s and GitLab from scratch and then running through the same process as we used in this article to deploy our sample app with GitLab CI/CD.

In my next blog, I’ll show you an example of how we are utilizing GitLab CI/CD with Kubernetes, Istio, and APIClarity to deploy a sample microservices app and control the lifecycle management of our sample application.

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel

Share: