Link: THE EMERGING THREE-TIER PRICING MODEL FOR PRIVATE CLOUD

Private clouds owned and self-managed by enterprises can be cheaper than public cloud. The magic number to beat is about $25 per VM-month at 100% utilization. If the cost of the whole stack comes in under this number, then even with the addition of labor to manage that private cloud, it should be cheaper than public cloud. Obviously, with better labor efficiency, unit costs versus public cloud are lowered further, and the relative value of benefits increases. Enterprises unable to achieve a labor efficiency of 300 VMs per engineer are unlikely to beat public cloud on price.
Original source: THE EMERGING THREE-TIER PRICING MODEL FOR PRIVATE CLOUD

Link: SRE: The Biggest Lie Since Kanban

That’s why SRE is a Big Lie – because it enables people to say they’re doing a thing that could help their organization succeed, and their dev and ops engineers to have a better career and life while doing so – but not really do it. Yes, there have been Big Lies before, which is why I cite Kanban as another example – but even if the new criminal is pretty much like the old criminal, you still put their picture up on the post office wall.

If something you’re selling is profoundly misused it’s your responsibility to be more up front about the issues.
Original source: SRE: The Biggest Lie Since Kanban

Link: Defense Innovation Board proposes new metrics for assessing DOD software development

“The metrics can be broken down into four broad categories — deployment rate metrics, response rate metrics, code quality metrics, and program management, assessment, and estimation metrics.  The DIB also provides general timeframes for what a “good” score looks like for each metric.”
Original source: Defense Innovation Board proposes new metrics for assessing DOD software development

Link: “Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s cal

“Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s called a Chef server. Similarly, ITIL places a strong emphasis on configuration. Teams I have built do the same. All changes to the system are made in code, go through a peer review process, are automatically tested, and rolled out in a recordable, repeatable, and auditable manner. I encourage tracking of all changes that are made to the system. To do that, I use git and I track problems and resolution in a ticketing system. That could be Jira or Zendesk. When it comes to risk management, compliance, and security, again, I turn to the Chef ecosystem. Chef Compliance, as part of the Chef automation system, provides ways to specify compliance requirements as testable specification, which can then be used for audit and management.”

All that configuration management, logging, and automation gives what’s needed for ITIL-level tracking.
Original source: “Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s cal

Link: How to Monitor the SRE Golden Signals

[Summary from the post of metrics to use:]

Rate — Request rate, in requests/sec
Errors — Error rate, in errors/sec
Latency — Response time, including queue/wait time, in milliseconds.
Saturation — How overloaded something is, which is related to utilization but more directly measured by things like queue depth (or sometimes concurrency). As a queue measurement, this becomes non-zero when you are saturated, often not much before. Usually a counter.
Utilization — How busy the resource or system is. Usually expressed 0–100% and most useful for predictions (as Saturation is probably more useful). Note we are not using the Utilization Law to get this (~Rate x Service Time / Workers), but instead looking for more familiar direct measurements.
Original source: How to Monitor the SRE Golden Signals