The meteoric rise of cloud-based infrastructure and services over the last decade has completely changed how modern applications are built and deployed. Gone are the days of self-contained monolithic architectures where every dependency runs within your corporate network. Modern developers instead rely on a wide range of external APIs and services to power essential features and deliver business outcomes faster. While this paradigm has many clear benefits, it also introduces a host of new operational challenges:

• Reliability of platforms and core applications now hinges on the health of these external dependencies. An issue with a vendor's API may become your outage.
• Troubleshooting the root cause of an issue has become significantly more complex.
• Limited visibility into external requests and payloads which may contain sensitive information poses a serious data governance risk.

Qpoint is the first purpose-built solution to enable operators to easily see and control their app's mission-critical external services and traffic to deliver unparalleled reliability, security, and game changing insights in minutes.

At the heart of Qpoint’s technology is an eBPF probe (Qtap) that runs in the data plane on your application hosts. Qtap operates on outbound application traffic (out-of-band) at the kernel level before encryption, providing access to the payloads while avoiding the need to manage certificates.

Qpoint's middleware subsystem further enables an operations team to seamlessly inject custom functions and execute complex traffic manipulations.

Our cloud control plane serves as the central nervous system for Qpoint by providing a graphical interface for users to monitor the status of endpoints, browse audit logs, configure alerting, and manage the fleet of eBPF probes deployed on the data plane.

The short answer: only if you explicitly choose to use Qpoint’s managed service for monitoring and analytics.

A Qpoint installation can generate two types of data:

• Logs: Logs contain metadata about the connection, the request, or the error, but do not contain payload information of any kind. Logs can be shipped to any log ingestion service.
• Snapshots: Conditionally generated snapshots are the actual request/response headers and bodies. Snapshots are submitted to S3 compatible endpoints (optionally encrypted).

For production deployments and highly-regulated environments, we strongly recommend using your own S3-compatible endpoint running within your own environment. You can also optionally run our custom monitoring and analytics service (Pulse) within your environment.

We offer the option of using Qpoint's fully managed Pulse service for operational simplicity, but no data will leave your network unless you explicitly choose to use this service.

Qtap provides native TLS introspection into most languages, including the following that are confirmed to work: Ruby, Python, Nodejs and Golang. Any utility that uses OpenSSL is also supported. Languages that do not currently support native TLS introspection are Java, .NET, and Erlang (but support is coming soon).

Qtap accesses the kernel via eBPF and also runs a user space application. The impact on CPU and memory is highly dependent on both the size and number of services running on the host.

Getting started with endpoint discovery, basic monitoring, and audit logging will have a minimal impact on system resources.

The impact of running more advanced middleware will depend on the nature of the functions that are running and how much of the overall traffic has middleware applied.