And you are here why?

/via http://www.commitstrip.com/en/2018/06/22/are-you-any-good-at-it/ I still remember discovering perl back in 1991. I was one of two Unix Guys at Notre Dame back then, and we were responsible for managing a metric ton of SPARCstations, AFS, remote booting, and all sorts of weird-ass s**t that, luckily, most of us just don’t have to worry about anymore. And yeah,  so  much of everything was run using a cobbled together collection of  csh  ( bash wasn’t huge back then). Perl was a godsend, simplifying  so  much of the nasty text processing that was intrinsic to the sysadmin stuff we used to do back then. Mind you, most of this was because it beat the pants off of  csh , and that was good enough for us! Years went by, and perl just became a core part of my toolkit — to the point that we pretty much ran a telco for over 10 years with most of the management/automation (what we’d call DevOps these days!) done in perl,  and it worked . Infrastructure tooling is  so  much bette

/via https://bit.ly/2KjRUCw Remember  Polar Express ? For those who don’t (lucky you!), it was  the  ChristmasKidFlick™ for 2004, one supposed to impart the Xmas spirit, good cheer, Santa Claus, and all that. Instead, it ended up becoming the living (!) embodiment of the  Uncanny Valley , filled with dead-eyed CGI zombie kids, and was — there is no other word for it —  creepy . The thing is, humans tend to be  very  good at identifying and classifying behaviors in others, especially base don facial expressions. That little twitch in your beloved’s lip means that they found your behavior adorable, the almost invisible wrinkle by the left eye — you goofed up real bad. And when the behavior displayed doesn’t match what we expect it to look like (“ huh? why did the eye twitch like  that ? ”), it’s like there is a blaring siren saying “ THIS IS ODD WHY IS IT THIS WAY I DON’T GET IT ”. In short,  humanoid objects which appear almost, but not exactly, like real human beings elicit u

I know, this is kinda ridiculous. Just for argument’s sake though, let’s pretend that you’ve got your act down — you built your product it’s actually selling, and you’ve got $$$. You’ve achieved that elusive  Product/Market Fit , where the thing you’re building is the thing that people want, and are willing to pay for. Product/Market Fit Evolves The issue with having achieved Product/Market Fit is that things change. People might be willing to pay for your widget today, but will that be true  tomorrow ? After all, • Competition  might bring other players into the market, who could sell the same thing for less. After all, they’ve already seen what works, don’t need to recoup R&D like you did, etc. • Customer needs evolve , heck, you might be the one that’s causing them to ask for more! Are you prepared to satisfy those needs? There are other reasons why what works today might not work tomorrow (market gets tapped out, regulatory changes, etc.). The point here being tha

In todays episode of “ Lets Talk About Stuff You Already Know ” we cover  Loose-Coupling . The  baseline definition  is kinda obvious — it’s a system is which each component has limited knowledge (and use!) of the other components. That said, if that was the extent of it, I would just have linked to  the Wiki page , and have been done with it. The thing is,  semantics are important , and what the term means to me is not necessarily what it means to somebody else. Given that the most costly software issues tend to be the ones made earliest, it behooves you to limit misunderstandings in the  Design  stage! Consider a simplified take on the development cycle, viz.  Design → Develop → Test → Deploy . With a loosely-couple system, you can • Design  your component with limited involvement from other components. Whats more, you can update this design without  other  folks having to change  their  stuff. • Develop  your component without much co-ordination with others, e.g., very few

If you’re using  Prometheus at scale ,  you’ve probably run into one or more of the following issues 1. Data retention  costs money, the more historical data you keep, the more SSD you need, and that gets expensive. 2. You scale prometheus by sharding, and the ensuing contortions you go through to get a unified view involves all sorts of madness with federation, grafana queries, and whatnot. 3. An HA setup inevitably runs into the entertainment associated with de-duplicating prometheus data. 4. If you run into more than one of the above, then whatever you do ends up being somewhat Rube-Goldberg-ish, with associated maintenance headaches, replicability, inefficiency, etc. Enter  Thanos , which integrates transparently with Prometheus, and pretty much takes care of all of the above issues, and remarkably elegantly at that. It consists of a bunch of modular components that can be snapped together to — transparently! — provide a unified view across your existing Prometheus setup,