How Kinesis Scales

Scalability is essential for modern applications, and there are two main approaches to scaling:

1. Scaling Up Scaling up means increasing the resources allocated to a single server, such as CPU, RAM, or network bandwidth, to enhance the performance of an application. However, individual servers have physical capacity limitations, making infinite scalability impossible. Some workloads (e.g., earlier types of SQL servers) support only single instances, so the only way to improve their performance is by scaling them up.

2. Scaling Out Scaling out involves deploying the application across multiple servers to distribute the workload. This approach works best when the application has minimal dependency on state, allowing each instance to operate productively in parallel. For example, many modern applications can run efficiently across a large number of smaller instances, providing better scalability and resilience.

The Kinesis Approach to Scalability Kinesis supports both instance-based scaling and serverless workloads, giving customers the flexibility to scale their applications as needed:

• Instance-Based Servers: For applications that require dedicated server instances, Kinesis offers scalable instance-based servers to meet performance needs.

• Serverless Workloads: The true power of Kinesis lies in its ability to host serverless workloads. Serverless workloads are applications that can scale seamlessly across an arbitrary number of machines without requiring central coordination.

A great example of a serverless workload is REST APIs. When a customer makes a request, any instance in the cloud can handle it. If persistent changes are required, that instance can make modifications centrally (e.g., by writing to a database).

Properties	HTTP serverless	TCP serverless	TCP instance
Typical Workloads	Stateless Request/Response APIs (REST calls, blockchain RPC requests, LLM prompts).	Stateless workloads such as some webservers with their storage somewhere else or idempotent servers such as document servers, ftp servers, time servers, …	Stateful instances such as Database, Storage, Message Queue, Orchestrator, etc.
Number of nodes	Managed by portal (as influenced by customer settings)	Managed by portal (as influenced by customer settings)	Managed by customer
Endpoint Type	Single HTTPS endpoint	Single Domain:Port	Single IP:Port
Endpoint Example	https://<availability zone>.us-west-1.portal.kinesis.network/relay/<private accesskey>	<availability zone>.us-west-1.portal.kinesis.network:44112	34.56.78.90:43223
Transport Layer Security	Always on — endpoint is HTTPS	Optional — can be reached over regular TCP or optionally, over TLS to provide transport layer security as an added benefit	Optional — can be reached over regular TCP or optionally, over TLS to provide transport layer security as an added benefit
Load Balancing	Each new request hits the portal servers behind that URL. Afterwards it is rerouted / load balanced to one of the available containers unless customer preferred sticky sessions via a cookie.	Each new TCP connection (we don't care about its higher level protocol, could be FTP, could be HTTP) hits the portal servers behind that URL.	N/A - no load balancing. Customer hits their container directly. Suitable for only DC nodes. More performant than HTTPS serverless mode because there is no Portal in thepipeline. But also less redundant because there is no load balancer.
Scale up (provisioining the container with more CPU or RAM)	Automatic	Automatic	Automatic
Scale out (provisioning more containers on different servers)	Automatic	Automatic	Manual. Customer must manually add new servers.
Customer experience after scale out	Nothing changes in terms of access points, customer still calls the original endpoint, which automatically makes the best use of backing containers.	Nothing changes in terms of access points, customer still calls the original endpoint, which automatically makes the best use of backing containers.	They get a new endpoint. Akash supports only this mode. It is up to the customer to call this new endpoint.
Support for Global Nodes	Yes, supports both DC and Global Nodes.	Yes, supports both DC and Global Nodes.	No, only DC nodes. While global nodes can run them, customers wouldn't want them, because who relies on unreliable global nodes with their stateful workloads.
Security	is cryptographically unguessable. As long as customer keeps the access key private, no one else can use this endpoint.	Domain names and IP addresses are public. Attackers can connect to these endpoints. Containers must provide their own authentications (similar to db servers, file servers, printers, etc.)	Domain names and IP addresses are public. Attackers can connect to these endpoints. Containers must provide their own authentications (similar to db servers, file servers, printers, etc.)
Access	FW to allow/block source IPs.	FW to allow/block source IPs.	FW to allow/block source and destination IPs
Log Collection	Logs are collected from all nodes (typically at least two). Customer can filter per date, and logs will show what each server has sent them.	Logs are collected from all nodes (typically at least two). Customer can filter per date, and logs will show what each server has sent them.	Logs are collected from all nodes (well, typically only 1). Customer can filter per date, and logs will show what each server has sent them.

Discussion:

For TCP connections, the endpoints look something like platform1.us-east.kinesis.network:41883. Isn't this a blatant security/privacy issue? Don’t we need to generate subdomains with enough characters to get some sort of security via obscurity, like Akash with connection strings like 8vg98dm2mhahjfmsr063a4d5t8.ingress.d3akash.cloud

TCP is a basic Layer 4 transport protocol, hence doesn’t have any inherent access controls. This is why TCP applications bring their own access control (e.g. internet standards like Telnet, SMTP, FTP, SSH, HTTP, and proprietary formats such as RDP, SMB, MongoDB, etc.). Anyone can connect the TCP socket (i.e. have SYN-ACK handshake) but the server will demand proper authentication in that protocol or they will terminate the connection. That’s is simply how TCP apps work.

What security tools can we offer to our customers?

• We will support firewalls, so authenticated or not, they can reduce the attack surface dramatically. Authenticating requests at application layer still requires code (any code can be vulnerable), and malicious connections can consume server resources like memory (especially kernel memory). FW can reduce the attack surface from worldwide adversaries to a much smaller group.

• We will support TLS connections (which operates at Layers 4 to 7, hence bringing new features). TLS is a widely supported industry standard. TLS provides two benefits: 1) it allows server and client authentication via certificates. In this case, a client wouldn’t even run any of the app code with an unknown client. This is safer because it is another layer of protection and such common code paths in OS are typically more hardened than individual apps. 2) it allows transport layer security, which provides privacy and protection against tampering, replay attacks, etc.

Can cryptographically unguessable domain names be a form of security?

Unfortunately no, because DNS records are public and can be discovered by commonly available tools. Even if they weren’t, the backing IP addresses are known, and can be crawled and scanned.

Can we do more?

We could introduce a client side SDK that takes over portions of authentication and transport security. I am hesitant because managing a multi-platform SDK is not easy.