SBN

Customer Story: Keeping a City of 8.5M Running with Self-Serviceable ADC Automation

About the Customer

Managing the IT infrastructure of an enterprise is hard enough. Managing the IT infrastructure of the largest, busiest city in the USA – a city that ‘never sleeps’ – is a task of herculean proportions. The city’s government-controlled telecommunications department acts as the ISP for over 80 agencies, including traffic surveillance and emergency response units, agencies that are the arteries of the city.

When You’re the Lifeline for 8.5M Citizens, You Can’t Afford a Single Moment’s Rest

Even under normal circumstances, each of the applications in each of these agencies needs to be available 24/7. After all, one blip is all it takes to plunge the city into chaos. The COVID-19 crisis further heightened the need for an always-on digital network – with the city’s guardians off the streets, law enforcement agencies bank on video surveillance systems, and their interfacing applications, to keep a watch on the goings-on. Emergency response units are seeing a surge in requests, engendering improved GPS and VoIP performance.

To meet the above demands on availability and performance, the IT infrastructure has to be robust, agile, and, most importantly, democratized. Each of the department’s different agencies has its own set of applications, tools, and technologies – the underlying infrastructure needs to be consistent and compliant while at the same time being flexible enough to support scaling and modernization.

The Wrench in the Works

The IT arm of the city’s telecommunications department encountered the same problems as any other enterprise, although on a larger scale – that its application and network infrastructure operations were restricted to one team – the network team. So, any application-centric operation, be it monitoring their health and performance, altering traffic flows, or rolling out updates, had to go through the network engineer. The result? Network engineers were overburdened with tickets from the application teams, while the application teams had to endure long wait times.

These delays impacted the functioning of the department at large – from end-user experience to internal processes, tiny lapses in the response began to creep in.

Get a Copy of our Case Study Now!

Other Stumbling Blocks

  • Lack of Centralized Monitoring and Management

Application owners lacked comprehensive visibility into their application objects and performance. Applications were deployed across many environments and involved multiple vendors servicing them, and the application team had to depend on network engineers to log in to each device and get the metrics individually. These metrics then had to be collated, organized, and analyzed to glean useful information – an excruciatingly slow process.

  • The Need to Restart Devices to Manage Them

The department uses F5 load balancers for application delivery, which were managed on the vendor’s platform. Whenever a new device was added to the management platform, it had to be restarted for the platform to connect to it. This need to restart devices each time they were added led to serious service interruptions, contributing to speed and performance deterioration.

  • Manual, Time-Consuming Provisioning of Virtual Servers

The ever-rising end-user traffic and rapid addition of new services to the department required new applications and instances to be created on a daily basis. To meet the demand, virtual servers had to be created frequently on an ad-hoc basis. However, the process of provisioning virtual servers was manual, time-consuming, and error prone. Although virtual servers are essentially an application service, application teams had no control over them, and their provisioning and management once again landed as tickets in the network engineer’s queue.

  • Compliance and Integrity Issues

As different agencies of the department each have their own applications, tools, and technologies, compliance was difficult to impose. Though the department had IT policies, enforcement was painstaking as each of the device configurations and processes in the vast, complicated network had to be manually compared against the accepted standards and rectified in case of deviations. Lack of network integrity and weak policy compliance gave rise to several security concerns and problems during audits.

Building a Democratized, Always-On Network with AppViewX

The results the department saw with AppViewX can be summed up in a few words – a sharp reduction in network tickets, zero wait-times, superlatively high application availability and performance, and uninterrupted services.

Here’s how AppViewX helped the department achieve the above results-

Application-Centric Single Pane of Control

With comprehensive dashboards, application owners can monitor metrics such as performance, traffic flows, and CPU usage. The topology maps display the relationships between various objects pertaining to the application and its services, such as load balancers, firewalls, etc., distributed across vendors and environments, enabling app teams to detect and rectify anomalies themselves quickly. This eliminates the need to log in to each device individually to gather the data, and subsequently, the dependence on network engineers. 

Zero-Touch Virtual Server Provisioning with Workflow Automation

AppViewX enables the creation of automation workflows through its drag-and-drop visual builder, which can then be shared with the application owner with appropriate permissions. Application owners can self-service these workflows to run application-centric tasks such as virtual server provisioning, traffic management during updates, simple load balancer configuration changes, etc. Automation drastically brings down errors and the time spent on manual configuration changes and helps make the infrastructure agile.

RBAC-Enabled Self-Servicing

With granular RBAC, administrators can grant application users device-level and object-level permissions to access maps and dashboards or execute workflows. RBAC also ensures application owners can access or edit only the attributes related to their application, and not others’. For example, the owner of Application A cannot make changes to Application B’s services. This protects the network and applications against unauthorized access, both accidental and intentional.

On-the-fly Management of Devices

AppViewX does away with the need to restart devices in order to add them to the management platform. Engineers could add their F5 devices to the AppViewX inventory and start managing them right away without interrupting their functioning. On-the-fly management of devices puts an end to service disruptions under any condition, and RBAC further helps refine management.

Thorough Compliance Management and Standardization

Network and application teams could ensure configuration compliance and standardization by using AppViewX’s Diff. Checker to detect and remediate configuration drifts. AppViewX provides enhanced governance through policy-based automation across vendors, tools, and environments. It provides pre- and post-validation checks, and allows users to back-up configurations and restore them in case of failure. It also maintains detailed logs of configuration changes of all the devices in its inventory, greatly aiding auditing and governance.

The post Customer Story: Keeping a City of 8.5M Running with Self-Serviceable ADC Automation appeared first on AppViewX.


*** This is a Security Bloggers Network syndicated blog from Blogs – AppViewX authored by AppViewX. Read the original post at: https://www.appviewx.com/blogs/customer-story-keeping-a-city-of-8-5m-running-with-self-serviceable-adc-automation/