Did you ever read the book “Who moved my cheese?” It was a 5-year New York Times Bestseller by Dr. Spencer Johnson.
The book speaks of how people react to change and offers several approaches to coping with change. The author, very eloquently, identifies the challenges of reacting and adapting to various changes in our lives.
In the book, Dr. Johnson helps us to understand that as we mature, we come to realize that change is constant: people change, schedules change, jobs change, friends change, and more. We are, for the most part, able to intellectually and emotionally cope and continue moving forward.
I can’t say that much about software. When something changes in software behavior, it will usually not have the capacity to cope and overcome, but remain in a fragile state until there is some human intervention.
Change Can Hurt Application Performance
Organizations have realized that apps make their business grow, and changing or improving apps is an inherent part of business growth. Yet with change, apps must still run and perform. In many cases the discussion of “what is the main reason for performance degradation or outages?” in various blogs and forums gets responses like “bad coding” or “resource allocation” or “NW configuration.” These are all good answers, but the reality is that 80% of production application performance hits is due to change. Someone touched something in the system:
- Pushed a bad piece of code
- Changed a NW port
- Changed a configuration file
- Updated middleware
One of my professors at university told me once: Software does exactly what a human told it to, it does not have a mind of its own. So, if it breaks, we are the ones who caused it.
The Past was about Preventing Change
Back in the late 90’s (actually around the time “Who Moved My Cheese” came out), I was working for a cellular carrier as an admin in the NW Operations Center. Our operating mantra was “If it works, don’t touch it. If you touch it, it will break.” This summarizes how we viewed the impact of ANY type of change. For Operation teams, change is bad. Change means things break. And any IT professional worth their salt dreads that two-phased period of panic to find and fix actual problem and then to find out whose fault it was, and of course the inevitable lack of sleep associated with a major outage. So, these same IT professionals developed a healthy aversion to change—they simply avoid change as much as possible.
Over time, this approach has proven to not be sustainable. Today’s businesses need to change in order to keep up with demand and growth and remain competitive. An early solutions came in the form of Information Technology Infrastructure Library, more commonly called ITIL. ITIL attempts to solve “change management” by putting a strict process in place with draconic rules of what may be changed and when. Every little event needed to be captured and approved, from server restart to ERP upgrade. Change approval boards are set and each request is put under a microscope. Talk about discouraging change.
The Future Brings a Greater Need for Change
Recent years have brought in a greater need for change. Innovation is everywhere, and companies realize software is where they can differentiate and grow. These companies have changed their development life cycle from waterfall to agile and scrum to deliver faster innovation. Now, changes are rolled through daily pushes instead of being rolled out on a bi-weekly or monthly basis.
Applications are also getting more complex, and the number of changes needed to sustain a complex application is rising. At the same time, the business is demanding more and more features in order to maintain a competitive edge, which translates to more and more changes. The outcome is that a constant rate of change is now a standard requirement for modern applications and any ITIL-like approach that slows down the process simply isn’t allowable any more.
How Can We Enable Change?
IT Operations and Application teams now need to embrace change and the velocity at which change happens. Someone is indeed moving the cheese very often because it is a necessity to survive and grow. When looking at your application deployment and performance monitoring solutions you, need to assess:
- How will your application management tool support you in enabling change?
- Can your application management solution actually support you in accelerating change?
As we developed the vFabric Application Management suite, vFabric Application Performance Manager (APM) and vFabric Application Director, the concept of “ongoing application changes” was a core tenant to our strategy. We realized apps would keep moving at greater speeds than ever before. So, we built tools that help customers answer these needs using the following five requirements:
- Simplify how changes are applied to applications. When change is necessary, the application should make every effort to create repeatable processes to apply the change. This includes creating reusable application blueprints for provisioning applications with Application Director, empowering application teams to deploy on their own while satisfying IT’s needs to enforce standards and policies, integrating with continuous build systems, and delivering powerful visualizations that make it easy to execute and communicate changes.
- Streamline how IT keeps up with change. Building the intelligence into our management tools so they automatically keep up with change, and minimize human involvement helps to ensure applications stay under management. It also speeds mean-time-to-resolution (MTTR) because all changes are tracked for easy root cause analysis when necessary. For monitoring tools like APM and Hyperic, this takes auto-discovery past just identifying new software that comes online and incorporates tracking if the component moved, powered off, or if additional components of that type came online that your application is using to scale up.
- Accelerate how quickly we understand how any change impacts performance. It is important for today’s monitoring tools to have the intelligence built in to automatically know what is normal. APM creates baselines and knows how the application performs under load and at the various times of day so it can accurately report when performance is not normal. Further, once it registers as not normal, all the information on transaction, code, and middleware infrastructure performance is correlated so users can easily identify the change that started the performance problem.
- Make it easy to understand how users are experiencing application performance. It is an important mindshift to look at performance in an application-centric manner. Many applications are built to be horizontally scalable, so if a single component starts to degrade, it may not severely affect application performance. APM triangulates real-time samples of transaction times, application middleware and infrastructure monitoring metrics and code performance together to give application owners the right perspective on real user experience.
- Ensure it is open and extensible to encourage, not hinder, innovative applications. We do not anticipate innovation and change to slow down. And we definitely do not want to stand in its way. We never want to force application architects to choose certain appstacks or deployment plans because it is the only way to keep it under management. We have built Application Director with the ability to deploy any app on any cloud. Users are not restricted by language or cloud. APM is optimized for java and VMware vFabric components, but it automatically can trace transactions running across your entire virtual infrastructure and with Hyperic embedded it ships automatically detecting and starting best practice monitoring for over 80 different technologies. And while both APM and Application Director come with a prepopulated catalog of supported technologies, they both are extensible so custom and yet-to-be invented technologies can be incorporated into application management easily.
We think we’ve designed and engineered a smarter solution. Our management tools know when the cheese moves and moves with it. In other words, when change happens, it adapts.