Operations | Monitoring | ITSM | DevOps | Cloud

The DevOps model unites development and IT operations to create a powerful organizational culture to achieve business goals more efficiently. Formerly siloed teams can now collaborate continuously to build more robust products, with increased confidence, and achieve business goals faster. The model has the power to transform operations, but there are barriers to DevOps that must be overcome first.

I believe that the evolution to hybrid cloud is inevitable. Not because it’s grabbing headlines, but because it mirrors the industry’s history of new technology adoption. Take the evolution of virtualization, for example. Going back 20 years give or take, virtual machines popularized by VMware, KVM, and Hyper-V started to gain traction.

Picture yourself flying first class. You board the plane first, you get champagne, and you feel as though you’re the most important. Why not treat your APIs the same way? In this talk, FireHydrant CEO and Co-Founder, Robert Ross (a.k.a @bobbytables) shares why putting your APIs first can be a game-changer for your business and how this mindset shaped the way FireHydrant was built.

To many businesses, the pace of innovation and speed to market has been hindered by the legacy infrastructure. This is mainly due to the closed structures and inflexible old-school architectural formats that they follow. The decades-old infrastructure hesitates to scale up with the growing business demands and realize advanced cloud-based technologies.

The widespread adoption of Agile methodologies in recent years has allowed organizations to significantly increase their ability to push out more high quality software. Previous development practices revolved heavily around centralized applications and infrequent updates that were shipped maybe once a quarter or even once a year.

What precisely are the requirements of a DevOps practitioner, as opposed to an SRE, legacy developer, or operations manager? And do those specific requirements require a different approach to monitoring?

Mean time to repair (MTTR) is an essential metric that represents the average time it takes to repair and restore a component or system to functionality. It is a primary measurement of the maintainability of an organization’s systems, equipment, applications and infrastructure, as well as its efficiency in fixing that equipment when an IT incident occurs. Key challenges with MTTR arise from just trying to figure out that there is actually a problem.

As an on-call engineer, you might deal with the day-in, day-out occurrence of alerts. These alerts may come from your alerting provider (PagerDuty, OpsGenie, etc.), Slack notifications telling you the site is down, or the ever concerning text message "Hey, is the site down?". These alerts elicit reactions that range from "shit" to "again?" and in many cases, both.

Today, almost every application stack would usually consist of a number of different applications, each performing a specific role and working together towards a common goal. This is the case whether it be that of a fortune 500 company or a computer science student trying to complete a tech project. As such, the stability and reliability of your infrastructure would greatly depend on the performance of each application within that infrastructure.