Temporal application deployment

Support
#1

Mere my curiosity and ignorance.
Let us say I have small Temporal application developed using Go SDK comprised of some workflows and activities and related Go functions.

  1. How Temporal application assembly and deployment works? Is it typical Go development practices?
  2. How the Docker which contains Temporal service deployed?
  3. How Temporal service and Temporal Client application(Activities & Workflows) are deployed in production?
  4. What exactly is the Client tier for a temporal server and Temporal application developed?
  5. How Mobile/Web clients communicates with services in Temporal application deployed?
  6. Will there be any Rest API application in between Mobile/Web clients and Temporal service, As CLI is more of developer tool?
  7. How third party application communicate with Temporal application?
  8. As a developer what are all I need know or take care about database like Apache Cassandra or MySQL?
  9. How authentication and authorization are taken care of? What about data security?

Can someone assist me in answering above questions? Questions may be overlapping, but general briefing will help me understand better.

2 Likes
#2

Hi Gopinathan, thank you for playing with Temporal!

To follow up on #2 (and, in part #3):

  1. How the Docker which contains Temporal service deployed?
  2. How Temporal service and Temporal Client application(Activities & Workflows) are deployed in production?

Here are a couple of possible options for running temporal in docker (which may also apply to running your application):

  1. using docker-compose

Temporal codebase includes a few docker-compose files, which cover a few different configuration options (e. g. mysql and cassandra persistent stores). https://github.com/temporalio/temporal/tree/master/docker

  1. in a kubernetes cluster.

To assist you with deploying to a kubernetes cluster (e. g. AWS EKS), Temporal codebase includes a Helm chart https://github.com/temporalio/temporal-helm-charts

  1. with any other docker orchestration technology (e. g. none, or docker swarm).
#3
  1. Temporal is not opinionated about the way an application is deployed. Both workflow and activity code is deployed and operated outside of the control of the Temporal gRPC service. So we recommend whatever deployment infrastructure you are already using for your Go or Java applications.
  2. The service itself is just a Go binary which needs some environment variables and configuration files to start. So it can be deployed in a variety of ways. The docker is the most common way to package the binary and Kubernetes is the most common way to deploy it to production. You can use the supported helm-chart. For development, we recommend using the docker-compose deployment of the service to a local machine. Mark provided more details on this one.
  3. No hard requirements here. The most common at this point is K8s, but there are many other ways to deploy them.
  4. Use the approach you are already using. Temporal doesn’t impose any requirements on the client tier deployment besides that it should be able to reach the service gRPC frontends through some sort of load balancer.
  5. They usually don’t communicate with Temporal service directly but through some sort of application-specific services.
  6. We might add support for Rest API at some point in the future, but currently gRPC is the only option. CLI is mostly for development.
  7. They usually communicate through some sort of application-specific proxy. If all the applications are part of the same organization they can communicate through the service gRPC API directly or through the Java or Go SDKs.
  8. Currently, Temporal MySQL binding doesn’t support sharding. So if you need a highly scalable deployment you want to go with Cassandra.
  9. TLS is supported to secure the connections. We are going to add more authentication and authorization features in the future.