IT infrastructures are being modernised, and most applications migrate successfully with them. But some applications, conversely, slow down and do not benefit from the advance. Suggestions are made to resolve the problems in the infrastructure, but these are not taken up upon due to the investments involved and because they do not fit into the new architecture. In almost all cases, the impasse between users and the IT organisation is broken by escalations, and the story ends with one or more unforeseen provisional items on the operating balance sheet. Situations of this kind are easily avoided if exceptions are recognised in time.
Applications have limited future-proofing
An application is designed for optimal performance in a specific type of technical environment and for a specific use. In recent years, however, IT infrastructures have undergone major changes for the sake of flexibility and manageability. Virtualisation, storage centralisation, multi-site solutions and cloud solutions have become commonplace. However, certain changes turn out badly for the performance of some applications. The methods and technologies the developer selects while designing the application – and which are thus embedded in the application – can lead to performance problems when the software is used in an environment where different rules apply. The substrate grows and evolves, but applications don’t grow with it. This is a major reason why performance problems arise and grow.
Generic environments are an utopia
Infrastructure architects and administrators tend to think in terms of generic solutions in which all applications run. An ‘enterprise architecture’ is formulated, which conforms to all the current modern norms. To ensure continuing conformity in the future, it is demanded that no deviations from the common standard should be made. On the other hand, software suppliers assert that the new environment complies with the requirements that were formerly drawn up; after all, the environment is becoming faster. However, not all the dependencies an application has with its environment are properly documented. An application’s sensitivities and the associated ‘dos and don’ts’ are seldom well documented. This means there are no prior indications that problems will arise; they only appear after implementation. Applications cannot usually be modified, which means an exception has to be made in relation to the newly selected IT architecture.
Application versus infrastructure and vice versa
Ymor regularly investigates the cause of performance problems, and routinely encounters situations of this type. The solution is frequently simple, but the recommendations come up against objections of principle. Rather than the implementation of the solution, it is the debate about issues of principle which results in long, drawn out projects which – sometimes years later – are nevertheless realised. This could easily have been avoided by reserving space, even in the design phase of the new infrastructure architecture, for safe alternative provisions and including these in the budget.
Sample causes of slowdown
- Complex routing: Application components that communicate intensively with each other can be disproportionately hindered by increased complexity of the infrastructure in between them. Not only the physical distance between the components but also complex traffic stream and authorisation routing can cause unexpected problems. These problems can be easily resolved by permitting sensible alternatives for the routing of traffic between components of the relocation of components in the environment;
- CAD/GIS packages and VDI: Mapping and drawing packages set high demands for the graphic processing between the machine on which the package runs and the user’s screen. When these packages run in a centralised environment such as Citrix, problems are guaranteed to arise. Good but expensive solutions are available for this, and it is better to budget for them in advance;
- Abolish the C drive: When an application depends on the high availability of a storage medium, the introduction of shared networks can bring problems. Cases are known in which exorbitant investments have been made to hold on to the design principle. It would have been better to introduce a sensible alternative in advance, with which the total architecture could continue to fulfil the norms.
In short: identify issues in time
An application does not grow with the underlying and expanding IT environment. The architect will therefore have to take measures to avoid problems that arise from specific application behaviour. It is advisable to issue the administrators of a new environment with instructions so that exceptions can be neatly fitted in without detriment to the architecture. This does mean that the anticipated saving for the hardware, scalability and security of a new environment may be less than in an ideal situation. With a realistic view of the future, you avoid uncontrolled growth of ad hoc solutions and the associated expenses.
During his career Marcel has helped organisations such as the Dutch Railways, Prorail, ASR and various municipalities with improving their IT-services. Speed, capacity, scalability and stability of the software are keywords in this. Marcel started his career as a developer in 1996, followed by working on performance testing, load modeling, performance troubleshooting and in the last few years automating performance testing in agile development projects. Within the organization Marcel is known for his Dynatrace expertise.
We would like to keep in touch! Join our newsletter and be informed about new developments, blogs, events and more.