Profiling Paradigm Shift in the Package World
The way applications are resourced these days have a number of applications on a single virtualized bed of infrastructure be it private, public or hybrid deployment models. Application vendors are talking about multitenant models. Service providers are hosting tailored application platforms for their clientele. The dynamics of hosting, appropriation of resources, and application customization is quiet different. In my previous blog here I urge on a stronger and proactive production environment. So what is necessary ingredient to bring that level of sophistication? The answer is the ‘profiling horizontal’. So how and why is it relevant to particularly SCM and generically packages. I take Sterling OMS as a case study to convey my view points.
Tomorrow, when a host of SMEs are on a cloud using Sterling for managing their orders on a platform that a service provider has created and is maintaining, using System Management Console to see the performance of every JVM, every service and API is extremely cumbersome. Considering the multi-tiered nature of Sterling, the OS, the data base server, application server, messaging middleware such as MS MQ and the database server employed by the messaging tier must also be profiled.
To further emphasize my point, today we use the Web Sphere Admin console to diagnose the performance of WAS, use OEM for Oracle RAC instances, and MS MQ console. Silos of performance monitoring tools! Multiply that by the number of clients! Result is a monitoring nightmare! Further, merely monitoring the CPU utilization and memory utilization is not enough to indicate an expensive query, a leaky data structure, or a bad template for getOrderDetails API in an Order Search page. I mean the internals of the applications are not known. So any level of external profiling tool can only help so much. Here is an illustration...
Solution: Make the profiling a horizontal across all tiers as illustrated in Figure 2. This could be picked by the really strong resource managers at the data center level to not only alert the application admins but also narrow down the problem to a data structure in a tier for a given application. If each tier can offer APIs that provide insight into the internals of the application for authorized personnel, then profiling takes its correct meaning and will not only reduce but also in many cases eliminate the need to further reproduce the problem. We could directly fix the problem. Here is a depiction....
