Frontend developer from Newcastle upon Tyne. Particularly interested in accessibility, UX and frontend. Hobby writer. Environmentalist. Lover of music. Hairline of a 40 year old.
Some good points in this article, no doubt. I like the more abstract concept of intentionally putting your system in less-than-ideal circumstances, observing the outcomes and acting accordingly. It could help to deliver a really robust system.
I do think, though, that this post is very heavily aimed towards people who work in CI/CD or DevOps. As a web developer, there are many chaotic situations that I could intentionally trigger, but would be unable to resolve. Sometimes, the solution lies with a third party or is restricted by technology.
I think we need to take these principles, but keep them flexible and configure them to match a given discipline.
True, this was more from DevOps prospective, however you could/can work along the DevOps (if you don't have own full access dev env) in where you could observe as to what happens if you shut off network , stop access to database, provide wrong username, dependencies on other apps and such.
When I do things like one above, I work with Devs because they help me provide better insights into app and or logs. So that Noc has a notification at least that an app restarted and healed it self by running script xyz that also restarted dependencies..
Thank you for commenting, much appreciated thoughts from different prospective..
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.
Hey there,
Some good points in this article, no doubt. I like the more abstract concept of intentionally putting your system in less-than-ideal circumstances, observing the outcomes and acting accordingly. It could help to deliver a really robust system.
I do think, though, that this post is very heavily aimed towards people who work in CI/CD or DevOps. As a web developer, there are many chaotic situations that I could intentionally trigger, but would be unable to resolve. Sometimes, the solution lies with a third party or is restricted by technology.
I think we need to take these principles, but keep them flexible and configure them to match a given discipline.
All in all - great article 😊
True, this was more from DevOps prospective, however you could/can work along the DevOps (if you don't have own full access dev env) in where you could observe as to what happens if you shut off network , stop access to database, provide wrong username, dependencies on other apps and such.
When I do things like one above, I work with Devs because they help me provide better insights into app and or logs. So that Noc has a notification at least that an app restarted and healed it self by running script xyz that also restarted dependencies..
Thank you for commenting, much appreciated thoughts from different prospective..