Service mapping for hybrid solutions

[Gavin Jolly2]

Recently we had to tell a customer we could not map the application as they had deployed it even though it is a very common deployment pattern. We could not find any way to run a Service Map check when the app has the front end in the cloud and the back end on premises

1. Web application running in Azure
2. APIGEE Cloud API middleware
3. Network perimeter security (Firewall, Load balancer)
4. Web application with APIs
5. SQL and app servers

Any recommendations?

The issues we struck during this project.

1. Could not have a Service Mapping process start on one mid server and finish on another (Azure Cloud, and customer network)
2. APIGEE Cloud has no APIs to support any form of discovery (Had to upgrade to Enterprise to get the APIs and then they did not look at the APIs as deployed. 
   1. Could not build a Static item for Service Mapping to "hook into to", say with incoming and outgoing routes/connections
3. After discovering a web application which had a connection to the Apigee cloud API middleware the map was finished
4. The Azure patterns were so out of date they would not work, could not find the services behind an Azure load balancer - this was another issue but it caused significant issues
5. Could not find a way to manually "join the maps/Services"

[VaranAwesomenow]

Very interesting usecase and it appears to be the future of many of apps as there is more and more adoption towards APIGEE, having said that, did you try to use ApplicationServiceAPI to fill the gaps that you couldnt achieve through OOB approach (pattern based), since its midserver agnostic it should give you the flexibility and still fits into ServiceNow OOB approach.
https://docs.servicenow.com/bundle/tokyo-servicenow-platform/page/product/configuration-management/c...