IT's a MAAD World

This post originally appeared on SolarWinds Content HUB.

All around me are familiar faces

Worn out places, worn out faces

Bright and early for the daily races

Going nowhere, going nowhere...

And I find it kind of funny

I find it kind of sad

The dreams in which I'm dying are the best I've ever had

I find it hard to tell you,

I find it hard to take

When people run in circles it's a very, very

Mad world, mad world


AWS re:Invent 2015 reminds me of the lyrics from Roland Orzabal’s Mad World. The first verse is represented by traditional Enterprise IT as it struggles to transform and enable continuous service delivery and continuous service integration. The second verse encompasses the conversation that IT operations is having with itself to remove the tech inertia and adopt the DevOps culture as well as the conversation it is having with developers as IT professionals try to learn and live agile and lean.


The disruption from highly available, easy-to-use and easy-to-scale cloud services is making IT organizations run in circles to change itself all the while trying to harness that change into business value. It’s like IT is becoming a mad world; but it doesn’t have to be, as long your maad and not literally mad. Whether you are an IT professional, a DevOps engineer, or an application developer—you can never be MAAD enough in this mad world, this age of instant-applications. And by MAAD, I mean monitoring as a discipline.


So why leverage monitoring as a discipline in the age of instant-apps? Solarwinds Developer Evangelist, Dave Josephsen, said it best in his IT Briefcase article“Teams with the know-how to embrace metrics-driven development and scale their monitoring into their codebase, will spend less time mired…and more time building and running world-class systems that scale.” But not so fast you say, because you’re in IT ops and not a developer. Okay, no problem. As my friend and fellow SolarWinds Head Geek, Thomas LaRock, so eloquently puts it, you need to learn to pivot. And when you do, embrace the discipline that you’ve already matured your career with—monitoring.


Monitoring is the ideal discipline to bridge the gap from your premises to your clouds at your scale. I think of monitoring as a set of eight skills:

  1. Discovery – show me what’s going on.
  2. Alerting – tell me when something broke or is going bad.
  3. Remediation – fix the problem.
  4. Troubleshooting – find the root-cause.
  5. Security – govern and control the data, app, and stack planes.
  6. Optimization – run more efficiently and effectively.
  7. Automation – scale it.
  8. Reporting – show and tell to the management teams/business units.

The first four skills (DART framework) are covered in detail in a SolarWinds eBook that focused on virtualization. The last four skills will be covered in another SolarWinds eBook later this year or early next year. These skills apply to any IT professional, especially one looking to enable hybrid IT service models. Below is a figure of the DART framework:

dart.png

Traditional IT organizations are embracing transformation, as evident by AWS’s continued simplification of cloud services for Enterprises to consume. Many organizations still face resistance internally to change and the rate of change associated with continuous delivery and continuous integration. At the same time, the disdain for IT professionals from the DevOps purist at THE cloud conference is still palatable. Some of it may be deserved for the years of IT roadblocks in the guise of rigor and discipline. Whatever the case, continuous service delivery and continuous service integration are the new realities for Enterprise IT. Dev is the new black.


So IT professionals, take ownership of your premises, your clouds, and your scale with monitoring as a discipline. It’s definitely not all quiet on the cloudy fronts. The storms of continuous change are brewing and IT professionals need to stay ahead of the game. If you’re in the calm, the storm is already upon your organization and disruption is about to be forced upon you.


I’ll end with words from a highly distinguished monitoring engineer who’s always on the leading edge of tech, Adrian Cockcroft. Adrian says that the CIO (and in turn their IT professionals) has three key goals:

  1. Align IT with the business
  2. Develop products faster
  3. Try not to get breached


That all three goals can be achieved with monitoring as a discipline is just utter maad-ness!

Parents
  • Excellent !!

    You inclusion of this line was spot on:

    So why leverage monitoring as a discipline in the age of instant-apps? Solarwinds Developer Evangelist, Dave Josephsen, said it best in his IT Briefcase article“Teams with the know-how to embrace metrics-driven development and scale their monitoring into their codebase, will spend less time mired…and more time building and running world-class systems that scale.”



    I  have been working for a couple of years to get the developers to code in logging to application specific log files or a service specific windows application log for several reasons.

    1) it gives a common location to get business specific application or service log data on every server (common look and feel as well as consistency)

    2) it allows for a unified message structure so we have fewer rules to have to build and maintain so it becomes scalable and managable across hundreds or thousands of servers.

    3) it decreases time to implementation and cycles to actually monitor services.

    4) allows for specific logging of specific issues so you have less noise and the data needed to decrease time to resolution.

Comment
  • Excellent !!

    You inclusion of this line was spot on:

    So why leverage monitoring as a discipline in the age of instant-apps? Solarwinds Developer Evangelist, Dave Josephsen, said it best in his IT Briefcase article“Teams with the know-how to embrace metrics-driven development and scale their monitoring into their codebase, will spend less time mired…and more time building and running world-class systems that scale.”



    I  have been working for a couple of years to get the developers to code in logging to application specific log files or a service specific windows application log for several reasons.

    1) it gives a common location to get business specific application or service log data on every server (common look and feel as well as consistency)

    2) it allows for a unified message structure so we have fewer rules to have to build and maintain so it becomes scalable and managable across hundreds or thousands of servers.

    3) it decreases time to implementation and cycles to actually monitor services.

    4) allows for specific logging of specific issues so you have less noise and the data needed to decrease time to resolution.

Children
No Data
Thwack - Symbolize TM, R, and C