Pinterest is talking about deploying code. Meanwhile, the rest of the world is moving toward deploying containers.
Open-sourcing Teletraan, a code deployment system
11–17 of 17 posts
Re: Open-sourcing Teletraan, a code deployment system
#12What does a "host" mean in context of deployment with this tool? Does it mean that you spin up instances and then deploy over and over on the same set?
Re: Open-sourcing Teletraan, a code deployment system
#13Run Deploy Agents on each host through your provisioning process
If that's the requirement, a serious question might be: why not just deploy code through your provisioning process?
My personal impression is that the key issue with most systems in this area is that they whitewash, ignore or blur the reality that network topology, security, service codependencies, data security, build and deployment pipelines and so forth need to be managed at some level, may not be the same across all infrastructure, and requirements in these spaces can frequently be nontrivial with competing concerns. Thus, individual solutions typically only function for a subset of cases while ignoring the fact that others exist.
A clear description of the limitations of the approach of the tool would be useful.
Corosync/pacemaker is one mature solution in this area with a focus on HA and the capacity to navigate logical topology changes (due to faults, errors, etc.) in real time to resolve service interdependencies towards a defined 'goal state'. Extremely powerful, with a huge library of 'OCF resource agents' (service definitions) already written.[0] However, it also uses the 'agent on each machine' architecture. Where a small number of services are deployed at large scale in a parallel configuration I believe an agentless configuration methodology with PXE and IPMI power control is a more efficient node management path, though it obviously negatively impacts HA.
PS. 'Features' like rollback and 'hotfix' are arguably negligible if you have a reasonable service build process incorporating versioning.
Re: Open-sourcing Teletraan, a code deployment system
#14What does a "host" mean in context of deployment with this tool? Does it mean that you spin up instances and then deploy over and over on the same set?
Someone like AWS has a minimum amount of time they bill for an instance for. It's usually 1 hour. If Pinterest is deploying 500 times a day, the cost of spinning up all new instances every single time would be pretty excessive. A lot of companies have a fixed set of app servers that stay up most of the time, then another set of dynamic ones that spin up and down with traffic.
So yes, it probably does mean that they are deploying more than once to the same set of servers.
Re: Open-sourcing Teletraan, a code deployment system
#15Pinterest is talking about deploying code. Meanwhile, the rest of the world is moving toward deploying containers.
"There is no silver bullet". - Fred Brooks
Re: Open-sourcing Teletraan, a code deployment system
#16Run Deploy Agents on each host through your provisioning process If that's the requirement, a serious question might be: why not just deploy code through your provisioning process? My personal impression is that the key issue with most systems in this area is that they whitewash, ignore or blur the reality that network topology, security, service codependencies, data security, build and deployment pipelines and so fo…
> why not just deploy code through your provisioning process?
Because provisioning operates with a much larger timescale, with a different fundamental understanding of the act of manipulating remote state. In a word, it's too slow.
In fact it seems to me that this tool is itself still too slow, like a half-step between Chef/Puppet/Ansible (system provisioning) and Kubernetes (application scaling). The future is clearly in the commodification of hardware and network, i.e. immutable infrastructure and cattle-not-pets.
Re: Open-sourcing Teletraan, a code deployment system
#17Run Deploy Agents on each host through your provisioning process If that's the requirement, a serious question might be: why not just deploy code through your provisioning process? My personal impression is that the key issue with most systems in this area is that they whitewash, ignore or blur the reality that network topology, security, service codependencies, data security, build and deployment pipelines and so fo…
> why not just deploy code through your provisioning process? Because provisioning operates with a much larger timescale, with a different fundamental understanding of the act of manipulating remote state. In a word, it's too slow. In fact it seems to me that this tool is itself still too slow, like a half-step between Chef/Puppet/Ansible (system provisioning) and Kubernetes (application scaling). The future is clear…
> In a word, it's too slow.
{{citation-needed}}
PXE boot is a few seconds... restores perfectly known state at all layers of the stack and thus has lots of guarantees.