Used to do DevOps before they even called it that way: Linux. Python. Perl. Java. Docker. For fun and profit. CTO level generalist working for a mid-sized tech-centric company.
Dresden, Germany
Just the right approach I'd say. Start simple. Don't optimize as long as you don't have to. But start DevOps'ish and be careful to deal with Dickersons Hierarchy of Reliability (david-merrick.com/2017/06/26/dicke...), especially the lower layers (monitoring). Keep eyes open to know how to address scalability issues as soon as they arise but even more keep eyes and ears open to see them when they actually start arising, to be able to figure out bottlenecks, scalability limitations fast. In our experience running a modestly sized system that has seen 15+ years of growth, fixing scalability issues is not trivial but in most cases it's way easier than actually finding scalability limits using good instrumentation. Make sure your application has this baked into from day one.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Just the right approach I'd say. Start simple. Don't optimize as long as you don't have to. But start DevOps'ish and be careful to deal with Dickersons Hierarchy of Reliability (david-merrick.com/2017/06/26/dicke...), especially the lower layers (monitoring). Keep eyes open to know how to address scalability issues as soon as they arise but even more keep eyes and ears open to see them when they actually start arising, to be able to figure out bottlenecks, scalability limitations fast. In our experience running a modestly sized system that has seen 15+ years of growth, fixing scalability issues is not trivial but in most cases it's way easier than actually finding scalability limits using good instrumentation. Make sure your application has this baked into from day one.