What are “Application Dependencies”?
Application dependencies are when IT components and applications rely on another component or application to provide a service.
Why are they important
Knowing the dependencies within your organisation is important for a number of reasons.
1. To protect business critical services from unplanned outages
For example, if you have a dependency between a web server and its files, where the files are stored on a different server. If this server undergoes planned maintenance but you were unaware of the dependency then you could end up with a live web service being affected because you took down the associated file server without providing an alternative that allowed the required files to continue to be accessed.
Now the website now doesn’t work.
2. To assist in migrating services from one site to another
Moving a front end server without moving its associated backend database will cause the application to perform slowly or to simply fail. Applications can consist of many servers and services – authentication servers, proxy servers, web servers, application servers, mediator servers, file servers etc – all related to a single service.
Further separate services can be interrelated – for example if a output from one service forms an input to another service.
Finally – infrastructure services like DNS, antivirus, backup, updates can affect how services behave. For example if you shift a server from one location to another but leave backups being performed by a server at the original location this could potentially bring down your wide area network… or at least give it performance problems.
3. Moving services from on premise to Infrastructure as a service (cloud)
Much in the same way as moving a service from one non-cloud site to another non-cloud site can affect that service and all the interrelated services; the same is true when moving a service to cloud as infrastructure-as-a-service (IaaS). If you don’t identify all the consituent parts of the service and either move them all or understand how they work at a minimum so as to properly appreciate the impact of moving some elements and not others – then you are likely to encounter problems.
4. Moving services from on premise to software as a service
Normally the business case for moving to a SaaS offering is predicated upon releasing resources and staff from caring for the application – but if you don’t know what makes up the application this will not work. To migrate to a SaaS solution you must first understand what makes up your on-premise service and how it interconnects to all your other services and how this will happen when the solution is managed by the service provider.
Which other services need to also move? How will you secure the connection from the SaaS solution back to on-premise? What data do you hold and which other services use that data? If you don’t understand how your application is build and what its dependencies are you will struggle to move it to SaaS successfully.
What to do?
Performing application dependency mapping manually will in general be an exercise in futility. How will you discover the connections and how will you know what they mean?
Let’s suppose you decide to spend nothing and to just look at what rules are in place in your firewall and build a dependency map from that… you’d need specific detailed firewall rules between each server and all other servers, between each server and the internet, and between each server and all the users. To me that sounds pretty unlikely – either you won’t have all these firewalls or your rulebase won’t tell you in detail what the different rules are for specifically.
For example – let’s suppose I discover a connection from server A TCP port 16761 to server B TCP port 445. I can guess that 16761 is a random port, and I can guess that because port 445 is in use its SMB over IP. But this doesn’t tell me why this connection is in use, what is being transferred, how important it is, what will happen if the connection has additional latency, what will happen if it fails etc.
Plus completing application discovery in this manner over 100s of servers, and 1000s of users, over a number of months would be too big a task. A tool is needed.
I hear you ask – why over a number of months…? Because some operations will only take place every 3 months, 6 months, or 12 months so I need ensure I monitor the dependencies over a prolonged period to catch these – or accept some risk.
A few tools
So what tools are available? This rather depends on your destination or how much you want to pay. I’m only going to mention a few of the tools here.
Azure service map
Back in 2015 Microsoft purchased a company called Bluestripe to plug the hole left by it’s lack of a application dependency mapping tool. This tool is now available in Azure in two forms-
Azure Migrate – this migration tool combines the former “Azure Site Recovery” server migration tool with a few other features including the Azure Service Map tool. But its only intended to be used as an aid to successful migration not as a operational management tool.
Azure Service Maps – working with Log Analytics, the Log Analytics Agent and the Dependency Agent, the Azure Service Map tool allows you to model an application based on the connections between servers, processes running and inbound and outbound connection latency and TCP ports. Service Map is a Log Analytics “Solution”.
The Service Map tool can be used by ICT support desks, 1st and 2nd line support to assist in identifying and managing faults in addition to helping define an application in order to successfully migrate it to Azure. But it does have a cost if you intend to use it as “BAU”.
AWS Application discovery service
Part of the AWS Migration Hub is the AWS Application Discovery Service. In fact the two are integrated such that data you collect in the later is available in the former to assist in migration planning.
The tool collects details about your on-premise infrastructure – the servers, MAC addresses, resource allocation and usage – details that are used to correctly size your target AWS environment. But in addition to the using AWS Application Discovery Service agents installed onto servers it maps and records the inbound and outbound network activity for each server. For VMware virtual machines a VMware applicance is available called the “AWS Agentless Discovery Connector” that can map the information about virtual machines without requiring an agent installation in each VM.
The data collected can then be analysed in Amazon Athena and visualized in Amazon Quicksight to identify the dependencies.
VMware vrealise network insight
VMware understand that migrating to cloud is complex and that most organisations have hybrid environments with a mix of physical servers, virtual servers and possibly even servers based in cloud. vRealise Network Insight is available in two versions – an on-premise installation and a cloud based version. In this section we are focusing on the cloud based version.
vRealise Network Insight is designed to help you to plan migrations by identifying what servers, services and applications are related to which other ones in order to group applications together to form migration waves. Data can be entered into the tool in a range of different ways and the solution combines these together to present a unified view on the application portfolio. The tool can also be configured to watch network traffic and identify dependencies between different applications and services along with the bandwidth requirements of applications and recommended firewall rules.
How we can help
Irrespective of whether you are migrating between platforms on-premise or migrating to public cloud it is vital that you understand how your applications are interrelated – which servers and applications need to be moved at the same time in order to avoid unintended downtime. We can help you choose the most appropriate tool for your migration scenario, provide the tool and help you use it collect the relevant information in order to effectively plan your migration appropriately.