mirror of
https://github.com/fnproject/fn.git
synced 2022-10-28 21:29:17 +03:00
a32ca3d90a
* moving documentation around to be more clear and easier to browse - moved assets into their own directory and updated links to them - moved operating docs into their own directory - consolidated kubernetes docs - added docker-swarm folder for docs - updated docs layout in docs/README.md to reflect the changes and make it easier to read * docs: s/Operating Functions/Operating IronFunctions/ * docs: removing duplicate database link * docs: moving databases into general docs * docs: moving databases/mqs back * docs: removing memory.md (duplicate of operating/routes.md) * docs: converting to markdown bullets
46 lines
2.3 KiB
Markdown
46 lines
2.3 KiB
Markdown
# Running IronFunctions in Production
|
|
|
|
The [QuickStart guide](/README.md) is intended to quickly get started and kick the tires. To run in production and be ready to scale, you need
|
|
to use more production ready components.
|
|
|
|
* Put the IronFunctions API behind a load balancer and launch run several instances of them (the more the merrier).
|
|
* Run a database that can scale.
|
|
* Asynchronous functions requires a message queue (preferably one that scales).
|
|
|
|
Here's a rough diagram of what a production deployment looks like:
|
|
|
|
|
|
|
|
## Load Balancer
|
|
|
|
Any load balancer will work, put every instance of IronFunctions that you run behind the load balancer.
|
|
|
|
**Note**: We will work on a smart load balancer that can direct traffic in a smarter way. See [#151](https://github.com/iron-io/functions/issues/151).
|
|
|
|
## Database
|
|
|
|
We've done our best to keep the database usage to a minimum. There are no writes during the request/response cycle which where most of the load will be.
|
|
|
|
The database is pluggable and we currently support a few options that can be [found here](/docs/databases/). We welcome pull requests for more!
|
|
|
|
## Message Queue
|
|
|
|
The message queue is an important part of asynchronous functions, essentially buffering requests for processing when resources are available. The reliability and scale of the message queue will play an important part
|
|
in how well IronFunctions runs, in particular if you use a lot of asynchronous function calls.
|
|
|
|
The message queue is pluggable and we currently support a few options that can be [found here](/docs/mqs/). We welcome pull requests for more!
|
|
|
|
## Logging, Metrics and Monitoring
|
|
|
|
Logging is a particularly important part of IronFunctions. It not only emits logs, but metrics are also emitted to the logs. Ops teams can then decide how they want
|
|
to use the logs and metrics without us prescribing a particular technology. For instance, you can [logspout-statsd](https://github.com/iron-io/logspout-statsd) to capture metrics
|
|
from the logs and forward them to statsd.
|
|
|
|
[More about Metrics](metrics.md)
|
|
|
|
## Scaling
|
|
|
|
There are metrics emitted to the logs that can be used to notify you when to scale. The most important being the `wait_time` metrics for both the
|
|
synchronous and asynchronous functions. If `wait_time` increases, you'll want to start more IronFunctions instances.
|
|
|