BMC continues to give assurances that RPD is part of their strategic platform. I agree with you, it was disappointing for it not to be mentioned at Engage.
1 of 1 people found this helpful
It was great meeting you at BMC Engage, and thank you for continued enthusiasm around BMC Release Package and Deployment. I am also a huge fan of this product :-).
I know we talked at the event, but hopefully I can do a better job to help sort out the current product direction.
1. BMC Release Lifecycle Management (RLM) is our suite targeted at managing and automating application releases for Release Managers and Application Release Automation teams. The suite includes BMC Release Process Management (RPM), BMC Release Package and Deployment (RPD) and BMC Application Automation (BAA).
Our goal is to eventually unify the RPM and RPD capabilities into a single unified codebase. For this reason, you will see RPD features making their way into RPM over time. Currently, RPD is better at creating packages and managing application packages (one version of one component). Currently, RPM is better at managing the full release of complex applications across multiple stages of environments. Until the merge of RPM and RPD is complete, I recommend that you use the RLM suite- RPM for your release process and RPD for your application component packaging and deployment.
2. BMC Application Automation (BAA) is just a license included in the BMC Release Lifecycle Management SKU that allows you to use BMC Server Automation's RSCD agents and Network Shell (NSH). Those components are used for connecting to remote targets for application deployments as well as many other use cases like patching and compliance. Because of the flexibility across use cases, strong access controls and proven record in some of the worlds largest data centers; those components are our recommended method for connecting to remote targets. For example, if we have a customer that is using BMC's solutions for Application Release Automation and Compliance, they do not want us to use two agents. For those reasons, the 'legacy' Varalogix bridge is going to be phased out.
BMC Middleware Automation (BMA) is a tool that enables a middleware administrators to manage their configurations at scale across hundreds or even thousands of nodes (ex. WebSphere, WebLogic, Jboss, etc.). The goal of BMA is to increase your ratio of nodes/domains manage per admin with more consistent, agile changes, less errors and faster meant time to repair (MTTR). Typically, middleware admins manually configure one node/domain and then they use BMA to snapshot that configuration, tokenize the configuration, and install it as a "golden configuration" across all the nodes/domains. The BMA drift and compare capabilities can be very useful for identifying, tokenizing and deploying changes as one aspect of an application release. Some of our customers that are using both RLM and BMA combines these capabilities into their release process.
I hope my response helps eliminate at least some of the confusion.
Thanks for the information Jon. How long do we have RPD as a standalone product using legacy agents?
1 of 1 people found this helpful
There is no plan to get rid of RPD as standalone product. As I mentioned, our goal is to gradually add RPD-like capabilities into a combined code base- over the next few years. When this is done, I think there will be compelling reasons for standalone RPD customers to want to migrate.
The legacy RPD agents are a different story. The NSH/RSCD combination has even greater capabilities than the legacy agents and significantly more platform support. Is there a specific reason you would be opposed to moving the agents to NSH/RSCD?
Sound good Jon. Thanks. I'll definitely keep my eyes on RPM. I have no concerns if we ultimately end up with all the features RPD offers today in a tool that also supports release orchestration!
As for why I'm hesitant to move away from legacy agents, I have a couple of points that maybe you can shed some more light on.
- I don't see a compelling reason to use the NSH/RSCD. My team does not play in the server/middleware automation domain. Our server and middleware engineers have their own tools and solutions. We are purely a business application software configuraton management team. We build and deploy applications on existing platforms. The legacy agents are a very small footprint that serves our need. Perhaps there are advantages you can identify for me, given my team's domain?
- It's my understanding that a single instance (install) of RPD (one database) today cannot manage a mix of these agents (legacy and NSH/RSCD). Given we have many environments and hundreds of targets we deploy to, that seems to force me to a single cut over event to use the new agents, without an opportunity to gradually introduce them in my environments. This also assumes I can have these new agents deployed to all target servers in advance of the cut over. If true, is the cut over low risk and easy to manage? Can I easily (automatically) change all Server Bridge configurations in RPD at once, and revert all back at once if necessary?