Skip to main content

Avassa - Distributed Application Management at the Edge

Avassa is an application management platform for distributed container applications. The platform targets use cases where applications are deployed in many locations and where the user requires precise control of application versioning and placement.

This document contains:

  • An explanation of why and how this distributed computational model – often referred to as edge computing or edge clouds – differs from today's mainstream public clouds
  • An overview of the Avassa architecture
  • A summary of the functionality in Avassa, mainly from a developer and DevOps' point of view

Distributed Edge Clouds​

The importance of geographically distributed computations is a consequence of the recent snowballing growth of decentralized data and its implications on security, privacy, performance, and scalability. Data processing often needs to be performed locally, rather than first moving the data to centralized applications. Local data processing often includes data filtering or transformation.

We call this distributed model the distributed edge cloud, in contrast to the traditional public cloud, which is centralized. The distributed edge cloud is not a replacement for the public cloud – it is an extension because the public cloud will integrate with data and computed insights from applications located on the distributed edge.

We can summarize the differences between public cloud and distributed edge cloud as follows:

The public cloud model assumes:

  • Many computers in a few very large datacenters
  • Fast and cheap networking between hosts in the datacenters
  • Application management tools are designed for optimizing resource utilization in the datacenters
  • Location is not essential for application placement and is generally abstracted from the user

The distributed edge cloud assumes:

  • Few computers in many locations
  • Applications and data is distributed across the many locations
  • There may be intermittent networking between the locations
  • The user explicitly controls the placement of applications across the edge sites

Public clouds are managed services that provide virtual and elastic resources, secure networking, and scalable infrastructure. The main reasons for using public clouds are simplified operations and application development.

The main reason for using distributed edge clouds, in contrast, is the rapid growth of decentralized data and the associated security, privacy, performance, and scalability requirements that do not exist in public clouds.

Summary of the Avassa Architecture​

The Avassa platform contains two software components:

The Avassa Control Tower provides central management of distributed edge resources and containerized applications through user interfaces and APIs. It is available as a service or can be installed on private infrastructure.

Control Tower

The Avassa Edge Enforcer is a software agent installed on all hosts in all edge sites. It provides zero-touch host registration functions, local cluster management, application placement and scheduling, and a local container registry. In addition, the Avassa Edge Enforcer provides local APIs for secrets management, and distributed event streaming for applications that require such services. Edge Enforceer

Distributed security​

When computing and applications are distributed across hundreds or thousands of sites, it is critical that data is protected both when in storage and when transported over the network. Physical theft is a real possibility in environments with little or no physical security.

Avassa removes the need to bundle secrets such as crypto keys, certificates, and third-party access credentials into application images. All sensitive data is accessed through fully authenticated and audited APIs, which allows secrets to be updated and crypto keys remain hidden without updating software images.

An intrusion at one site does not compromise data at other sites, and if a security breach occurs, it is easily isolated and mediated.

Secrets are automatically shared to sites where they are required, and policies are applied across the entire system. Sharing only occurs in one direction, from the management point and outward. Local secrets are not propagated upward to avoid poisoning from a potential breach.

Multi-tenancy​

Deep multi-tenancy is the fundamental enabler for allowing tenants to securely deploy applications across shared resources and make sure the applications run in isolation. Tenants are provided with dedicated and shared resources to form their unique view of the edge environment. Avassa is a multi-tenant system, where all components support strong isolation between tenants. Data is isolated between tenants, and tenant-specific network traffic is encrypted. The environment delivers fine-grained resource governance and limits-enforcement on container level for CPU, memory, and storage. Both for shared and tenant-specific deployment models.

Autonomy​

The Edge Enforcer provides a high degree of autonomous execution during control plane and connectivity outages. All control plane communication between Control Tower and Edge Enforcers are buffered locally until communication is restored and the same behaviour is available for applications using site-local service APIs. In these situations, the Edge Enforcer supports local management such as installing applications, reading and searching in logs, managing secrets locally (rotating keys, updating secrets, etc), and manual unsealing of sites if necessary. The Edge Enforcer also continues to manage and govern each site-local cluster including re-scheduling applications to new hosts in the event of host failures.

Developer and DevOps functionality​

We can divide the features for developers and DevOps in the following main areas:

  • Declarative deployment of applications at edge sites
  • Monitoring of applications and sites
  • Intrinsic support for distributing secrets to applications
  • Efficient application event streaming

The rest of this document contains an overview of these categories.

Declarative deployment of applications to edge sites​

From a developer and DevOps point of view, Avassa solves a core problem:

“Once I have my containers in a registry, how can I deploy them to the target edge sites?” That includes lifecycle management functions like monitoring the application health and upgrades. The lifecycle management behaviour is defined by two artifacts:

  • As a developer you write an “Application specification” that defines the structure of an application: which containers and associated resources and configuration?
  • As a DevOps you write a “Deployment specification” that defines placement policies for a specific application.

These specifications are declarative and the system constantly maintains the desired state. This in contrast to many other tools that are imperative. With Avassa you never have to actively perform actions like start and stop. If you modify the above specifications, like changing a container version, Avassa immediately calculates the minimum set of operations and converges the edge sites to the new desired state. This also makes it easy to integrate Avassa into your CI/CD pipeline. You maintain the specifications in your CI/CD and versioning environment and push them to Avassa when a new application version is published and needs to get deployed at all sites.

