News for hackers. Stuff that matters.

A comment on Imperative configs are out; Declarative configs are in. Parent comment

Re:Imperative configs are out; Declarative configs are in by taeric on Wednesday November 09, 2022 @05:43PM (#33539160)
Not when your infrastructure includes your data store, though. Or if it includes such things as your application endpoint. You may want to stand up the new endpoints and then drain over traffic, as an example. Not take an outage for a deployment.
[ Parent | on HN ]
Re:Imperative configs are out; Declarative configs are in by tremon on Wednesday November 09, 2022 @07:18PM (#33540299)
Not when your infrastructure includes your data store, though

Then the service is no longer stateless.

[ Parent | on HN ]
Re:Imperative configs are out; Declarative configs are in by taeric on Wednesday November 09, 2022 @07:55PM (#33540668)
I mean, you aren't wrong. But I am challenged to think of a service that doesn't store state somewhere.

And you ignore the other situation. Even a fully "stateless" service that literally just responds to things probably doesn't want an outage just to deploy a new version.

[ Parent | on HN ]
Re:Imperative configs are out; Declarative configs are in by tremon on Thursday November 10, 2022 @04:38AM (#33544214)
That's true. The way we solve it is by splitting our infrastructure deployments in two parts: a volatile part and a persistent part; it gives us more confidence when deploying the stateless part, but sadly it also means that the persistent deployments don't get as much exercise as the stateless part and are somewhat more prone to bitrot.
[ Parent | on HN ]
Re:Imperative configs are out; Declarative configs are in by scubbo on Thursday November 10, 2022 @07:09PM (#33555581)
Right, yes - sorry, I should have clarified that I didn't mean "tear down then set up", but rather "set up (new), cut over, then tear down (old)". But still - the service should be "created from scratch"!
[ Parent | on HN ]