Deployment model

Full automation across multiple cloud provider regions and multiple cloud providers is available through Akka’s fully-managed platform. You choose to run your Akka services in

Akka platform manages the fully-automated regions running your Akka services and takes responsibility for SLAs tied to elasticity, agility, and resilience of your Akka services.

For organizations that want control over how Akka services are installed, updated, and maintained. Akka services are packaged into standalone binaries with Akka clustering for scaling and deploy to self-managed nodes. You are responsible for separately managing secure connectivity, routes, installation, deployment, and persistence.

During development, Akka services run directly on the developers' machines, enabling fast iteration cycles without the hassle of shared infrastructure.

A project is the root of one or more services that are meant to be deployed and run together. The project is a logical container for these services and provides some common management capabilities. Projects contain a list of regions that they deploy to. One of the regions will always be the primary region which acts as the source of resources to replicate between regions. This will be the first region that deployments roll out to. By default, the primary region is the first region specified when creating a project. More detail on regions is covered below in physical deployment.

Services are the core unit of deployment in Akka. They equate to the concept of a microservice and contain all your components and objects as described in the Akka architecture model. A project contains one or more services. Services can be started, stopped, and paused independently. They can also be scaled independently making them also the unit of scale.

Regions are specific clusters running Akka in a specific place. Regions are designed to run independently for greater availability. They are also designed to replicate data asynchronously between each other. Every Akka project specifies a list of one or more regions in which it runs.

In addition to your services from a project, a region also has endpoints for your API. You define endpoints within the API layer and Akka will expose them. They will be unique to each region. That is they will have unique DNS, much like AWS services S3 and SQS do.

Container registries exist in all Akka.io regions so that the images that are your packaged services are in close proximity to the compute they will run on.

A given cloud provider region may have many Akka regions within it. In this way Akka can scale past any upper bound limits of the infrastructure on which it runs.

Stateful components in Akka have a concept of location, that is region, and are designed to span regions and replicate their data across regions. This is outlined in state model and multi-region operations. These components call the region where they can be updated their primary region and keep track of it throughout their lifetime. This allows Akka to simplify some aspects of distributed computing.

In Akka projects, regional choices are made at deployment time, not development time, allowing you to change your regions over time and even change your primary region. You can also control if your service is in pinned-region or request-region mode of regionalization, which impacts where the primary copy of component data resides. For more information see multi-region operations.

By default, most entities will only allow their primary region to change their state, to make this easier Akka will also automatically route state changing operations to the primary region. This gives you a read anywhere model out of the box that automatically routes writes appropriately.

If you use more sophisticated state models you can have a write anywhere model. See state model for more details.

Regions can be added to or removed from an Akka project while it is running. There is no need to stop the services within the project to do this.