Avassa enables application focused lifecycle management. The application specification covers use cases from simple one container applications to complex applications with many services like database backends, application servers, web servers etc. You can focus on your application requirements rather than details in the infrastructure.

Examples:

  • Do a canary deployment of a specific application version on a set of sites
  • Upgrade the version of a container on all deployed sites
  • Change the configuration of the applications
  • Roll back the version update
  • Modify the placement for an application, resulting in automatically removing it from certain sites and adding it to other sites
  • View deployment status across all sites
  • Automatically trigger an application or placement update from your CI/CD environment

Monitoring​

Avassa supports two monitoring perspectives depending on the role associated to the tenant.

  • As a site provider you need to monitor the health of the sites and hosts on the sites
  • Application operations need to understand the health of the deployed applications

Site providers own and manage the edge infrastructure that the applications are running on. Therefore it is important to monitor the sites which includes:

  • the state of the edge cluster itself: networking, control plane status etc
  • the hosts on the site: resource utilization

Application teams need to monitor the application health. It is very important to get a overall insight into if applications are responding well to requests and acting according to expectations. This is different from digging into logs to see if everything is ok. Avassa provides aggregated views of the applications health and supports drill-down all the way into container health and logs.

Avassa also provides distributed logging at each site and real-time search from the Control Tower into the site-local logs and metrics. This distributed approach is highly efficient and scales to thousands of sites. Monitoring includes both logging and metrics.

Monitoring and logging is available over the built in event bus. APIs makes it easy to integrate monitoring data and logs towards tools like Cloudwatch.

Examples:

  • Get an overview of the health of an application across sites
  • Drill-down to understand issues in an application on a site
  • See the on-going status of an application deployment
  • See resource utilization by an application and its containers
  • Get notification when Control Tower loses connection to a specific site
  • See logs for a site
  • See logs for a container

Efficient event streaming​

Event streaming solutions have proved to be solid building blocks of loosely coupled distributed systems. A high-performance event streaming service is an integral part of the Avassa system. Applications can use the streaming service to produce and consume messages.

Key features include:

  • Replicated, persistent, and volatile event queues with arbitrarily many producers and consumers to any given topic
  • Full support for Avassa's multi-tenancy model
  • Most edge sites are located behind NAT firewalls. The streaming service has full support for producing to and consuming from topics at such edge sites
  • Each streaming topic is replicated on compute nodes on one edge site.
  • A distributed log query service : this service facilitates very fast queries over application logs for a large number of sites
  • Very small footprint, allowing event streaming even at small single-host edge sites
  • Built-in strong encryption and user authentication. User data is always passed over a websocket API, ensuring strict isolation between users on the same Volga implementation

Event streaming is used in many loosely coupled distributed systems. The three examples below illustrate how powerful this technology is in a distributed edge cloud environment.

  1. Event sourcing

    Example: A central application wants to propagate a configuration change to all sites. This can be done by:

    • Post the change into the Control Tower
    • Consume the change at the edge sites.

    This is a good way to organize loosely coupled distributed applications.

  2. Aggregation

    Example: An application with many edge sites where large amounts of data is produced at these sites. Due to either cost or bandwidth, data must be aggregated and refined before it is pushed further up in the network.

    Such an application would publish data on one or several topics locally at each site. Data would typically then be consumed and refined locally and either re-produced to an aggregation topic locally or produced remotely to an aggregation topic in a central application.

  3. Distributed metrics

    Example: Metrics generated at edge site is best produced to local site topics. To query and search such metrics, a request to search can be posted to the Control Tower. This is a means to have all metrics data distributed without ever accumulating data centrally. If the number of edge sites is very large and the amount of metrics data is large, this is a good way of avoiding central bottlenecks.

Intrinsic support for distributing secrets to edge applications​

The Avassa platform embeds a system-wide distributed service for managing secrets and policies. Secrets are automatically shared to sites where they are required, and policies are applied across the entire system. Sharing only occurs in one direction, from the central management point and outward to the edge sites. Local secrets are not propagated upward to avoid poisoning from a potential breach.

Key features include:

  • Cryptographic isolation of secrets between tenants and sites, separate keys for each tenant and site
  • A one-step operation to block a tenant, a site, and a host
  • Fine-grained control of how secrets are distributed to sites
  • Local secrets storage is sealed until remotely unsealed
  • Fully audit-logged access to secrets
  • Centralized key management: key rotation, revocation, access
  • Encrypt and decrypt services that allow use without access to actual crypto keys
  • API for format-preserving encryption/decryption as well as masking of data before logging, storage, and transport
  • Fully encrypted and authenticated communication both between sites (inter-site) and between hosts at a site (inter-host)
  • Mount secret as files in the file system for a container

Examples:

  • Store access credentials to AWS
  • On a specific site, encrypt data before sending it in a Volga message to Control Tower
  • Post mortem analysis of accesses to secrets after detected intrusion on a specific site
  • Block sia site after a security breach was detected
  • In a specific application, mask the social security number of the patient before logging
  • FPE (Format Preserving Encryption) of credit card number before storing in database for customer registration in a specific application on a specific site
  • Rotate a customer certificate
  • Sign an x-ray image using certificate before storing in the local file system on a specific site
  • Store secret configuration parameters for application

Conclusion​

The Avassa platform is an easy-to-use, secure and scalable solution to the challenges of running container-based applications in a distributed environment. We would love to show it to you tell you more in detail about how others are using it. Please contact us to schedule a demo or join our trial program and get access to a running system.