Business Agility

Business Agility covers using the technical agility delivered by virtualization and cloud computing to improve business agility, performance and results. This includes the agility derived from the proper implementation of Agile and DevOps methodologies, the agility derived from proper application and system architectures, (Read More)

the agility derived from the proper implementation of Infrastructure as a Server (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) clouds, the agility derived from proper monitoring of the environment coupled with a process to resolve problems quickly, and the agility derived from have continuous availability through the use of high availability and disaster recovery products and procedures in place.

The Big Data Back End for the SDDC Management Stack

SDDC.Management.Stack.Reference.ArchitectureIn, Building a Management Stack for Your Software Defined Data Center, we proposed a reference architecture for how one might assemble the suite of management components that will be needed to manage a Software Defined Data Center (SDDC). In this post we take a look at the need for that management suite to be supported by a multi-vendor big data datastore, and take a look at who might provide such a data store.

The Need for a Multi-Vendor Management Data Store in Your SDDC Management Stack

So why you ask, will a SDDC require a set of management products that will in turn require a multi-vendor big data back end. The reasons are as follows:

  1. The whole point of moving the configuration and management of compute, memory, networking and storage out of the respective hardware and into a software layer abstracted from the hardware is to allow for configuration and management changes to happen both more quickly and more automatically (which means very quickly). Each configuration change or policy change is going to create a blizzard of management data.
  2. If you look at all of the horizontal boxes in our Reference Architecture (below) each one of them along with the vertical IT Automation box will be generating data.
  3. The rate of change in the SDDC will be high enough so as to require fine grained and very frequent monitoring at every layer of the infrastructure.
  4. Just combining the number of layers with the rate of change with the need for fine grained and high frequency monitoring (5 minutes is an eternity) creates a big data problem.
  5. Finally, the need to be able to to cross layer root cause analytics (where in the software or hardware infrastructure is the cause of that application response time problem) means that the root cause analysis process has to cross domains and layers. This in and of itself calls for a common data store across management products.

The Software Defined Data Center Management Stack Reference Architecture



Who Could Provide the Multi-Vendor Big Data Repository?

There are two basic criteria for being able to provide such a repository. The first is that you have to have one, or have the intention to build one. The second is that since it is multi-vendor, you have to have the technical capability to, and the business model to partner with the vendors whose products will feed this datastore. The rest of this post is entirely speculative in nature as it is based upon who could do what, not upon who is doing what. To be clear, no vendor listed below has told us anything about what they intend to do in this regard. The rest of this post is based entirely upon what people are shipping today and the author’s speculation as to what might be possible.


If there is one vendor who has an early lead in filling this role it would be Splunk. Splunk is in fact the only vendor on the planet from whom you can purchase an on-premise big data datastore, which is today based upon shipping and available products being populated by data from management products from other vendors.  In fact if you go to SplunkBase do searches on things like APM, monitoring, security, and operations you will find a wide variety of Splunk written and vendor written applications that feed data into Splunk. Now it is important to point that today, when a vendor like ExtraHop Networks or AppDynamics feeds their data into Splunk they are not making Splunk in THE back end datastore for their products. They are just feeding a subset and a copy of their data into Splunk. But this is a start, and it puts Splunk further down this road than anyone else. Needless to say, if the vision of the multi-vendor datastore is correct, and Splunk is to become the or one of the vendors who provides this, then Splunk is going to have to entice a considerable number of software vendors to trust Splunk to perform a role that no vendor today trusts any other vendor to perform.


In, VMware Fleshes Out SDN Strategy with NSX, we went through how VMware is combining Nicira into its Network Virtualization offering, NSX. In the VMware announcement there was a link to a blog post, “Open Source, Open Interfaces, and Open Networking” contained the following fascinating statement:

Statistics Collection & Telemetry

“Another area of focus for an open networking ecosystem should be defining a framework for common storage and query of real time and historical performance data and statistics gathered from all devices and functional blocks participating in the network. This is an area that doesn’t exist today. Similar to Quantum, the framework should provide for vendor specific extensions and plug-ins. For example, a fabric vendor might be able to provide telemetry for fabric link utilization, failure events and the hosts affected, and supply a plug-in for a Tool vendor to query that data and subscribe to network events”.

