Tuesday, 3 December 2013
The FableThe two great heads of IT sat and stared at each other across a meeting room table. It was late in the day, and thankfully their services had all been restored. Now was the time for recriminations. The CIO had been called into firefighting meetings with the board all day. They knew he was going to be royally pissed off, but who was going to get the blame?
The beginningThe story began when service performance nose-dived. It was always a busy period, the lead-up to Christmas, but this season had been marked by some hugely successful promotional campaigns, and their online services had been humming with traffic. Nobody quite knew what caused it, but suddenly alarms started sounding. Throughput slowed to a trickle - and response times rocketed through the roof. Downtime. At first the infrastructure team, plunged into a triage and diagnostics scenario, did what they always did. Whilst some were busy pointing fingers, they formed a fire-fighting team, and quickly diagnosed the issue - they'd hit a capacity limit at a critical tier. As quickly as they could, they provisioned some additional infrastructure and slowly brought the systems back online.
The backgroundBut why had all this happened? Some months ago, and at the advice of some highly-paid consultants, the CIO had restructured the business into a private cloud model. The infrastructure team provided a service to the applications team, using state-of-the-art automation systems. Each and every employee was soon enamoured with this new way of working, using ultra-modern interfaces to request and provision new capacity whenever they needed it. Crucially, the capacity management function was disbanded - it just seemed irrelevant when you could provision capacity in just a few moments.
The inquisitionBut as the heads of IT discussed the situation it seemed there were some crucial gaps they had overlooked. The VP of Applications confessed that there there was very little work being done in profiling service demand, and in collaborating with the application owners to forecast future demands. He lacked the basic information to be able to determine service headroom - and crucially was unable to act proactively to provision the right amount of capacity. In an honest exchange, the VP infrastructure also admitted to failings in managing commitment levels of the virtual estate, and in sizing the physical infrastructure needed to keep on top of demand. In disbanding the Capacity Management function, they realized that they had fumbled - and in fact needed those skills in both of their teams.
The ConclusionThe ability to act pro-actively on infrastructure requirements distinguishes successful IT organisations from the crowd. What these heads of IT had realised is that the private cloud model enhances the need for Capacity Management, instead of diminishing it. The dichotomy of Capacity Management in the private cloud model is that these two functions belong to both sides of the table - to the provider, and to the consumer. Working independently, they would be able to improve demand forecasts and diminish the risk of performance issues. Working collaboratively, these twin dichotomies combine in a partnership that allows a most effective way of addressing and sizing capacity requirements to align and optimize cost and service headroom.
- As a consumer, ensure you are continually well-informed on service demand and capacity profiles. Use these profiles to work with your application owners in forecasting different 'what if' scenarios. Use the results to identify which are the most important metrics, and prepare a plan of action when certain thresholds are reached.
- As a provider, ensure you are continually tracking your infrastructure commitment levels and capacity levels. Use the best sizing tools you can find to identify the right-size infrastructure to provision for future scalability.
- Have your capacity management teams work collaboratively to form an effective partnership that ensures cost-efficient infrastructure delivery and most effective headroom management.
Will you wait for your own downtime before acting?
Tuesday, 24 September 2013
- The fit with your longer-term business plans
- The measurable benefit to your business
- The investment needed
- comparing and contrasting capacity options has descended into a "dark art", with many stakeholders and an over-riding aversion to risk
- measuring capacity usage has become a specialized platform function, leading to difficulties in getting an end-to-end perspective of how much business can be transacted
- an increasingly agile enterprise is causing rapid fluctuations in capacity requirements, again with an aversion to risk
- endeavours to provide a complete picture of capacity usage across all silos
- provides visibility of service headroom, potential bottlenecks and abundances
- couples together with your financial management controls, providing governance over capacity allocation
- gives insight into future business scenarios, allowing investments to be rebalanced against the needs to transact business
Tuesday, 16 July 2013
Saturday, 27 April 2013
The notion of #Devops serves to accelerate time to market through greater cohesion in the release management life cycle.
So called 'service virtualisation', such as offerings from IBM and CA LISA, enables modular testing practise by learning typical behaviour patterns of defined systems. The effect is a more tightly focused testing process that reduces the dependency on external (inert) services.
Release Automation, such as in the newly acquired Nolio solution, allows the testing process to be further streamlined by providing cohesion through the multistage process. The benefits are most highly felt where complex dependencies and configurations add magnitude to setup and teardown for QA.
Agile methods need agile release management processes, and this is the whole point of #Devops. However the risks in this agile thinking come in end- to-end performance.
The missing link here is provided by prerelease Capacity Planning (such as provided by CA Performance Optimizer) , a virtual integration lab that brings together the performance and capacity footprints of each component in the production service. And while some of those components may be changing and therefore measured through the release management process, others are not - and are measured in production. Creating and assimilating component performance models allows the impact of each sprint to show on IT operations.
Capacity Planning is a true #Devops process. Only by adapting the capacity plan to take into account the step changes due to software release, can the risks of poor scalability and damaging impact be accurately guarded against.
Monday, 25 March 2013
But what about our IT enterprise? It's not uncommon - even in 2013 - to come across siloed thinking that stifles the health of the organisation. Purchasing decisions are made within the silos, leading to distorted allocations of capacity based on political, rather than engineering needs. Further - due to the manifestation of these silos, entropy increases as financial accountability struggles to permeate the organisation. Provisioning decisions are made on a risk-averse basis without insight into how business demands translate into capacity requirements.
And now it's time to change.
The financial crisis has caused a significant change in emphasis in most major corporations. IDC estimate that over 50% of major corporations are actively planning investments in better capacity management functions. Cloud-sourcing is on the increase to assist with the deferment of cost, and a refocus of investment on the core business. Capacity has become a commodity, and in an open economy, is becoming subject to the same commercial forces that balance cost and quality in any marketplace.
But how can enterprises leverage their purchasing power, when they don't know how much commodity capacity they really need? How can they right-size investments and defer costs without incurring risk to their top-line revenues?
Actually, this is a question that enterprises have addressed in many of their other lines of operation. Full financial accountability has ensured the right-sizing of many other enterprise assets; whether that is employees, hot-desks, freight containers or manufacturing capacity. Successful companies have figured out that costs must be aligned proportionately with revenues. The only thing that makes IT different is the complexity, and the lack of insight.
So where to start in right-sizing IT?
The answer is perhaps startlingly clear - you should begin where you always begin, with your requirements in mind: measure capacity consumption across all silos. The trick then is to bring in a method of normalization, a model library that provides weighting factors according to the make and configuration of your estate. This same method can then be applied to plan a migration, transposing configurations easily to determine the optimum sizing on alternative real-estate.