This is the second of a series of blog posts around the new Mule agent. For an overview of the new Mule agent, be sure to read Introducing the new Mule agent. In this post, I’ll talk about the new agent in relation to the Mule Enterprise Management Console (also known as MMC).
Readers of this post are probably familiar with MMC, which is MuleSoft’s current on-premises management/monitoring solution. The agent is a first step in the development of MuleSoft’s next generation management and monitoring solution. Think of this solution as more than just MMC 2.0. Over the next few Anypoint Platform releases, this agent will unify management and monitoring of Mule ESB, CloudHub, and API Gateway to provide MuleSoft customers with unparalleled visibility and control over their connectivity landscape. And because we’re taking an API-led connectivity approach to developing the agent, it will be highly extensible.
For current MMC customers reading this, don’t worry. We know MMC is a critical part of many enterprise production deployments. MuleSoft will continue to support MMC in its current form, which includes adding features and fixing bugs as needed. We will also continue to support older versions of MMC as long as its corresponding Mule version is supported (e.g. MMC 3.4.2 will be supported as long as Mule ESB 3.4.2 is supported). Furthermore, we will continue shipping new versions of MMC until customers have validated that the new management solution is a suitable replacement.
Note that the name, packaging and delivery date for the new management solution are all still TBD. We’ll continue to update you around the new management solution as more development is done and the release date gets closer.
The new management solution and the new agent
Our primary goal for developing the agent was for our new management solution to leverage its APIs, as shown in the diagram below.
As shown in the diagram, MMC will continue to interface with a Mule runtime (ESB or API Gateway) via the existing MMC agent, and the new management solution that is currently under development will interface with the same runtimes via the new agent. An important detail in this diagram is that the new agent and the MMC agent can coexist (in compatible Mule runtimes), which we hope will facilitate a smooth transition for MMC users to the new management solution.
Comparing MMC vs the new agent
Comparing MMC vs the new agent is not an apples-to-apples comparison. That said, if there’s one thing to keep in mind when looking at the agent in relation to MMC, it’s that the agent should only be used over MMC when APIs ALONE are used for management/monitoring, which is typical in situations where existing third party apps are the primary mechanisms used to manage/monitor Mule instances. Unlike MMC, the agent does not have a graphical UI. If you are looking for a full MMC replacement, that’s only coming later with the new management solution.
We do not believe the new agent in itself can fully replace MMC within an enterprise’s architecture, but we do believe that there are certain use cases where the agent is a superior choice for runtime management in lieu of a full-blown management GUI like MMC, and there are also certain use cases where the agent can complement, or run alongside, MMC deployments. We’ll talk about some of those use cases in a separate blog post.
Learn more about the agent by reading the full Mule Agent documentation, and feel free to post comments within this blog post or in the MuleSoft forum. Thanks for reading, and stay tuned for the next installment of the agent blog post series.
Missed the last post? Check it out here: Introducing the new Mule agent »