Needless to say, it is highly unlikely that VMware would choose to make the current datastore for vCenter Operations into the “framework for the common storage and query of real time performance data“. Rather it is much more likely that VMware would build its own big data datastore with the people and the assets that VMware acquired when VMware acquired the Log Insight technology and team from Pattern Insight. VMware therefore clearly has the technology building blocks and the people to pull this off. You could also argue that they would not have make this acquisition if there were not intentions to go at least somewhat in this direction. The key challenge for VMware will then be the multi-vendor part. VMware has no relationship of technical cooperation with any other management software companies other than Puppet Labs, so this is clearly an area where VMware has a long way to go.

New Relic

New Relic is the hands down market leader for monitoring Java, .NET, Ruby, Python, and PHP applications in the cloud. New Relic offers cloud hosted APM as a Service and has gone in four years from a brand new company to now having more organizations using its product than the rest of the APM industry combined. New Relic recently raised $75M from top tier investors and is rumored to be positioning itself for an IPO in the 2014-2015 timeframe. New Relic already makes its data available to third parties in its partner program via a REST API. It is not much of a stretch for New Relic to consider becoming the management platform in the cloud, partnering with adjacent vendors and becoming a vendor of the multi-vendor cloud datastore. Again all of this is pure speculation at this point.

The Pivotal Initiative

The Pivotal Initiative is a new company formed with assets and people from EMC and VMware lead by former VMware CEO Paul Maritz. These assets consist of the application platform PaaS products from VMware (Gemfire, Spring, vFabric and CloudFoundry), and the big data assets fromEMC (GreenPlum). The stated ambition is to deliver a way to build and deploy big data applications that is radically better than the incumbent method and tackle giants like IBM, Microsoft, and Oracle in the process. This means that the focus of both the application development assets and the big data assets is most likely to be upon solving business problems for customers, not IT management problems for customers. However, it would not be inconceivable for a third party company to license these technologies from Pivotal and build an offering targeting the multi-vendor management stack use case.


Consider the possibility that this multi-vendor big data datastore is in fact non on-premise, but in the cloud. If you are willing to consider that possibility, then it is not much of a stretch to consider that CloudPhysics a vendor with cloud hosted (delivered as a service) operations management solutions might step into this fray. One of the key reasons that CloudPhysics may be able to provide something of extraordinary value is that the company has a strategy of applying Google quality analytics to Google size data sets. The analytics come from a world class team of people some of whom previously worked at Google. The data today is collected by virtual appliances installed at CloudPhysic’s customer sites (in their respective VMware environments). If CloudPhysics is already collecting data across customers and putting it in its cloud, it is not too huge a stretch to consider the possibility that other vendors who also deliver their value as a service could partner up with CloudPhysics, combine their respective sets of data, and produce a 1+1=3 scenario for joint customers.


AppNeta is today a market leading vendor of a cloud hosted service, PathView Cloud, that measures the performance of the wide area network in between the users and branch offices of an enterprise and the enterprises back end data center. The back end is a true big data back end, built around true big data technologies. AppNeta is branching out into APM with its TraceView offering.  But network performance data and application performance data are just parts of the compete set of data that will get generated by the SDDC and about the SDDC by various management products. AppNeta does not today have a partner program to attract third party data to its management data cloud, but who knows what the future holds.


Boundary is an APM vendor with a cloud hosted big data back end that today focuses upon collecting the statistics from the network layer of the operating system that support applications running in clouds. If you think of New Relic as the vendor who is monitoring your application in the cloud, you can think of Boundary as the vendor who should be monitoring the interaction of your operation system underlying your application with the cloud.  Boundary has no partner program today, and no ability to add third party vendor data to its cloud datastore today, but again who knows what the future might hold.


