# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 8
# self = https://watcher.sour.is/conv/il3jmaa
@cncf Hello Kevin! π (_email inbound since I can't comment_) Very interesting read, thank you for taking the time to write this up and its a very nice perspective and story!\n\nRegarding the motivations behind the move from Swarm to Kubernetes:\n\n> In addition to the patchwork tooling, we were quickly reaching a point where we will likely need to scale out our critical infrastructure components such as Redis and RabbitMQ and while Swarm is great for scaling stateless applications, itβs less than ideal for managed stateful applications. With the introduction of Operators
@cncf Hello Kevin! π (_email inbound since I can't comment_) Very interesting read, thank you for taking the time to write this up and its a very nice perspective and story!
Regarding the motivations behind the move from Swarm to Kubernetes:
> In addition to the patchwork tooling, we were quickly reaching a point where we will likely need to scale out our critical infrastructure components such as Redis and RabbitMQ and while Swarm is great for scaling stateless applications, itβs less than ideal for managed stateful applications. With the introduction of Operators
@cncf Hello Kevin! π (_email inbound since I can't comment_) Very interesting read, thank you for taking the time to write this up and its a very nice perspective and story!\n\nRegarding the motivations behind the move from Swarm to Kubernetes:\n\n> In addition to the patchwork tooling, we were quickly reaching a point where we will likely need to scale out our critical infrastructure components such as Redis and RabbitMQ and while Swarm is great for scaling stateless applications, itβs less than ideal for managed stateful applications. With the introduction of Operators
@cncf Hello Kevin! π (_email inbound since I can't comment_) Very interesting read, thank you for taking the time to write this up and its a very nice perspective and story!
Regarding the motivations behind the move from Swarm to Kubernetes:
> In addition to the patchwork tooling, we were quickly reaching a point where we will likely need to scale out our critical infrastructure components such as Redis and RabbitMQ and while Swarm is great for scaling stateless applications, itβs less than ideal for managed stateful applications. With the introduction of Operators
@cncf Its a shame to that we (_and by we I mean the Docker Swarm community, or whatever is left of it_) never really figured out how to do stateful services properly. The most frustrating aspect of Docker Swarm I've found is managing stateful workloads and having good storage volume drivers. There are many that were implemented but either a) simply don't work or b) are incomplete, buggy or broken.\n\nNice write up! cheers π€ (_btw I still run several production Swarm clusters even today!_)
@cncf Its a shame to that we (_and by we I mean the Docker Swarm community, or whatever is left of it_) never really figured out how to do stateful services properly. The most frustrating aspect of Docker Swarm I've found is managing stateful workloads and having good storage volume drivers. There are many that were implemented but either a) simply don't work or b) are incomplete, buggy or broken.
Nice write up! cheers π€ (_btw I still run several production Swarm clusters even today!_)
@cncf Its a shame to that we (_and by we I mean the Docker Swarm community, or whatever is left of it_) never really figured out how to do stateful services properly. The most frustrating aspect of Docker Swarm I've found is managing stateful workloads and having good storage volume drivers. There are many that were implemented but either a) simply don't work or b) are incomplete, buggy or broken.
Nice write up! cheers π€ (_btw I still run several production Swarm clusters even today!_)
@cncf Its a shame to that we (_and by we I mean the Docker Swarm community, or whatever is left of it_) never really figured out how to do stateful services properly. The most frustrating aspect of Docker Swarm I've found is managing stateful workloads and having good storage volume drivers. There are many that were implemented but either a) simply don't work or b) are incomplete, buggy or broken.\n\nNice write up! cheers π€ (_btw I still run several production Swarm clusters even today!_)