3 ms·
> We can mandate that customers can't futz with our image. Our software becomes an appliance that plugs into their network. One of the overlooked benefits of t
by bonesss 8y ago
> We can mandate that customers can't futz with our image. Our software becomes an appliance that plugs into their network.
One of the overlooked benefits of this approach is how technically aggressive it lets you be when deploying components into strange environments... More and more we're getting tools from our suppliers based on containers that use databases, proxies, heavy server tools, and such. We fire up in seconds tools that could never viably be installed in our environment and that we have 0 competence with.
Long running databases in containers is something you need to think about, but guaranteed known states for supplier-side configuration frees them up to be daring, and firing up local DBs for config data with no outgoing ports lets me not care about how other engineers see the world.
- zamalek 8y ago> databases in containers is something you need to think about I think in a few cases it makes sense to move problems out of containers. A good amount of our customers would likely tell us what to do if we asked them to not worry about the SQL database in a container - they have their backup policies and so forth. This will change over time, but I'm pretty sure that there will always be scenarios where a VM or even metal is required.