pulumi/docs/design/runtime.md

## Coconut System Services

TODO(joe): describe package manager, artifact repository, CI/CD, the relationship between them, etc.

## Runtime Services

TODO(joe): describe logging, Coconut correlation IDs, etc.

TODO(joe): describe what out of the box runtime features are there.  It would be nice if we can do "auto-retry" for
    service connections...somehow.  E.g., see https://convox.com/guide/databases/.

TODO(joe): consider something like Kubernetes DaemonSet abstraction.

## Extensibility

There are three general areas of extensibility:

* *Container/runtime*: A service with a runtime footprint may be backed by a Docker container, VM, cloud-hosted
  abstraction (such as an AWS Lambda), or something else.  It is possible to use your favorite technologies and
  languages for implementing your service, in a 1st class way, without Coconut dictating a preference.

* *RPC*: Any service with an RPC interface associated with it may be bound to anything that speaks a "JSON-like" wire
  protocol.  This might be your RPC framework of choice, such as gRPC or Thrift, or even hand-rolled REST over HTTP.

* *Events*: Any service that exposes events that can be subscribed to can be bound to any runtime that similarly deals
  with "JSON-like" payloads.  This might be your favorite PubSub framework, such as Kafka or AWS SNS.

Coconut doesn't have a strong opinion on your choice, and permits mixing and matching, although in each case it also
provides a simple runtime choice that can be used by default for a seamless and simple experience.  Either way,
out-of-the-box providers exist to both bind to your favorite frameworks, and also generate code for them so that, for
instance, you needn't manually keep your RPC framework's interfaces in synch with Coconut service interfaces.
Coconut! 2017-02-25 16:25:33 +01:00			`## Coconut System Services`
Reorganize documents a bit and add an index 2017-01-02 00:18:36 +01:00
			`TODO(joe): describe package manager, artifact repository, CI/CD, the relationship between them, etc.`

			`## Runtime Services`

Coconut! 2017-02-25 16:25:33 +01:00			`TODO(joe): describe logging, Coconut correlation IDs, etc.`
Reorganize documents a bit and add an index 2017-01-02 00:18:36 +01:00
			`TODO(joe): describe what out of the box runtime features are there. It would be nice if we can do "auto-retry" for`
			`service connections...somehow. E.g., see https://convox.com/guide/databases/.`

Overhaul the stacks.md design document The stacks.md document used to describe the metadata format. Now that we've moved away from the old model of YAML + Go templates, and created the MuPack/MuIL format, this document needed to be overhauled. It's pretty bare bones now, however it will eventually evolve into a document describing how the Mu abstractions map down onto MuPack/MuIL concepts. For example, it describes how subclassing mu.Stack creates a "stack", even though at the MuPack/MuIL level it's just any old subclass. 2017-01-02 03:06:03 +01:00			`TODO(joe): consider something like Kubernetes DaemonSet abstraction.`

Flesh out a bunch of things 2017-01-02 01:17:30 +01:00			`## Extensibility`

			`There are three general areas of extensibility:`

			`* Container/runtime: A service with a runtime footprint may be backed by a Docker container, VM, cloud-hosted`
			`abstraction (such as an AWS Lambda), or something else. It is possible to use your favorite technologies and`
Coconut! 2017-02-25 16:25:33 +01:00			`languages for implementing your service, in a 1st class way, without Coconut dictating a preference.`
Flesh out a bunch of things 2017-01-02 01:17:30 +01:00
			`* RPC: Any service with an RPC interface associated with it may be bound to anything that speaks a "JSON-like" wire`
			`protocol. This might be your RPC framework of choice, such as gRPC or Thrift, or even hand-rolled REST over HTTP.`

			`* Events: Any service that exposes events that can be subscribed to can be bound to any runtime that similarly deals`
			`with "JSON-like" payloads. This might be your favorite PubSub framework, such as Kafka or AWS SNS.`

Coconut! 2017-02-25 16:25:33 +01:00			`Coconut doesn't have a strong opinion on your choice, and permits mixing and matching, although in each case it also`
Flesh out a bunch of things 2017-01-02 01:17:30 +01:00			`provides a simple runtime choice that can be used by default for a seamless and simple experience. Either way,`
			`out-of-the-box providers exist to both bind to your favorite frameworks, and also generate code for them so that, for`
Coconut! 2017-02-25 16:25:33 +01:00			`instance, you needn't manually keep your RPC framework's interfaces in synch with Coconut service interfaces.`
Flesh out a bunch of things 2017-01-02 01:17:30 +01:00