ServiceNow is a powerful platform. It offers lots of capabilities and features to help users administrate many areas (not just IT). And if users miss some features? Not a problem! You can develop them on your own in Global scope or encapsulate your functionality into the scoped application. In this case study, we will show you a successful network line sizing automation.
How to ensure smooth communication between branches and datacenters
One of our major customers asked us for help with enhancing one of the processes that required a lot of manual work and long delivery times. Imagine a company with many offices, warehouses, and other facilities all over the globe with 3 main data centers:
- one in Europe, also covering some branches in Africa,
- one in Asia, also covering the rest of the Africa branches and
- one in North America, covering also South America.
The customer needed to ensure smooth communication between every branch office and data centers - and of course among data centers themselves - to provide employees with non-problematic usage of applications supporting the company business.
In this situation, it is essential to have a good overview of the utilization of each line. That can help in cases when a new application is about to be deployed and started to be used, or there is hiring in some office and the application will be used by more users. Both cases lead to changed utilization of line available on the site.
Another scenario can be replacing one application with another or just starting to use a newer version of some application since there might be different bandwidth demands each of the applications or application versions require. Then, it is up to network team members to evaluate the situation and make a decision or at least provide a recommendation.
What was the client’s situation before the solution proposed by ConWare?
- Branch offices agenda (location, information about available connection types - MPLS, Internet - with bandwidth allocations, QoS information) existing in ServiceNow
- Basic request for site evaluation – manual input of application demands (protocol/port + in/out bandwidth demands, QoS used etc.)
- Path through other site (system of parent and child sites) to DC where the application runs found automatically
- Total bandwidth demands calculated per site/line in the path calculated
- Request to individual connectivity providers to provide evaluation and conclusion if currently allocated bandwidth is sufficient and it is safe to start to use new application or it is safe if e.g., 20 more employees start to use some application
For example, because of the need to enter application bandwidth demands, creating a new evaluation request requires more than basic knowledge of the application in question. It might also take up to 10 days (agreed max. time) to get some results from providers, in some cases consisting of many dependent sites (sites in path) or one evaluation request containing sites from different regions.
Client’s requirements
- Creation of applications agenda - version, traffic requirements containing protocol/port, information about in which datacenter application is available, QoS class, which connectivity type should be used by the application.
- Application discovery – possibility to create an API request to an external system to provide utilization data between specific source and target IPs. Results are then stored and linked to a specific application and its version.
- Circuit agenda – connectivity type (Primary/Secondary MPLS, Internet, SD-WAN, Leased Line), with bandwidth allocation QoS class setup (40% Business, 20% Voice, 20% Video, 20% Default). One site (branch office) can have multiple circuits.
- Periodical site profiling – enablement of storing site utilization data on daily basis. ServiceNow integration to an external system to request and retrieve it.
- Enhancement of evaluation request – users are able to use the application agenda. By selecting an application, bandwidth demands are inserted automatically, users don’t need to know the specific protocol/ports the application is using. QoS class and connectivity type inserted as well. Site profiling data is utilized to provide results.
Main challenge: considering all possible scenarios
From the beginning, it was essential to fully understand all possible and impossible scenarios of how the connection from the site to the data center is found and working. The scenario was quite often very complex, with setup as follows:
-
Application is using MPLS connectivity type.
Now, on some distant site, that connectivity type was not possible as there was only Internet connectivity type. When finding the route from the site to the data center, Internet connectivity type has to be also on the parent site. Then the parent site needs to have Internet connectivity type available as well.
As the next step, a check must be done if the parent site has an MPLS connectivity type the application could use. If so, then the next connections are done via MPLS. -
One site can be parent to many others.
In this case, when creating an evaluation request, the total needed bandwidth in and out per site is calculated. Previously, the order of the sites didn’t play any role. With the new setup, we needed to take this into consideration, because we needed to know if the site is either a source (client), or is located in the middle of the route, or is a target (server running the application). For example, for sites in the middle, in and out bandwidth demands need to be swapped.
Since data quality wasn’t in a good shape, it was also quite challenging to correctly transform data to a new table structure.
Successful project: timely and flawless delivery
For this six-month project, we cooperated with two other companies. ConWare delivered the ServiceNow part of the solution, while other vendors developed components providing netflow data collection from sources and performing operations like average or percentile calculations. Results are then provided and stored in ServiceNow instance using APIs. The whole solution was delivered on time. All minor issues were fixed during the test phase of the project and till this moment (6 months since production release), we haven’t received any request for a fix.
Added value by ConWare: the app saves time and money
As far as we know, the new functionality running on the ServiceNow platform works without any issues. In situations when a new application is released, the current one is used by more people, or its version is changed, the customer has a very good overview of network utilization almost instantly.
During the development and implementation, we also came up with the idea to use not only stored periodical data for evaluation in case of additional bandwidth demand, but to line utilization data availability in the ServiceNow. That gives the customer a good opportunity to check and compare if some line has too much bandwidth allocated, hence paying too much for it. So, the solution we provided at ConWare can be also used for effective cost-saving. To put it in other words, we always go one step further to provide the client with original solutions.
Do you want to know more details about our application? Drop us a line on info@conware.eu.
Lukáš
Senior ServiceNow Consultant