newsroom

In the world of IT, it is difficult to accomplish the Goldilocks balance of getting things “just right,” rather than having too few computing resources or too many. It’s easy to say you can never have too much compute power, but the reality is that there is always a tradeoff and any money saved on buying and running servers can be put to good use elsewhere. Nevertheless, that is not the most common problem. It’s more usual to see insufficient compute resources that result in the inability to get work done in a timely manner, impacting operations: slowing time to market, for example, or delaying response to customer needs or trends.

This problem would be somewhat more manageable if the volume of data to be processed were constant hour by hour, day by day, week by week.  But of course, it is not. There are peaks and troughs in the demand for computer resources.  For example, there is frequently increased demand to handle end-of-quarter accounting – or the increased volume and volatility of stock trading on four “triple witching” days each year, when contracts for stock index futures, stock index options and stock options all expire on the same day.  In these circumstances and in many others, systems still need to provide a predictable response, even in the face of unpredictable demands.

Shared infrastructure and workload management

In many cases, peak volumes for an organization’s different applications occur at different times. Here, shared infrastructure can help.  This is an IBM Spectrum Computing core capability that manages the lending of otherwise idle resources by one department for use by another where there is high demand. This can help significantly to smooth out the bumps and improve resource utilization.  But it is not always a complete solution: at times total demand can simply exceed the capacity of even the best-planned shared infrastructure.  When this happens, as an alternative to putting compute tasks into an ever-lengthening queue and frustrating users, IT organizations can turn to cloud bursting – the temporary use of public cloud resources to process peak workloads in a timely manner.

But the public cloud approach has been problematic for financial service providers. With their exceptional needs for data security and privacy, they have generally not been able to allow individually identifiable information to leave their premises for cloud-based processing.  That has now changed.

Comprehensive security for bursting data to the cloud

IBM Spectrum Computing has a long and successful track record of providing workload management and resource sharing solutions for mission-critical financial services applications.  Along with IBM Cloud, IBM Spectrum Computing offers a solution with comprehensive security from top to bottom of the technology stack designed to protect data at all times. The solution allows organizations to deploy IBM Spectrum Symphony high-performance workload management and resource scheduling both on premises and in the cloud with security that incorporates encryption of boot images and network and NSA-level (SHA-2) encryption of communications.  This level of security provides a degree of assurance that has given one major US financial institution the confidence to finally break out of the constraints of an on-premises infrastructure and to burst workloads to IBM Cloud in order to handle peak capacity.

This solution is available now. Financial services providers and others with equivalent security requirements can take advantage of cloud bursting to more efficiently obtain consistent performance across the peaks and valleys of demand for computer resources. In addition to improving performance, users can potentially save millions of dollars per year in capital and operational expenditures for hardware, space, administration and other costs.

As for Goldilocks, unfortunately we can’t promise that she will live happily ever after. This is a true story, after all, not a fairy tale.

The post Goldilocks finds that secure cloud bursting is just right appeared first on IBM Systems Blog: In the Making.