HNHacker News
TopNewBestAskShowJobs

jtrtoo

161 karma · joined June 11, 2013

Geek, humanist, avid lifelong learner, technologist, entrepreneur. Into burritos, beer, soccer, coffee. Adventurer in self-employment, tech consulting, high-tech.

Based in California, on the Central Coast.

Blog/Website: https://joshrichards.net

Twitter: @jtr

submissionscomments
jtrtoo··on The Stages of IT Monitoring Maturity: A Framework for Enterprise IT Stakeholders
Author here.

I've put together a write-up of the various stages of IT monitoring maturity most organizations go through. Feedback is always welcome.

WHAT: It includes the various types of monitoring, main coverage points, and typical implementation approaches and protocols involved. I also mention a few of the most commonly overlooked items in each stage.

WHY: I find it useful to understand the various key stages so that I can recognize where an organization is in its level of maturity, as well to introduce some tangible milestones around where the stakeholders want to go.

Perhaps a few of you will find it useful.

Feel free to share/re-post/distribute within your organization. Feel free to comment here, on the post, or drop me a note privately if that's more your thing.

jtrtoo··on Rubygems.org AWS bill for Feb 2014 [pdf]
Is any of this good/bad/right/wrong? I have no idea. That depends quite a bit on what THEY are doing with it and why. For example, it can be cheaper to distribute from CloudFront versus straight from S3 for some use cases. Though, generally, you are not only looking at using CloudFront to save money over S3 ...there's typically a performance reason.

And sometimes the hosting costs simply don't matter. It's easy for us engineers - siting here on HN - to sit at our keyboards and play around with hypothetical ways to save money. This isn't necessarily a bad thing, but there are numerous things in IT that it doesn't make sense to optimize. Why? Because the ROI on the engineering time, CapEx, and OpEx (and the time, energy, and focus of ANYONE involved or impacted at all) to do the optimization doesn't outweigh the opportunity cost.

Sometimes there are simply better uses of our limited capital and time.

Not everything needs to be optimized. And the argument gets stronger when there are other factors more difficult to factor in: adopting a platform that isn't as widely known or isn't backed by a similar level of maturity (even with it's quirks, at least they are well known), etc.

The risks/concerns not only vary between organizations, but often from one period of an organization's growth to the next. The beauty is every organization gets to make their own decision ...and none of them have to give a damn if the HN community agrees or not. :-)

jtrtoo··on Rubygems.org AWS bill for Feb 2014 [pdf]
Since it can take a bit of time to read through the invoice, here's a summary of the bill:

CloudFront $1,071 Data Transfer $3,597 EC2 $2,184 S3 $ 228

While "bandwidth" costs equate to ~$4,668/month, only $1,071 is CDN (CloudFront), with the balance just raw Data Transfer.

Since lots of folks are commenting, and not everyone realizes the difference it's also a good time to point out the CloudFront vs. Data Transfer distinction.

Using Amazon's terms... Data Transfer means anything directly served/coming from EC2 or S3 (or a few other services which aren't relevant here), but NOT anything for CloudFront (which is, obviously, a separate line item, as shown above).

The bulk of CDN (CloudFront) usage ($735 worth or 69%) is US.

The bulk of Data raw bandwidth (Data Transfer) usage ($2,931 ~80%) is US East.

jtrtoo··on Rubygems.org AWS bill for Feb 2014 [pdf]
I presume you mentioned Cloudflare because of their "unlimited bandwidth". That comes with some constraints as to the use/application: https://www.cloudflare.com/terms.html

It's possible RubyGems.org would be classified under one of the "not really allowed here" terms.

← PreviousPage 4 of 4