4 ms·
In my book, the biggest difference between a sysop/devops guy, and an application developer is a broad scope vs a deep scope. So, as a developer with an applic
by tetha 8y ago
In my book, the biggest difference between a sysop/devops guy, and an application developer is a broad scope vs a deep scope.
So, as a developer with an application with a simple internal security model, yeah. There's going to be a couple of guidelines, and those will setup a pretty hard surface for that application. For our internal application, well. That security model is hell - I don't understand it and try to avoid it. And we got some picky enterprise customers, that's where the simple guidelines don't work anymore. :)
On the operations side, you can impact each application less, but you have so much more stuff to individually deal with in a quantitative sense. For our SaaS clusters we have to secure 15 - 20 different applications. And for a lot of these applications, we're the one and only line of security - you just have to operate a mysql/postgresql database properly, these systems are pretty secure on their own.
And that's just data security. How many developers do think about backups or disaster recovery for all of this mess. Not saying this is bad - this isn't a job for developers, because it's a lot of work. It's mostly a point against the notion of NoOps.
- vajrabum 8y agoJust remember that NoOps isn't actually no operations. That's the cargo cult version of NoOps. Instead it's outsourcing operations and relying that the outsource vendors operations team will do a better and more accountable job than any internal team you could build. So, a database service instead of a locally managed database and a reliance on the service vendor to back things up, keep the code up to date and manage reliability. That's not a bad choice but you still want someone with the judgement to evaluate vendor claims, performance, exceptions and the like.