From acb7028471b39cb7fddc93d5633e17a32fddfca3 Mon Sep 17 00:00:00 2001 From: David Erwin Date: Fri, 14 Jul 2017 16:01:57 -0400 Subject: [PATCH 1/5] Write microservice docs --- docs/_data/sidebars/talk_sidebar.yml | 3 ++ docs/install-microservices.md | 63 ++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+) create mode 100644 docs/install-microservices.md diff --git a/docs/_data/sidebars/talk_sidebar.yml b/docs/_data/sidebars/talk_sidebar.yml index 02cac9f3f..b483b47d1 100644 --- a/docs/_data/sidebars/talk_sidebar.yml +++ b/docs/_data/sidebars/talk_sidebar.yml @@ -36,6 +36,9 @@ entries: - title: Setup url: /install-setup.html output: web + - title: Microservice Deployments + url: /install-microservices.html + output: web - title: Troubleshooting url: /install-troubleshooting.html output: web diff --git a/docs/install-microservices.md b/docs/install-microservices.md new file mode 100644 index 000000000..4100c4cac --- /dev/null +++ b/docs/install-microservices.md @@ -0,0 +1,63 @@ +--- +title: Microservice Deployments +keywords: install +sidebar: talk_sidebar +permalink: install-microservices.html +summary: +--- + +The Talk server serves several logically/architecturally distinct functions: + +* A web server that + * serves "public" assets (aka, the comment embed) + * "protected" assets (aka, the admin console) over http(s) + * the GraphQL endpoints +* A web socket server that handles subscriptions. +* A jobs processor that handles queued operations. + +In the documentation so far, we've discussed how to deploy all of these functionalities bundled into a single monolith application. This is convenient as there is minimal configuration and horizontal scaling is as easy as upping the number of servers behind a single load balancer. + +## Separating Talk into Microservices + +Talk can be run as three separate clusters of servers: webserver, socket server and jobs server. + +Note that the `cli serve` command, which is responsible for starting the server, contains flags that control whether `jobs` and `websockets` are enabled. + +``` +talk :) ]$ bin/cli serve --help + + Options: + + ... + -j, --jobs enable job processing on this thread + -w, --websockets enable the websocket (subscriptions) handler on this thread + ... +``` + +Each Talk Microservice cluster can be deployed in an identical manner described in the other docs in this section with the omission of the `-j` and/or `-w` flags. + +With routing logic in front of the webserver cluster, separation between public and protected assets can be achieved. + +## When should I consider separating? + +Consider a microservice deployment if: + +* you want to put access to admin routes behind a firewall +* you are running plugins that require intensive job processing +* you do not want to simplicity of single cluster horizontal scaling and want to tune the economy and performance of your install. + +At scale, combining separate concerns in a single process makes it very difficult to understand what is taking up resources. With microservices, each server could be configured to sit behind it's own load balance and scale independently. Each variety of process can always have just enough resources. + +An install that heavily utilizes the jobs queue could see delays in http service because of heavy jobs processes and/or delays in the execution of jobs processes due to increased server load. + +## Deployment Methodologies + +Note that there is no flag to separate the http routes on the webserver. Separating the http server functionalities can be accomplished by the routing of various routes to the correct http server. This can ensure that sensitive areas, such as the `/admin/` route are not available outside the firewall. + +Talk's Queue is backed by Redis, so as long as all Talk instances access the same Redis cluster no additional configuration is needed when launching an independent jobs cluster. + +If there are any features of Talk that you believe should be disable-able via server flags, please let us know and consider contributing it to the project! + +## Deployment Flows/Scripts + +We do not currently support any microservice based deployment flows. If you develop one yourself that is completely based on open source tooling, please consider contributing it to the project! From b235b8334e530eec2cd746ad4e4361eefb748594 Mon Sep 17 00:00:00 2001 From: David Erwin Date: Fri, 14 Jul 2017 16:06:47 -0400 Subject: [PATCH 2/5] Give some context --- docs/install-microservices.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/docs/install-microservices.md b/docs/install-microservices.md index 4100c4cac..c3215f730 100644 --- a/docs/install-microservices.md +++ b/docs/install-microservices.md @@ -6,6 +6,12 @@ permalink: install-microservices.html summary: --- +In Talk, we seek to deliver the simplicity of a monolith with the advantages of a microservice based infrastructure for those who want them. + +To accomplish this, Talk has the ability to run with subsets of its overall functionality and contains architecture that allows them to operate logically as microservices when running in a single environment. + +## Talk Server Functionalities + The Talk server serves several logically/architecturally distinct functions: * A web server that @@ -19,7 +25,9 @@ In the documentation so far, we've discussed how to deploy all of these function ## Separating Talk into Microservices -Talk can be run as three separate clusters of servers: webserver, socket server and jobs server. +Talk can be run as three separate clusters of servers by enabling/disabling different bits of functionality: webserver, socket server and jobs server. + +Each microservice would deploy with the same codebase and configuration. Note that the `cli serve` command, which is responsible for starting the server, contains flags that control whether `jobs` and `websockets` are enabled. From 0069f31244a317ed98efb391ffc53dec028de1f0 Mon Sep 17 00:00:00 2001 From: David Erwin Date: Fri, 14 Jul 2017 16:07:47 -0400 Subject: [PATCH 3/5] Make it accurate --- docs/install-microservices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/install-microservices.md b/docs/install-microservices.md index c3215f730..eb3111c2d 100644 --- a/docs/install-microservices.md +++ b/docs/install-microservices.md @@ -25,7 +25,7 @@ In the documentation so far, we've discussed how to deploy all of these function ## Separating Talk into Microservices -Talk can be run as three separate clusters of servers by enabling/disabling different bits of functionality: webserver, socket server and jobs server. +Talk can be run in two or more separate clusters of servers by enabling/disabling different bits of functionality: webserver, socket server and jobs server. Each microservice would deploy with the same codebase and configuration. From d82735b2b5b308773ffce3e9fc9644fd8afa01fd Mon Sep 17 00:00:00 2001 From: Wyatt Johnson Date: Mon, 17 Jul 2017 10:50:40 -0600 Subject: [PATCH 4/5] Adjusted docs --- docs/install-microservices.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/install-microservices.md b/docs/install-microservices.md index eb3111c2d..668603920 100644 --- a/docs/install-microservices.md +++ b/docs/install-microservices.md @@ -15,8 +15,7 @@ To accomplish this, Talk has the ability to run with subsets of its overall func The Talk server serves several logically/architecturally distinct functions: * A web server that - * serves "public" assets (aka, the comment embed) - * "protected" assets (aka, the admin console) over http(s) + * serves "public" assets (aka, the comment embed) * the GraphQL endpoints * A web socket server that handles subscriptions. * A jobs processor that handles queued operations. @@ -50,9 +49,9 @@ With routing logic in front of the webserver cluster, separation between public Consider a microservice deployment if: -* you want to put access to admin routes behind a firewall * you are running plugins that require intensive job processing * you do not want to simplicity of single cluster horizontal scaling and want to tune the economy and performance of your install. +* You run into scaling issues serving websockets At scale, combining separate concerns in a single process makes it very difficult to understand what is taking up resources. With microservices, each server could be configured to sit behind it's own load balance and scale independently. Each variety of process can always have just enough resources. From d5dfd89d94a9aea2d65c1c975e9a781e9bfcf464 Mon Sep 17 00:00:00 2001 From: Wyatt Johnson Date: Mon, 17 Jul 2017 10:54:54 -0600 Subject: [PATCH 5/5] review of docs --- docs/install-microservices.md | 56 ++++++++++++++++++++++++++--------- 1 file changed, 42 insertions(+), 14 deletions(-) diff --git a/docs/install-microservices.md b/docs/install-microservices.md index 668603920..061640dd9 100644 --- a/docs/install-microservices.md +++ b/docs/install-microservices.md @@ -6,9 +6,12 @@ permalink: install-microservices.html summary: --- -In Talk, we seek to deliver the simplicity of a monolith with the advantages of a microservice based infrastructure for those who want them. +In Talk, we seek to deliver the simplicity of a monolith with the advantages of +a microservice based infrastructure for those who want them. -To accomplish this, Talk has the ability to run with subsets of its overall functionality and contains architecture that allows them to operate logically as microservices when running in a single environment. +To accomplish this, Talk has the ability to run with subsets of its overall +functionality and contains architecture that allows them to operate logically as +microservices when running in a single environment. ## Talk Server Functionalities @@ -20,15 +23,21 @@ The Talk server serves several logically/architecturally distinct functions: * A web socket server that handles subscriptions. * A jobs processor that handles queued operations. -In the documentation so far, we've discussed how to deploy all of these functionalities bundled into a single monolith application. This is convenient as there is minimal configuration and horizontal scaling is as easy as upping the number of servers behind a single load balancer. +In the documentation so far, we've discussed how to deploy all of these +functionalities bundled into a single monolith application. This is convenient +as there is minimal configuration and horizontal scaling is as easy as upping +the number of servers behind a single load balancer. ## Separating Talk into Microservices -Talk can be run in two or more separate clusters of servers by enabling/disabling different bits of functionality: webserver, socket server and jobs server. +Talk can be run in two or more separate clusters of servers by +enabling/disabling different bits of functionality: webserver, socket server and +jobs server. Each microservice would deploy with the same codebase and configuration. -Note that the `cli serve` command, which is responsible for starting the server, contains flags that control whether `jobs` and `websockets` are enabled. +Note that the `cli serve` command, which is responsible for starting the server, +contains flags that control whether `jobs` and `websockets` are enabled. ``` talk :) ]$ bin/cli serve --help @@ -41,30 +50,49 @@ talk :) ]$ bin/cli serve --help ... ``` -Each Talk Microservice cluster can be deployed in an identical manner described in the other docs in this section with the omission of the `-j` and/or `-w` flags. +Each Talk Microservice cluster can be deployed in an identical manner described +in the other docs in this section with the omission of the `-j` and/or `-w` +flags. -With routing logic in front of the webserver cluster, separation between public and protected assets can be achieved. +With routing logic in front of the webserver cluster, separation between public +and protected assets can be achieved. ## When should I consider separating? Consider a microservice deployment if: * you are running plugins that require intensive job processing -* you do not want to simplicity of single cluster horizontal scaling and want to tune the economy and performance of your install. +* you do not want to simplicity of single cluster horizontal scaling and want to + tune the economy and performance of your install. * You run into scaling issues serving websockets -At scale, combining separate concerns in a single process makes it very difficult to understand what is taking up resources. With microservices, each server could be configured to sit behind it's own load balance and scale independently. Each variety of process can always have just enough resources. +At scale, combining separate concerns in a single process makes it very +difficult to understand what is taking up resources. With microservices, each +server could be configured to sit behind it's own load balance and scale +independently. Each variety of process can always have just enough resources. -An install that heavily utilizes the jobs queue could see delays in http service because of heavy jobs processes and/or delays in the execution of jobs processes due to increased server load. +An install that heavily utilizes the jobs queue could see delays in http service +because of heavy jobs processes and/or delays in the execution of jobs processes +due to increased server load as a result of Node's single thread infrustructure. ## Deployment Methodologies -Note that there is no flag to separate the http routes on the webserver. Separating the http server functionalities can be accomplished by the routing of various routes to the correct http server. This can ensure that sensitive areas, such as the `/admin/` route are not available outside the firewall. +Note that there is no flag to separate the http routes on the webserver. +Separating the http server functionalities can be accomplished by the routing of +various routes to the correct http server via an external upstream proxy like +Google Cloud's Load Balancer, AWS's ELB, or a websever like NGINX/Apache. This +can ensure that sensitive areas, such as the `/admin/` route are not available +outside the firewall. -Talk's Queue is backed by Redis, so as long as all Talk instances access the same Redis cluster no additional configuration is needed when launching an independent jobs cluster. +Talk's job processors are synchronized by Redis, so as long as all Talk +instances access the same Redis cluster no additional configuration is needed +when launching an independent jobs cluster. -If there are any features of Talk that you believe should be disable-able via server flags, please let us know and consider contributing it to the project! +If there are any features of Talk that you believe should be disable-able via +server flags, please let us know and consider contributing it to the project! ## Deployment Flows/Scripts -We do not currently support any microservice based deployment flows. If you develop one yourself that is completely based on open source tooling, please consider contributing it to the project! +We do not currently support any microservice based deployment flows. If you +develop one yourself that is completely based on open source tooling, please +consider contributing it to the project!