One of the tasks an IT Architect is typically assigned with is reconciling infrastructure and application needs, this holds true for the Cloud just the same as on-premise solutions (and all Hybrid variations of the 2). This type of reconciliation is typically referred to as Performance Engineering. Performance Engineering is seldom a one-off activity, although Architects tend to get involved during crucial junctures such as planning phases or in the midst of crisis scenarios, and operational staff monitor and make adjustments on a more regular basis. First, let’s take a look at what tends to make up a typical performance engineering activity or assessment:
- Preliminary Requirements Estimation
- Initial Capacity Assessment
- Network Benchmarking
- Application Benchmarking
- Application Tuning
- Capacity Adjustments
- Application Testing
Not every Performance Engineering activity requires this full lifecycle approach, however it should occur as least once and preferably be continuous in coordination with major application releases or transformation initiatives. Elements from each of these lifecycle pillars can be built into the continuous performance monitoring framework as well – although what you can do is highly contingent on what types of performance monitoring or automation you have in place.
Regardless of whether you are doing a preliminary performance exercise or preparing for a major release or transformation, there are a number of principles that tend to apply which need to be considered in any assessment:
1 – Context is King: The idea of performance is a somewhat relative concept; what one audience or set of clients finds acceptable may not be acceptable to another. Also, even within the same audience, expectations are prone to change. The first step in any performance exercise is determining what is or isn’t acceptable in a given context. This will drive all sorts of decisions and tends to happen mainly in the requirements phase but can be recurring.
2 – Don’t depend solely on one information source: Too often, teams can make decisions on an incomplete picture, relying solely on utilization statistics or UAT results, etc. Performance is a dynamic science – it requires inputs from all available sources in order to obtain an accurate picture. In some situations, important sources of performance information are missing altogether – such as lack of performance automation tools or a performance environment. In these cases, those information deficits must be considered serious operational risks and treated as such.
3 – Always utilize a performance environment – one that mirrors Production: This principle of course is not just for performance management, it is required in order to get a sense of how Production will really operate. However, not all QA environments are precisely matched with Production and when that happens there is always an increased risk that both performance and functionality cannot be accurately predicted or assessed until the application goes live – which is never a good thing.
4 – Get to know your application, holistically: Every application is different, moreover an application is more than likely of a system of system conglomerate of capabilities working in tandem. It is critical that all of these elements are assessed – from the Operating System to the data interfaces to network connectivity and load balancing. Division of labor often separates interests in terms of who is responsible for what, but ultimately someone is responsible for the whole thing and that typically is the IT Architect.
5 – Err on the side of caution: In most cases, the cost of procuring additional computing or networking resources now is relatively inexpensive compared to the good old days in IT. While it doesn’t make sense to massively over-provision an environment, by the same token it make little sense to ‘see how long you can ride on the fumes either.” Give yourself a healthy buffer, one that allows for application growth and can handle unforeseen events.
I’ve found that these principles help to provide a framework for about any performance assessment scenario. If I were to add another principle it might be this one – whenever doing performing assessments or engineering, leverage expert knowledge across the stack rather than assuming that you can answer every question entirely on your own. In today’s complex environments, it’s difficult to find someone who is expert in all aspects of the solution – being able to find and take full advantage of subject matter expertise is an important skill for any IT Architect.
Copyright 2016 - Stephen Lahanas
0 comments :
Post a Comment