As businesses get serious about the cloud, developers are bringing more business-critical transaction data to cloud-resident web and mobile apps. Indeed, web and mobile apps that drive systems of engagement (how you interact with your customers and partners) are the reason why many companies look to the cloud in the first place. Public clouds offer the speed and agility developers want, plus the development tools they need. Once you’ve built a killer web or mobile app in the cloud and it’s in production, driving real revenue, who’s responsible for making sure it performs?
It’s a team effort. Developers have to think about performance management as they build, and IT operations teams need to design application monitoring and management into their cloud deployment processes up front. Why? Because there’s no time to do it later. You won’t have time to implement a new app monitoring solution for each new cloud app before you need to get it out to users. And once it’s out there, you need to be tracking user experience immediately.
In traditional IT, one of the reasons we could get away with limited insight into application performance was because we usually overprovisioned resources to make sure we didn’t have to worry about it. It’s easier to have excess capacity than to solve tricky performance problems – problems you might only see once in a while.
Bridgekeeper: "What ... is your name?"
Traveler: "John Swainson of Dell."
Bridgekeeper: "What ... is your quest?"
Traveler: "Hey! That's not a bad idea!"
We suspect Dell's process was more methodical than that!
This acquisition was not a surprise, of course. All along, it has been obvious that Dell needed stronger assets in software as it continues on its quest to avoid the Gorge of Eternal Peril that is spanned by the Bridge of Death. When the company announced that John Swainson was joining to lead the newly formed software group, astute industry watchers knew the next steps would include an ambitious acquisition. We predicted such an acquisition would be one of Swainson's first moves, and after only four months on the job, indeed it was.
I have been working on a research document, to be published this quarter, on the impact of 8-socket x86 servers based on Intel’s new Xeon 7500 CPU. In a nutshell, these systems have the performance of the best-of-breed RISC/UNIX systems of three years ago, at a substantially better price, and their overall performance improvement trajectory has been steeper than competing technologies for the past decade.
This is probably not shocking news and is not the subject of this current post, although I would encourage you to read it when it is finally published. During the course of researching this document I spent time trying to prove or disprove my thesis that x86 system performance solidly overlapped that of RISC/UNIX with available benchmark results. The process highlighted for me the limitations of using standardized benchmarks for performance comparisons. There are now so many benchmarks available that system vendors are only performing each benchmark on selected subsets of their product lines, if at all. Additionally, most benchmarks suffer from several common flaws:
They are results from high-end configurations, in many cases far beyond the norm for any normal use cases, but results cannot be interpolated to smaller, more realistic configurations.
They are often the result of teams of very smart experts tuning the system configurations, application and system software parameters for optimal results. For a large benchmark such as SAP or TPC, it is probably reasonable to assume that there are over 1,000 variables involved in the tuning effort. This makes the results very much like EPA mileage figures — the consumer is guaranteed not to exceed these numbers.