The SDDC and the Cloud are going to require a new SDDC Management Stack that will need to be based upon a multi-vendor big data datastore. There will likely be on-premise and cloud hosted version of these datastores. Splunk, VMware, New Relic, The Pivotal Initiative, CloudPhysics, AppNeta, and Boundary are all excellent hypothetical suppliers of such a datastore.

Public Cloud Reality: Do we Stay or Do We Go?

CloudComputingSoon the backup power will be available for our new datacenter and the redesign to make use of VMware vCloud Suite is nearing completion. Soon, our full private cloud will be ready for our existing workloads. These workloads however now run within a XenServer based public cloud.  So the question is, do we stay in a poorly performing public cloud (mentioned in our Public Cloud Reality series) or move back to our own private cloud? As the Clash put it “Should I Stay or Should I Go Now.” Continue reading Public Cloud Reality: Do we Stay or Do We Go?

Public Cloud Reality: Reinforced at CSA Summit

CloudComputingI have written about the Public Cloud Reality and the need to bring your own security, monitoring, support. This was reinforced by Dave Asprey of Trend Micro at the last Cloud Security Alliance Summit held at this years RSA Conference. The gist of Dave Asprey’s talk was that YOU are responsible for the security of your data, not the cloud service provider. Unfortunately, this sort of discussion often devolves into one of shared vs tenant responsibility, the type of data, etc. It will also devolve into a legal discussion just as quickly. Unfortunately, all this does is point fingers. The long and the short of this discussion is about two items often mixed as one. Continue reading Public Cloud Reality: Reinforced at CSA Summit

Building a Management Stack for Your Software-Defined Data Center

SDDC.Management.Stack.Reference.ArchitectureData Center Virtualization has spawned several entirely new categories and variants of management software. This is largely because data center virtualization alone was a large enough change to create new requirements that legacy management products could not meet. This created a new constituency for management solutions—the virtualization team—which proceeded to purchase management solutions that met their needs. This trend was facilitated by the “easy to try and easy to buy” business model that many of the new vendors of virtualization management solutions adopted. Out of this a new management software industry arose. Continue reading Building a Management Stack for Your Software-Defined Data Center

APM for Agile and DevOps: 7 practical use cases

APM for AgileApplication Performance Management (APM) solutions are historically monolithic systems used by IT operations for monitoring the performance of production applications. But this trend is changing quickly. A combination of agile and DevOps methods combined with cloud computing and a new generation of DevOps focused APM products are adding value throughout the agile development lifecycle – far beyond application support.

Legacy APM tools are generally expensive, complex, require lots of configuration to get working and are fragile when application ecosystems change. They were designed for applications running on physical hardware that rarely change – the antithesis of agile development in the cloud. These new breed of APM products including AppDynamics, New Relic, dynaTrace, Foglight and VMware vFabric APM amongst others still do what their predecessors did, but now they’re increasingly being embraced by developers, testers and DevOps team members. These people are using APM to add value during analysis, design, development and testing phases too.

This article highlights specific ways agile teams are using APM outside IT operations, starting from a project’s kickoff.

#1 – Kickoff

APM Setup Checklist

As a part of starting a new project or product, many agile teams do a Sprint 0. This Sprint is primarily focused on technical tasks and planning so that new feature development can begin in Sprint 1. While the product team is focused on writing the initial user stories, the technical team can focus on hooking up APM to their application while integration is still simple. This, along with other stories for continuous integration, code management can be done.

These steps might be largely manual at first or if they occur rarely. However, if setting up new applications or projects is a common than these can be largely automated. Tools like Puppet can script the installation of the controller and/or agents as a part of environment setup. Agent configuration file(s) can be packaged with application frameworks so new applications are automatically configured to communicate with the controller.

If you’re developing in a PaaS solution such as Heroku or Azure, integrating a new application with APM is even simpler. Just enable in your PaaS management dashboard and you’re set.

#2 – Analysis

Most agile teams capture functional requirements in the user story format: As a <Persona>, I would like to <Do Something>, so that I can <Achieve Some Result>

NFR for Performance

