- 1.1 The Need for a Distributed Services Platform
- 1.2 The Precious CPU Cycles
- 1.3 The Case for Domain-Specific Hardware
- 1.4 Using Appliances
- 1.5 Attempts at Defining a Distributed Services Platform
- 1.6 Requirements for a Distributed Services Platform
- 1.7 Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.5 Attempts at Defining a Distributed Services Platform
The first question we should ask ourselves is, “Which services should this architecture support?” A precise classification is difficult, if not impossible, but Figure 1-2 is an example of some of the services typically associated with a domain-specific platform.
)
FIGURE 1-2 Services
From 10,000 feet, we can see two groups of services: infrastructure services and value-added services.
Infrastructure services are things such as Ethernet and bridging, IP and routing, storage access through a modern protocol like NVMe, RDMA transport, TCP termination, and overlay network processing.
Value-added services include a firewall, load balancer, encryption (both symmetric and asymmetric, both in flight and at rest), key management and secure storage, classical VPNs like IPsec, and more modern ones such as SSL/TLS, storage compression, and deduplication.
In this book, we will present infrastructure and value-added services together because they are deployed together in the majority of the cases.
The first attempt at a truly “distributed” network architecture can be traced back to software-defined networking (SDN). SDN is a paradigm that was introduced initially on switches and routers but was expanded to servers. It offers the capability to control and program the NIC virtual forwarding functions.
The main focus of SDNs is on infrastructure services. They do not currently address value-added services, but they create a framework where DSNs are under the central coordination of a common manager and work together toward a common goal.
There is also an open-source effort within the container community, called service mesh, that defines the services, such as load balancing, telemetry and security, distributed across the clusters of nodes and combined with a management control plane. The approach uses a software proxy sitting next to an application to provide layer 4 or layer 7 load balancing features and TLS security between applications and provide telemetry for all the traffic that passes through the proxy. The management control plane provides integration with orchestration systems, such as Kubernetes, and also provides a security framework to do key management for applications and define authorization primitives that can police interapplication communication. Although the effort started for containers, the concepts and code can be leveraged for virtual machines. There are many implementations of service mesh, such as Istio, Nginx, Linkerd, and some commercial closed-source implementations.
It is definitely possible to provide a much superior service mesh with DSNs by offering better security via keeping private keys within the hardware root of trust, by improving performance by an order of magnitude, and by reducing interapplication latency, without losing the software programmability.
The distributed services platform also attempts to address a few additional elements:
Provide immunity from host/application/hypervisor compromises; that is, the enforcer shouldn’t be compromised if the enforcee is compromised
Provide services beyond the network, for example, storage, RDMA, and so on
Offer low latency, high throughput, and latency isolation without impacting application performance
Exhibit cloudlike scale to handle millions of sessions
A distributed services platform may be used alongside service mesh, which is an application layer concept, as opposed to an infrastructure layer concept. For example, the distributed services platform may provide isolation, security, and telemetry at the virtualization infrastructure layer, whereas service mesh can provide application layer TLS, API routing, and so on.