Author: Mustufa Batterywala
How to keep tabs on multi-cloud ROI
The cloud’s business benefits such as faster time-to-market, better service quality as compared to traditional IT setups, and a lower Total Cost of Ownership (TCO) are well established, which has led to its pervasiveness. Most organizations have migrated to cloud services providers like Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and Alibaba Cloud seeking flexible payments, scalability, elasticity, resilience, and more. Cloud’s adoption is also driven by the fact that it provides a flexible and agile platform for innovation and growth. However, even as organizations adopt cloud for building cloud-native applications, they are at the risk of losing sight of cloud ROI.
Optimizing and managing cloud-based resources has become highly complex over the years. The race to the bottom among cloud service providers is long over; it means that it’s up to their customers to find ways to better optimize their cloud costs and increase operational efficiencies. However, they often struggle to reduce the cloud sprawl and manage cloud-native applications. That is why hybrid and multi-cloud setups are now seen as a solution to such challenges. According to RightScale, every major organization is using around five clouds and 81% of the enterprises have a multi-cloud strategy.
Top 5 compliance challenges in DevOps
One of the primary goals of DevOps is to improve speed and reliability with a higher cross-functional collaboration and to make security, quality, and feedback parts of the pipeline. With automation and shift left approaches, most organizations have varying levels of success in meeting this goal. However, compliance controls and audit activities still involve a lot of manual workflows, which makes them inefficient and error-prone. In this article, we will explore the major challenges and possible solutions for implementing continuous compliance in DevOps.
Transforming IT operations with site reliability engineering
Observability – Here’s all you need to know
DORA Metrics – Dos & Don’ts for achieving engineering excellence
Peter Drucker’s famous quote, “If you can’t measure it, you can’t manage it,” provides clear guidance to any organization seeking improvements in its processes. Today, every software development organization seeking higher agility, efficiency, stability, and reliability in its operations measures a wide range of metrics. The metrics hold valuable insights for improving the health and performance of software development practices. However, many times tracking the developer productivity metrics can cause undesired results. For instance, tracking the lines of code often leads to a dramatic fall in the quality of the code. Similarly, tracking the number of bug fixes can force quality testing teams to log every minor and trivial bug, affecting the shipping of code. At the same time, organizations also realize that not all metrics are created equal, and some can also mislead or provide a false sense of comfort.
DORA’s (DevOps Research and Assessment) research program recognized these problems. It came up with its set of metrics that are now considered the holy grail for measuring the success of software development. Each year, DORA surveys thousands of organizations and rates their performance on these four key metrics, viz. deployment frequency, mean lead time for changes, change failure rate, and mean time to restore. The survey reports provide a sense of DevOps trends across the globe and help teams compare themselves to their peers, identify areas for improvement, and take steps to become elite performers.
While the metrics are beneficial and can help teams achieve continuous improvements, it is possible to misuse DORA metrics inadvertently. The most common challenge with metrics is that they are often misunderstood and end up becoming the goal, which is an anti-pattern.