Along with each user story are a set of acceptance criteria that defines specifies when a user story is “done”. Often acceptance criteria may include non-functional requirements related to performance, scalability and resiliency. Teams often struggle with how to test these during development, and area where APM can help.

Defining a non-functional requirement can be as simple as as the example above. The method alone clearly stakes which APM metric from which dashboard, under what amount of load and for what percentage of users. This clarity of requirement not only sets expectations with internal stakeholders including architects and developers, it’s also something that can be easily integrated into a business-facing dashboard built in the APM product during development and available after release.

#3 – Design & Development

During development APM is a supplemental tool to the team, not something necessarily used everyday but a very handy tool for running down issues, such as why a particular test failed or why page load times are slow for single users. They can also identify poor design decisions and raise them to the surface, something that occurred on a recent project I audited.

Two companies were charged with building a new customer service web site for a client. One focused on the CMS and web application. The other on creating web services to expose data in legacy systems to customers. During design the legacy team insisted on creating fine grained web services because it was the least expensive option and easiest to do. The project manager agreed and teams moved forward. The web team’s user story requirements called for a year’s worth of transaction data to be displayed on the web page. The web team  implemented the story, making the right API calls, and the functional tests passed.

Soon thereafter developers and testers started complaining about the slow load times. They hooked up their APM tool and discovered the offending page was making 117 web service calls to get the required data to load the page. Although each call was less than 400 milliseconds, the sheer number made the performance horrible. The web team brought this information to the legacy team’s attention, showed them the APM data. Then they quickly worked out a single API call that took additional parameters but made the integration much simpler and faster. Once each team refactored their code the page load time dropped dramatically.

Solving integration problems like these are a part of a developer’s life. Without the right tooling, some of these problems may take days or weeks to resolve and potentially result in a whole bunch of hand-written diagnostic code.

The new breed of APM tools get this reality and are increasingly focusing their attention on developers and not just operations. In addition to free developer versions of their products, APM vendors are forming partnerships with PaaS vendors (such as New Relic with Heroku and AppDynamics with Azure) to make integrating monitoring into your applications very simple.

#4 – Functional Testing

Agile teams leverage automated testing as a normal part of their sprints. While developers focus on automated unit testing, quality assurance typically focuses on integration and acceptance testing. During each sprint APM is hooked up to the application in the test environment(s). If one of the automated tests fail at a specific time, the corresponding snapshot of the failed transactions at that same time can be captured from APM to enable further analysis. Tools like Splunk can also help here as well, enabling developers and testers to collaboratively solve issues uncovered by testing – especially tough ones such as bugs that are only reproducible under certain conditions.

#5 – Performance Testing

This is one of the most popular uses of APM as it helps architects, developers and testers answer questions such as: what really happens to the application under load and can the application support the customer demand?

Modern APM’s are essentially application profilers that have such a low overhead they can run all the time without negatively impacting an application’s performance. Gone are the days of hooking up an application profiler, running tests and having your results skewed greatly because of their invasive overhead. Today’s APM tools give developers the same drill down capabilities – such as identifying the problem line of code or SQL statement – that profilers traditionally provided but without the overhead and extra setup.

What this means is that during performance tests, a team can in real-time watch the application’s performance under load and diagnose issues on the fly. They can also save off results for post-analysis. APM’s are useful for clearly identifying bottlenecks and limitations on scalability. They bring these issues to the attention of the team who are in the best position to fix them, whether this be tweaking a configuration parameter or refactoring code. They’re also useful for recording previous performance test runs so teams can do comparisons between releases to look for any subtle trends.

It’s no secret that faster applications generate more revenue and better customer experience. Amazon notes that every 100 millisecond drop in response times yields a 1% sales decline (that’s a $200M+ potential revenue impact). Google notes that a 500 millisecond drop in response times results in 20% less search traffic. This means the new APM tools are delivering value not only by reducing resolution times (costs), but also improving performance (revenues) – a great position for any product.

#6 – Production Deployment

