The Application Architecture is Shifting Again

APM is all about monitoring applications and the effectiveness of an APM tool depends upon whether or not it is (or was) built to correctly monitor a set of applications that are built to specific architectures and to specific languages. Therefore as architectures and languages of applications shift, the approach that the APM tools take must shift as well. These shifts in application architecture are so profound, that they have in the past created entirely new winners and losers in the APM tool business. The current shift to microservices could well create new winners and losers as well.

The First Phase of APM – Monolithic Java Applications

Wily Technology was launched in 1998 to instrument transactions implemented in Java and that were running on J2EE application servers. The most popular early J2EE application servers were WebLogic and WebSphere. WebLogic ultimately got acquired by BEA Systems, and BEA ultimately got acquired by Oracle. WebSphere came from the acquisition of Cyanea by IBM in 2004.

During this era key application functionality was migrated off of mainframes and on to distributed systems but the applications were highly monolithic in nature. In many cases the systems were high end UNIX servers like HP-UX, Sun Solaris, and IBM AIX that had hundreds of processors in them and the entire application ran on one server and in one Java Virtual Machine (JVM).

The Second Phase of APM – Distributed Applications and New Languages

Starting in about 2007, three significant changes occurred:

  1. Lightweight and open source Java Applications Servers like Tomcat, JBoss, Jetty, GlassFish and since then many others started replacing heavyweight J2EE Application Servers like WebLogic and WebSphere
  2. The middleware for highly distributed and loosely coupled applications matured. Service Oriented Architectures based upon web protocols or messaging protocols became the norm.
  3. New languages were invented to solve specific problems and to speed up the process of implementing business functionality in software.

The above dynamics resulted in applications being broken apart into distributed services, with each service being then scaled out to many instances. A typical application could have hundreds of web servers, many tiers of Java servers each numbering in the hundreds or thousands and many different database servers.

This new application architecture lead to the need to trace transactions implemented in Java, .Net and other languages across the tiers of the application systems. This lead to the complete disruption of the APM industry. The legacy solutions which had been acquired by IBM, CA, and HP fell by the wayside, to be replaced by the current market leaders in APM (according to Gartner) who are AppDynamics, Dynatrace, New Relic and CA (CA was added back as a leader this year after a several year absence as a result of heavy investments in producing a second generation APM product).

The Third Phase of APM – Containers, Container Orchestration, and Micro-Services

We are now experiencing another shift in application architecture. This shift is being driven by the following dynamics:

  • Digitization (the desire to implement every business process in software) is creating an infinite demand for delivering new software into production, and an infinite demand to rapidly enhance that software.
  • Agile Development and DevOps were invented as processes to support the above demands
  • Ever more new languages and run times like Pivotal Cloud Foundry and Red Hat OpenShift were invented to ease the deployment and management of software in production
  • Containers (Docker) and container orchestration and management platforms like Kubernetes and Docker Swarm were invented to manage and orchestrate large numbers of containers in production.
  • The ability to run large numbers of containers in a coordinated (orchestrated) manner lead to the ability to further break up applications into micro-services with each micro-service implementing one function of the application leading to easier maintenance of that service and faster enhancements.
  • Micro-Services can be dynamic. They can be instantiated as needed and shut down when no longer needed.
  • Dynamic applications (micro-services) now run on dynamic infrastructure (clouds)
  • The Internet of Things (IOT) is creating an explosion in the number of devices that contain software that will need to be monitored.
  • The world of open source is coming to the world of APM. Open source projects like Coda Hale Metrics and OpenTracing can be used to augment or replace parts of commercial APM solutions.

The above dynamics create a new set of requirements for APM for this new era of distributed and dynamic applications:

  1. Given how quickly a micro-service can be instantiated and destroyed, monitoring must now be nearly continuous. One minute granularity is no longer good enough as a single instance of a micro-service may only live for a few seconds. Modern APM must monitor at the one second level of granularity.
  2. Agents installed in the JVM are no longer viable because if you wait until the container, the JVM and the application exist to install the agent, the entire container may well be destroyed before the install finishes. Rather the instrumentation of the micro-service needs to be dynamically injected into the micro-service as the container and its micro-service are instantiated. Instana and the new Dynatrace product (based upon Ruxit) are examples of products that take this approach.
  3. The Internet of Things combined with breaking applications into 10, 100 or 1,000 micro-services combined with the need to monitor at the one-second level of granularity creates a deluge of time series monitoring data for the back end of the monitoring product to process in real time. This requires that third generation APM solutions have real-time low latency big data back ends based upon time series and stream processing approaches.
  4. The number of things being monitored with frequency creates too many alerts that might or might not actually be problems. This leads to the requirement that AI and Machine Learning be employed to focus the results of the monitoring product into a set of things that the humans should actually pay attention to. AI and ML should also be expected to help drive issues to resolution.
  5. Third generation APM vendors should be expected to support and enhance the open source projects in the APM area that achieve adoption and which build viable communities.

Conclusion

Almost every business now needs to compete on the front of enabling their products and services with software. The shift in application architecture to containers and micro-services is being driven by this business imperative. This radical shift in application architecture will also require a radical transformation of how these applications and micro-services are monitored by APM solutions. The current leaders in APM must now modernize their offerings or face the fate of the first generation of APM solutions. Enterprises should take great care to match the capabilities of their APM vendors with the architectures of their applications.