Announcing the Private Beta of Synadia Cloud Applications

Building applications is about more than just typing code, especially for large-scale, distributed systems. There are numerous aspects to consider, such as tagging resources, managing idle resources to control costs, handling logs, events, traces, metrics, authorization, authentication, fail and restore processes, and multi-tenancy. And this is all before addressing messaging, data storage and retrieval, and file or blob management.

For years, NATS has been the de facto standard for building messaging-based applications. With the introduction of JetStream, we gained the capability to persist highly available streams that withstand server unavailability. Soon after, key-value and object stores further enhanced our applications for free, without requiring a new integration or dependency.

A common pattern we see today is teams starting with NATS for messaging and quickly adopting additional features, embracing what we call a "Nothin' but NATS" approach. Many applications can rely entirely on just NATS.

Now, with various applications and services depending on your NATS infrastructure, wouldn’t it be great to deploy those applications using the same system? The answer is a resounding yes.

We are thrilled to announce the private beta of the third foundational pillar of NATS, after connectivity and data: workloads. Built on our open-source project Nex, this marks the beginning of a journey toward a powerful set of features, reinforcing the “Nothin’ but NATS” style—a specialized form of the "cloud-native" pattern that extends to the edge.

Deploying in Synadia Cloud

Synadia Cloud Applications provide a managed, turnkey experience. Define your application components, specify where and how you want them to run, upload your software, and let Synadia Cloud handle the rest.

An application is a logically related set of components. A component is a specification for a workload that can be deployed. A workload is anything that can be executed. Workloads can be long-running services (e.g., native binary executables and, eventually, OCI images) or functions (e.g., JavaScript, WebAssembly). If your service can be compiled into "just a binary," we'll run it in a secure sandbox without extra hassle or unpredictable packaging.

So what does it look like?

If you're familiar with other app scheduling products, you probably know about the concept of an application specification (often called a "manifest"). To create a new application specification, the following command is used which will prompt for information:

$ synctl app new

You'll be left with a .json file that corresponds to the name of your application. For this example, I've created one called helloworld. The following is the resulting application specification file:

1
{
2
  "name": "helloworld",
3
  "version": "0.0.1",
4
  "description": "My new application",
5
  "components": [
6
    {
7
      "name": "echofunction",
8
      "description": "This is the echo function",
9
      "trigger_subjects": [
10
        "hello.function"
11
      ],
12
      "workload_type": "v8",
13
      "placement_policy": {
14
        "policy_name": "fixed_scale",
15
        "instances": 1,
16
        "regions": [
17
          "us-east"
18
        ]
19
      }
20
    },
21
    {
22
      "name": "echoservice",
23
      "description": "This is the echo service",
24
      "workload_type": "native",
25
      "placement_policy": {
26
        "policy_name": "fixed_scale",
27
        "instances": 1,
28
        "regions": [
29
          "us-east"
30
        ]
31
      }
32
    }
33
  ]
34
}

The generated spec defines two components: echoservice and echofunction. Each of those will be deployed in the us-east region and Synadia will ensure that we only ever have a single instance of them running. As the name implies, the service is always up and running and the function is executed on demand in response to a triggering NATS subject.

Ordinarily we would have to ensure that we upload artifacts to Synadia such as the echofunction.js file and the native executable for echofunction. However, because these are available to everyone in the private beta, we can skip that step for now. In the near future, you’ll even be able to use a GitHub Action that pushes your artifacts directly into your Synadia Cloud account and one that can update your application specification.

Take a look at the code we don’t have to write in the JavaScript function:

1
(subject, payload) => {
2
  console.log(subject);
3
  return {
4
    triggered_on: subject,
5
    payload: String.fromCharCode(...payload)
6
  }
7
}

All deployed functions have access to our host services, which include access to messaging, key value stores, object stores, and even an HTTP client. The days of worrying about connection strings are finally over.

1
(subject, payload) => {
2
  this.hostServices.kv.set('hello', payload);
3
  this.hostServices.kv.delete('hello');
4

5
  this.hostServices.kv.set('hello2', payload);
6
  return {
7
    keys: this.hostServices.kv.keys(),
8
    hello2: String.fromCharCode(...this.hostServices.kv.get('hello2'))
9
  }
10
}

Now let's deploy the application:

$ synctl app deploy --name helloworld --version 0.0.1

The CLI will give us some output indicating that the application has been deployed. We can watch the status of the application and its components change in real-time using either the CLI or the Synadia Cloud app similar to what is shown in this screenshot:

With just those two commands, we've got an application deployed in our Synadia Cloud! To prove that it’s up and working, you can use the nats CLI just like you would any other application. Using the correct nats context that connects to your account, you can make requests:

1
$ nats req hello.function 'hello'
2
└─❯ nats req hello.function "hello"
3
09:54:16 Sending request on "hello.function"
4
09:54:17 Received with rtt 1.030000226s
5
{"triggered_on":"hello.function","payload":"hello"}

It may be worth it to take a step back and digest what’s happening here. We’ve created an application from our code in a matter of seconds, deployed it into Synadia Cloud, and a function in that application can be triggered by subjects in our account.

When we're done playing with the application we can easily stop it:

1
$ synctl app stop helloworld

With the application stopped, we can see the important historical events in the app timeline as shown in the web UI:

Ready to get started? Sign-up for the private beta waiting list and we will notify you when your access is ready.

I personally can't wait to start deploying all of my projects to Synadia Cloud, and make sure you stay tuned to our blogs, talks, and videos for more news and announcements about Synadia Cloud Applications.

About the author

Kevin Hoffman is the Director of Engineering for Synadia Platform. He has devoted most of his career to building distributed systems and making it easier and fun for developers to do the same.