APM is particularly helpful during new releases to production, which can be nerve-racking events themselves. Most vendors have a way to indicate a change to production such that post-release metrics (such as response time) can be compared with pre-release metrics. Should something look amiss or there’s a performance problem identified, the decision can be made to quickly rollback and investigate. Data from the APM tool can be used as a part of this analysis to figure out what went wrong before attempting the next release.

This same basic process can be applied to teams practicing continuous deployment. But instead of relying on humans to do the release analysis, this is automated so only exceptions are raised to the attention of humans, otherwise the same post-launch checks are all done via automated tests and validated in part using APM. Should issues arise, workflow scripts can be created to send issues to the organizations incident management system. A table of popular DevOps competent APM tools for use in dynamic and cloud based environments is below.

DevOps Focused APM Tools

Vendor/Product Product Focus Deployment Method Data Collection Method Supported App Types Application Topology Discovery Cloud Ready “Zero- Config” Deep Code Diagnostics
AppDynamics Monitor custom developed Java and .NET applications across internal and external (cloud) deployments On Premise/SaaS Agent inside of the Java JVM or the .NET CLR Java/.NET
dynaTrace (Compuware) Monitoring of complex enteprise applicatons that are based on Java or .NET but which may include complex enterprise middleware like IBM MQ and CICS On Premise Agent inside of the Java JVM or the .NET CLR Java/.NET, Websphere Message Broker CICS, C/C++

New Relic RPM Monitor custom developed Java, .NET, Ruby, Python, and PHP applications across internal and external (cloud) deployments SaaS Agent inside of the Java JVM, NET CLR, or the PHP/Python runtime Ruby/Java/ .NET/PHP/Python

Quest Foglight Monitor custom developed Java and .NET applications and trace transactions across all physical and virtual tiers of the application On-Premise Agent inside of the Java JVM or the .NET CLR Java/.NET  
VMware vFabric APM Monitor custom developed Java applications in production. Strong integration with the rest of the VMware product line including automated remediation and scaling. On Premise Mirror port on the vSphere vSwitch and an agent inside the Java JVM HTTP/Java/.NET/SQL

#7 – Support

This is the traditional use case for APM and still the most popular: helping operations teams reduce incident resolutions times. This may be in real-time as an incident occurs or during post-incident analysis looking for clues as to what went wrong. Often times this includes looking into slow or failed transactions to identify root causes. I’ve known teams to use APM to discover the 5am database back-up job is causing application performance to degrade.

From SLA management to operational dashboards, these newer APM tools still support their core operations administrator and help-desk engineer. But with increased simplicity and more intuitive user interfaces, these new APM adding value beyond their traditional support role.


A new breed of DevOps focused APM tools is moving performance management outside the domain of operations. With features to support analysts, architects, developers, testers and DevOps APM is at home in all phases of agile development.


Browsium Catalyst Available Now – Time to Quell Corporate Browser Choice Feuds?

Browsium CatalystBrowsium have released Catalyst, a browser management utility designed to make deploying multiple browsers in the enterprise a manageable reality.

The browser is a gateway to the Internet, to applications, to data, to the corporate intranet. Outside of the office, its not uncommon to switch between browser versions between devices: or even have different browsers on the same device. My Google App world is ably accessed from a Chrome experience synchronised between devices, but I have Internet Explorer on-hand, and Firefox still gets a run out all be it increasingly less so.

Indeed, for many corporations such care-free browser relationships are equally common. This might be because different browser versions are required to maintain access to legacy applications; to give users more choice; an effort to reduce the impact of a browser security issue. Alternatively, because control of different browser environments has been complex in the past, it is deemed less cumbersome and risky to mandate a single browser environment.

With the release of Catalyst, can care-free relationships be afforded a level of sensible protection? Can restrictive single-browser choices be relaxed and more business user friendly? Browsium intend Catalyst to reduce helpdesk calls and improve IT security allowing more granular control of all browsers in the enterprise and how does it do that?

Continue reading Browsium Catalyst Available Now – Time to Quell Corporate Browser Choice Feuds?