>
Like in the past, when we used to store logic inside databases, using triggers and stored procedures. And now we know this kind of architecture can lead to problems related to performance, scale, and vendor lock-in.Many people use these database features quite well & suffer no problems. Doing things has risk. We have to keep interpetting _ deciding what risks, pro's/con's there are.
It's a long read/rant, but I recommend Steve Yegge's Notes from the Mystery Machine Bus, where he talks about the political alignment of engineers into conservative or progressive positions. He's not totally right about his own opinions- turns out static typing has a lot of upsides, or at least, we havent made an IDE that can give us autocomplete as good without it- but the framing, the way of considering how we accept or reject ideas around us is capital.
I see a lot of fear in this post. And it seems like an interesting premise. But I'd need a lot more to go on to start seeing the problem. Autonomic systems have a big risk of going wrong & there being no one in the room who understands, who can dive in & see the operator work: that to me is the chief risk; the de-skilling they enable. Maybe in some ways that mirrors problems stored procedures had. But operators are also capable of having really good observability, of really saying what they're doing and why, and that is the perfect counter, is bringing the light of understanding to the darker systems. Where-as the database has rarely been a good debuggable rich-context world.