Solved: Gathering AWS Inventory via Adoption

raaron1 · ‎Apr 30, 2020

Greetings.

A client has implemented the FlexNet agent via adoption within their data center. They have added AWS resources and seek to bring those servers in also. I have yet to fully understand (meeting in the coming days) but would think that we could use adoption from the single beacon that's co-located with the app server. It may be that we stand up a beacon in AWS - TBD.

The documentation (section Planning your inventory beacons in the FNMSInvAdaptersAndConnectorsRef) makes the below comment when discussing push vs. pull. Situations for "push" -- "for the 'remote execution' tasks known as adoption and zero
footprint inventory collection, neither of which you expect to use in a cloud environment."

Maybe it's just the wording but would there be an issue using adoption?

Thanks, Rob

pwesthorp · ‎Apr 30, 2020

Hi Rob, The reason that you would not expect to use push mechanisms (adoption, zero-touch inventory) with cloud instances is because of their transience and addressing limitations (you cannot rely on a newly instantiated instance being at the same address as one you accessed previously). So rather than adoption, best practice is (as described in the section above where you quoted):
"To gather useful inventory from all instances, best practice is to include the FlexNet inventory agent ... in the Amazon Machine Image (AMI) from which your devices are instantiated."

Standard adoption does not easily allow for customization. For all cloud instances, some customization is usually needed, and that's especially so for short-lived on-demand instances (see the comments on Schedule specialization earlier in that chapter).

Also on the issue of whether to use an inventory beacon co-located on their application server, the documentation notes that this "may require balancing questions of security and performance against cost". On the surface, it would seem to me that allowing every cloud instance to directly access the application server within the customer's private network does not seem to take sufficient account of either security or robust network communications. My understanding is that standing up an inventory beacon on a long-life AWS instance, as described in that chapter, may be a more secure and robust solution. But of course YMMV.

HTH
Peter

View solution in original post

pwesthorp · ‎Apr 30, 2020

Hi Rob, The reason that you would not expect to use push mechanisms (adoption, zero-touch inventory) with cloud instances is because of their transience and addressing limitations (you cannot rely on a newly instantiated instance being at the same address as one you accessed previously). So rather than adoption, best practice is (as described in the section above where you quoted):
"To gather useful inventory from all instances, best practice is to include the FlexNet inventory agent ... in the Amazon Machine Image (AMI) from which your devices are instantiated."

Standard adoption does not easily allow for customization. For all cloud instances, some customization is usually needed, and that's especially so for short-lived on-demand instances (see the comments on Schedule specialization earlier in that chapter).

Also on the issue of whether to use an inventory beacon co-located on their application server, the documentation notes that this "may require balancing questions of security and performance against cost". On the surface, it would seem to me that allowing every cloud instance to directly access the application server within the customer's private network does not seem to take sufficient account of either security or robust network communications. My understanding is that standing up an inventory beacon on a long-life AWS instance, as described in that chapter, may be a more secure and robust solution. But of course YMMV.

HTH
Peter

raaron1 · ‎May 01, 2020

Many thanks, Peter!