Operations | Monitoring | ITSM | DevOps | Cloud

Back in the day, monitoring applications from end to end was—for the most part—significantly easier than it is today. Though the basics of instrumentation and observability for metrics like CPU, memory, and I/O throughput haven’t changed, the way applications are built has changed significantly. There were, at most, a handful of application servers and likely a single database server.

In the early days of the pandemic and in 2021, teams were on their heels reacting to everything thrown their way: changes in work dynamics, accelerated digital transformation, and new support procedures and expectations. Providing exceptional support isn’t only about quick response and incident resolution; much of it boils down to processes behind the scenes that keep you proactive. Enter: problem and change management.

Before you can answer this question, I like to step back and take a good look at the history of computing. Mainframes and legacy client-server applications were monolithic—all the processing took place on a single set of hardware. As hardware grew cheaper, and especially after widespread hardware virtualization came to fruition, these trends gave way to the widespread development of distributed systems. I began to see this trend during my time as an architect at a large cable and telecom provider.

Automation is often portrayed as a scary thing. Whether it’s artificially intelligent robots conquering the planet or a world where no one can find work because automatons have taken everyone’s jobs, movies and entertainment often paint automation with a horror brush. But IT pros know this isn’t the reality. They know automation is a tool capable of making their lives easier and helping their organizations run smoothly. Still, many IT pros fear automation for legitimate reasons.

One of the most fundamental concepts in any relational database management system (RDBMS), such as SQL Server, is the transaction. During my consulting career, I've seen many performance problems caused by developers not understanding how transactions work in SQL Server. In this tutorial, I'll explain what transactions are, why they're necessary, and how they work in SQL Server.

The term DevOps has taken the IT world by storm. Though every business incorporates DevOps practices differently—and even defines the term differently—doing so can offer businesses several benefits. In this article, we’ll talk about the advantages DevOps practices offer, the different parts of the organization they can help, and the future of DevOps.

Government IT administrators manage several different types of operations. There’s DevOps, which led to the creation of DevSecOps. Now, data-driven agencies are being introduced to a new operational concept: DataOps, the bridge connecting IT operations and data sciences and accelerating the use of data analytics.

Data is the lifeblood of businesses, and protecting it is incredibly important. One of the ways DBAs help ensure the continuous availability of data is through database backups, a process involving copying the data and schema from a database and saving them elsewhere for retrieval later. But like any other process in IT, database backups have costs, benefits, and risks associated with them.

How do you know your SQL Server system is running well? Is it the simple method of noting no one is complaining? (Sadly, in many businesses, this is exactly how it's done.) The fact is, if you're not monitoring SQL Server performance, you don't know.

Recently, I wrote an article titled Life Cycle Monitoring: Why an Ounce of Prevention Is Worth a Pound of a Cure. The great Benjamin Franklin coined the term. In the article, I highlighted the value, efficiency, and logic of putting more time into a proper capacity planning and optimization process for all types of IT environments. Most IT professionals would tell you the first thing that comes to their mind when asked how they use log management tools is troubleshooting.