Distributed computing dependency management system

Abstract

The present disclosure relates to a distributed computing dependency management system. Various methods and systems for implementing dependency management for infrastructure are provided. A dependency service manager of the dependency management system includes multiple dependency management system components that facilitate automatic discovery and analysis of data to generate dependency data. The dependency data includes dependencies and subordination relationships of dependency service tenants as tenant services of the infrastructure. The dependency data is generated based on data retrieved by multiple collectors. The collectors from the multiple collectors are agents that retrieve data associated with the dependency service tenants based on corresponding collection time attributes of the collectors. The collectors access the data used to generate the dependency data at one of the following collection times: design time, deployment time, and runtime. The generated dependency data is then stored in a data repository and transmitted to a dependency service interface for users to access the dependency data.

Description

[0001] This application is a divisional application of the invention patent application with an international application date of December 26, 2016, which entered the Chinese national phase on June 29, 2018, and has Chinese national application number 201680077394.8 and invention name “Distributed Computing Dependency Management System”. Technical Field

[0002] Embodiments of the present disclosure relate to the field of information technology, and more particularly, to a distributed computing dependency management system. Background Art

[0003] Large-scale networked systems are common platforms used in various settings for running applications and maintaining data for traffic and operational functions. For example, a data center (e.g., a physical cloud computing platform) can provide various services (e.g., web applications, email services, search engine services, etc.) to multiple customers at the same time. These large-scale networked systems typically include a large amount of resources across the entire data center or multiple data centers in one or more regions across the world. Resources can be similar to physical machines or virtual machines (VMs) running on physical nodes or hosts. Data centers run on hardware (e.g., power supplies, racks, and network interface controllers (NICs)) and software components (applications, application programming interfaces (APIs), SQL databases) that rely on each other for operation. Specifically, services comprising one or more components operate based on dependencies with each other. Services are often managed independently by different teams, often using ad hoc methods, to resolve dependency issues with other components. Summary of the Invention

[0004] Embodiments described herein provide methods and systems for implementing a dependency management system for an infrastructure (e.g., a distributed computing infrastructure). At a high level, dependency management facilitates the automatic discovery, construction, and analysis of dependencies for tenant services in the infrastructure. A dependency service manager of the dependency management system includes multiple dependency management system components (e.g., collectors, standard name providers, and dependency aggregators) that facilitate the generation of dependency data. The dependency data includes dependencies and dependencies of dependent service tenants that are tenant services of the infrastructure. The dependent service tenants are associated with the dependency management system. The dependency data is generated based on data retrieved by multiple collectors. Collectors from the multiple collectors are agents that retrieve data associated with the dependent service tenants of the infrastructure based on corresponding collection time attributes of the collectors. The collectors access the data at one of the following collection times for generating dependency data: design time, deployment time, and runtime. The dependency service manager operates to cross-check the data collected by the multiple collectors and generate relationships between the dependent service tenants and the corresponding dependent and dependent components.

[0005] The generated dependency data is then stored in a data repository and transmitted to a dependency service interface for users to access the dependency data. In an embodiment, the infrastructure includes an on-premises infrastructure for synchronizing the dependency data. The dependency service interface supports providing different views of the dependency data to allow users to access and analyze the dependency data. The dependency data is also accessible via a data graph representation; the data graph representation provides alternative access and functional views of the dependency data. The dependency data presented via the dependency service interface or data graph representation can be further used to perform dependency service operations of the infrastructure.

[0006] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in isolation as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present invention is described hereinafter with reference to the accompanying drawings, in which:

[0008] Figures 1A-1C is an exemplary dependency service interface for accessing dependency data according to embodiments described herein;

[0009] Figures 2A-2B is an exemplary graphical representation of dependency data according to embodiments described herein;

[0010] Figure 3A is a block diagram of an exemplary distributed computing infrastructure and dependency management system in which embodiments described herein may be employed;

[0011] Figure 3B is a block diagram of an exemplary dependency management process flow according to embodiments described herein;

[0012] Figure 3C is a diagram of exemplary artifacts and relationship logic that depend on service tenants according to embodiments described herein;

[0013] Figure 4 is a flowchart illustrating an exemplary method for providing a dependency management system according to embodiments described herein;

[0014] Figure 5 is a flowchart illustrating an exemplary method for providing a dependency management system interface according to embodiments described herein;

[0015] Figure 6 is a block diagram of an exemplary computing environment suitable for use in implementing the embodiments described herein; and

[0016] Figure 7is a block diagram of an exemplary computing environment suitable for use in implementing the embodiments described herein. DETAILED DESCRIPTION

[0017] A distributed computing infrastructure (e.g., a cloud computing infrastructure) can provide build, deployment, and management capabilities for different types of applications and services. A distributed computing infrastructure can include several physical and virtual resources that facilitate the provision of cloud-based computing capabilities. For example, a data center includes many distributed resources, including physical machines or virtual machines (VMs) running on physical nodes or hosts. A data center runs on hardware (e.g., power supplies, racks, and network interface controllers (NICs)) and software components (applications, application programming interfaces (APIs), SQL databases) that rely on each other for operation. A distributed computing platform kernel (e.g., a fabric controller ("FC")) can be used to monitor and manage the distributed computing infrastructure. A distributed computing infrastructure can also include an on-premises infrastructure (e.g., a tenant of the distributed computing infrastructure), to which services and applications are functionally extended for on-premises deployment for performing on-premises operations.

[0018] Typically, services comprising one or more components in a distributed computing infrastructure operate based on dependencies with one another. Services are often managed independently by different teams, often using ad hoc approaches to resolve dependencies with other components. Furthermore, some teams operate services running in virtualized environments and may be unaware of dependencies on physical resources (e.g., network equipment, power equipment, or generators). Determining which dependencies exist, communicating dependencies, and resolving dependencies can present challenges for a distributed computing infrastructure using different approaches to dependency management. Therefore, a comprehensive system for configuring, identifying, and communicating dependencies between distributed computing infrastructure components can improve the assessment, understanding, and reliability of a distributed computing infrastructure.

[0019] Embodiments of the present invention relate to efficient methods and systems for dependency management. A dependency management system can be implemented as a service or application (hereinafter referred to as a "dependency service") in a distributed computing infrastructure. At a high level, dependency management facilitates the automatic discovery, construction, and analysis of dependencies for tenant services in the infrastructure. A dependency service manager of the dependency management system includes multiple dependency management system components (e.g., collectors, standard name providers, and dependency aggregators) that facilitate the generation of dependency data. The dependency data includes dependencies and dependencies of dependent service tenants that are tenant services of the infrastructure. The dependent service tenants are associated with the dependency management system. The dependency data is generated based on data retrieved by multiple collectors. The collectors from the multiple collectors are agents that retrieve data associated with the dependent service tenants of the infrastructure based on corresponding collection time attributes of the collectors. The collectors access the data at one of the following collection times for generating dependency data: design time, deployment time, and runtime. The dependency service manager operates to cross-check the data collected by the multiple collectors and generate relationships between the dependent service tenants and the corresponding dependent and dependent components.

[0020] Dependency data can be leveraged for dependent service operations. Advantageously, the generated dependency data enables validation of the dependency management system's declarative service dependency model, alerting on missing dependencies, suppressing notification noise, and other operations such as aiding incident impact analysis. Analysis services (i.e., validating the declarative service dependency model, alerting on missing dependencies, and suppressing notification noise) can further be used to validate and extend each other. Dependency data further helps developers understand dependencies and prioritize service recovery by introducing recovery paths and integrating with recovery workflows.

[0021] The specific services and components supported and discovered by a dependent service can be referred to as a dependent service tenant. A dependent service tenant can be associated with an administrator, owner, operator, or client of the dependent service tenant. A dependent service tenant can be implemented as one or more instances of a dependent service tenant. A tenant name can be associated with a dependent service tenant; however, the tenant name does not necessarily have to be a globally unique identifier (GUID), but rather a more meaningful name.

[0022] Throughout this disclosure, several abbreviations and shorthand notations are used to aid understanding of specific concepts regarding the associated systems and services. These abbreviations and shorthand notations are intended to help provide a simple method of conveying the ideas expressed herein and are not meant to limit the scope of the invention.

[0023] ALMap application layer mapping - static service layer order

[0024] (Build Time) Statement

[0025] CS Config Repository - Repository for configurations / settings

[0026] DNS Domain Name Service

[0027] FC Fabric Controller

[0028] FMA Fault Model Analysis - Design Time (Statement)

[0029] Dependency Graph

[0030] MA Monitoring Agent - an agent deployed within the service

[0031] MDS Monitoring and Diagnostic Services - analysis services for monitoring and diagnostic data

[0032] SVD Service Model Definition - Design Time

[0033] TFS Team Foundation Server

[0034] VIP virtual IP address

[0035] The dependency management system may support a graphical user interface that facilitates access to and interaction with the features and functionality supported by the dependency system. Dependency data is accessible via a graphical representation of the data. Dependency data may be generated and stored in a data repository and transmitted to a dependency service interface for users to access the dependency data. Dependency data may be further provided via an API (application programming interface) for utilization by other services (e.g., an alarm suppression service may plug into the dependency data API to suppress alarms from services that depend on a failed service). In an exemplary embodiment, the dependency management system may include a web front end ("FE") that provides users with the ability to visualize both the dependencies for a given dependency service tenant and the dependent (affected) services of the dependency service tenant. The dependency management system discovers components or services within components that the dependency tenant service depends on, along with other dependencies. For example, if the dependency service tenant depends on storage, the dependency service further identifies and exposes the storage account and certificates associated with the dependency service tenant.

[0036] The dependency management system supports different types of viewing experiences to provide access to dependency data. The dependency management system can transmit dependency data to a dependency service interface generated on a display. The dependency management system can also support a data graph representation of dependency data, as discussed in more detail herein. Figures 1A-1C, an exemplary dependency service interface 100 (e.g., a portal) is provided. The dependency service interface 100 can be a portal for communicating information configured and implemented via a dependency management system. The dependency service interface 100 can support optional views for presenting and accessing dependency data. Within each view, a user can browse a series of dependency information, aggregating and sorting dependencies (and resources). The views aggregate common services; however, the user should be able to see individual service dependencies. As an example, a portal can include two views to present dependency information: a "Dependencies by Service" view and a "Dependencies by Location" view. The dependency by service view can operate as a logical view that helps users investigate the impact of service failures. This view is targeted at component owners or single service failures. Figure 1A As shown, a selectable drop-down menu 102 can be provided via the dependency service interface 100 to select dependencies by service view. Selecting dependencies by service populates the dependency information portion 104A of the dependency service interface 100 with dependency information for the services (e.g., Tenant_Service_Alpha; Tenant_Service_Beta; and Tenant_Service_Charlie). The dependency service information can be provided in a tree-like hierarchical structure (e.g., Tenant_Service_Beta_02 112 shown in the tree-like hierarchical structure under Tenant_Service_Beta).

[0037] The dependency view by location can be operated as a physical view, which helps administrators investigate the impact of physical location (such as data center loss) or logical location (such as update domain or fault domain). Figure 1B As shown, a selectable drop-down menu 102 for selecting a dependency view by location can be provided via the dependency service interface 100. Selecting the dependency view by location populates a dependency information portion 104B of the dependency service interface 100 with dependency information for services based on location (e.g., LOC_Alpha; LOC_Beta; and LOC_Charlie).

[0038] The dependency management system supports different types of dependency exploration experiences to perform analysis on dependency data. Dependency analysis is characterized by finding one or more services of interest. Thus, to fully support dependency exploration, the following exploration capabilities are made available via the dependency management system: In an exemplary embodiment, with reference to Figure 1C, the dependency service interface 100 includes a dependency search bar 110 that supports identifying dependency information for the searched service. The dependency information may further include details of a dependency service section 114 that populates the incoming and outgoing relationships in the corresponding incoming and outgoing relationships sections 116 and 118 of the dependency service interface 100. As an example, a user may search for a specific tenant by name (e.g., Tenant_Service_Beta_02 110B) and dependency information including a list of tenant services that depend on the searched Tenant_Service_Beta_02 (i.e., incoming relationships) and a list of tenant services that generated the searched Tenant_Service_Beta_02 (i.e., outgoing relationships). The user may search for a collection of services by name. The user may then explore tenants by location or hierarchy.

[0039] The dependency management system supports different types of dependency annotation experiences to perform analysis of dependency data. The dependency management system is configured to detect and annotate each dependency with the appropriate service name and resolve all dependencies. There may be missing links or failures in resolving dependency names, such as external services of utility machines and infrastructure. The dependency management system provides a way to define new service instances and one or more service grouping rules. The component team (which owns the service) can annotate the dependency model (such as control plane, operation plane, and data plane) and edge directions. The dependency management can store this information and apply it to all instances of the tenant service.

[0040] The dependency management system supports a portal (e.g., a front-end website) to view dependency information, which can be hosted on-premises and / or in the cloud. The dependency data for the website can come from SQL (SQL Azure or local SQL with automatic failover) to ensure that the website is always available. The website can be implemented to ensure high availability. It is envisioned that a data graphical representation of the dependency data is accessible as part of the portal or independently of the portal. The dependency management system further supports a web-API that can be accessed programmatically to retrieve dependency data for a given dependent service tenant.

[0041] A data graph operates as a graphical illustration of dependency data that provides a visual representation of the dependency data for further analysis. For example, a user can download a complete graph or a portion of a graph as a file for detailed analysis. The data graph representation can be based on an extensible markup language representation of a directed graph. For example, a data graph can be in the Directed Graph Markup Language (DGML) file format that allows a user to interactively browse the dependency graph via a portal or other application to understand the underlying links that the analysis has detected. Applications that support viewing data graph representations can support different types of modes to allow flexibility in viewing data graph representations. For example, for larger graphs, different modes can provide an aggregated view of the dependencies.

[0042] As an example, Figure 2A and Figure 2B A data graph representation of an exemplary dependency management system is illustrated. Specifically, Figure 2A is a partial graphical representation of several different dependent tenant services, including their dependencies and subordination relationships. Figure 2A The data graph in includes dependent tenant services 202A, 204, 206, 208, 210, and 212. Links (e.g., link 214A) show direct dependencies and facilitate analysis to understand the activities between Rack_IP_01 and Store_Web_01_01. Services and links can be further annotated to provide additional details within the data graph view. Figure 2B In , alternative views of the data graph can provide access to dependent data. For example, Figure 2B Tenant_Service_Alpha (202B) is included that corresponds to Tenant_Service_Alpha (202A), and the dependencies and subordination of Tenant_Service_Alpha are illustrated in another view.The embodiments described herein contemplate other variations and combinations of data graph views of dependency data.

[0043] Reference Figure 3A , embodiments of the present disclosure may be discussed with reference to an exemplary distributed computing infrastructure 300A as an operating environment for implementing the functionality described herein of a dependency management system 300. The dependency management system 300 includes a dependency service manager 310, a plurality of collectors 320 (320A, 320B, 320C, and 320D), a standard name provider 330, a dependency aggregator 340, a dependency database 350, and a front end 352.

[0044] As used herein, a system refers to any device, method, or service or combination thereof. A system can be implemented using components that are hardware, software, firmware, dedicated devices, or any combination thereof. A system can be integrated into a single device, or it can be distributed across multiple devices. The various components of a system can be co-located or distributed. The system can be formed from other systems and their components. It should be understood that this arrangement and other arrangements described herein are set forth only as examples.

[0045] Having identified various components in a distributed computing environment, it should be noted that any number of components may be used to implement the desired functionality within the scope of the present disclosure. Figure 3A The various components in FIG are shown with lines. Figure 3A Some components of the system are depicted as single components, but the description is exemplary in nature and quantity and is not to be construed as limiting all implementations of the present disclosure. The dependency management system functionality can be further described based on the functions and features of the components listed above.

[0046] The various functions that are described herein can be performed by hardware, firmware and / or software.For example, various functions can be performed by the processor of the instruction stored in the memory.

[0047] In operation, the dependency service manager 310 of the dependency management system 300 supports the analysis pipeline and utilizes the data in the defined streams to appropriately optimize the dependency data. Multiple collectors 320 are used to retrieve data used in the analysis and generation of dependency data. The collectors are configured to retrieve information or data about the service. The goal of the collector is to collect information at design time, runtime, and deployment time. The collector can be associated with a collection time (e.g., via a collection time attribute) so that the collector retrieves data based on a specific collection time. The collector can also annotate any collected data at the time of collection to provide a historical view of the collected data.

[0048] There are several different types of collection times or phases that multiple collectors 320 can support. Design time collections support understanding the dependencies between modules and service types (for example, the use of client libraries or common libraries). Design time collections can include static dependency analysis, layer mapping, and fault model analysis. Static dependency analysis refers to techniques for determining the dependencies between program binaries. Static dependency analysis is performed by analyzing the binaries used, referenced, or included in the software package. These dependencies indicate dependencies on services, rather than dependencies on specific instances of services. Layer mapping refers to grouping services into a hierarchical structure that allows for proper layering between services (for example, lower-level services do not depend on higher-level services). Layer mapping can support validating data graph representations and ensuring proper design. A layer map is a model of the dependencies between program binaries and may not be an exact representation. A fault model is a template that describes the various ways in which a program may fail at runtime and the impact of these failures on execution. Fault model analysis is a manual document design for dependency layering to show how failures in one or more dependencies propagate through the system. For example, a dependency can be modeled on SQL as non-critical, meaning that a failure in SQL should not be an inherent failure. For that matter, any analysis should not consider a failure in the SQL component as a possible cause of a service failure.

[0049] Deployment-time collection (e.g., a name resolver) supports mapping specific deployments to service types (e.g., the Tenant_Service_Alpha_01 instance is part of the logical Tenant Service_Alpha) and remapping names (e.g., deployment GUID to name). Deployment-time collection also supports downloading and parsing deployment artifacts to collect statically declared dependencies. Statically declared dependencies can include specific instantiations of dependencies from a first service to a second service, or from a first service instance to a second service instance. For this purpose, if multiple instances exist, several separate dependencies can be inferred. Static design-time tools may only provide dependencies at the service level, while deployment and runtime tools provide dependencies at the service instance level. Deployment-time collection further supports physical inventory of clusters and logical inventory of virtual machines and Internet Protocol addresses (VM / IP). Deployment-time collection can include TFS and datacenter settings (e.g., datacenter.xml files). Runtime collection supports discovering service dependencies while the services are performing operations, at least in part based on network traffic between them. It is contemplated that communication between services can be direct via APIs or indirectly via intermediary components such as data repositories or event systems. Runtime collection may include tenant configuration (SVD) and distributed computing infrastructure events. The dependency service manager 310 may operate to cross-check data or dependency information in a dataset (e.g., table) populated by the collector. The dependency service manager 310 generates relationships between tenants and resources.

[0050] like Figure 3A As shown, the dependency service manager 310 operates with multiple external components. A data repository (e.g., dependency database 350) can store dependency data or dependency information and support data processing functions supported by the service, and a front end 352 can communicate with the data repository and support transmitting information for display via a display. The data repository can operate based on an API to provide the functionality described herein. In an embodiment, the distributed computing infrastructure may include an on-premises infrastructure 354. The on-premises infrastructure can be used for clients of the distributed computing infrastructure, remote infrastructure for accessing dependency services, or high availability and disaster recovery infrastructure for external deployment. The on-premises infrastructure may include an on-premises dependency database 356 and an on-premises front end 358, wherein the on-premises database is synchronized to contain the latest information of the dependency data, and the dependency data is transmitted via the on-premises front end.

[0051] Continue to refer Figure 3A, the standard name provider 330 is responsible for associating different naming conventions across services into a normalized form. The standard name provider 330 component can operate to obtain input data from different types of agents (e.g., runners) and output a standard name. In one exemplary implementation, the standard name provider 330 uses a workflow that includes the following: the standard name provider 330 receives a request from a collector, and the request from a specific type of collector queries the standard name provider 330 using the data collected by the collector. The standard name provider 330 then outputs the standard name of the target dependent service tenant; and the collector uses the standard name to update the metadata information of the dependent service tenant. The metadata information can be provided via the dependent service interface, as discussed in more detail herein.

[0052] The collector can retrieve data items that are used to request a standard name from a standard name provider. The collector can retrieve different types of data items for a specific service. One or more of the retrieved data items can be used specifically to find each type of collection. For example, in Table 1 below, Table 1 shows different collector types and collected data (e.g., input data) for retrieving standard names. The highlighted data items can be used to find in order to obtain the standard name. The MDS collector can use the TenantID, the SVD collector can use both the TenantID and the VIP, and the DNS collector can use the VIP and the timestamp.

[0053]

[0054] Table 1

[0055] In this regard, the standard name provider operates to look up standard names based on data provided by the collector. The standard name provider can use different data structures for lookup purposes to facilitate finding standard names. In an exemplary embodiment, the standard name provider 330 uses a table (e.g., a standard name table). In addition to using the standard name table for lookup and logic, the table or corresponding data structure for the lookup and logic can also be used for service tenant and role dependent lookups.

[0056] An exemplary standard name table is shown in Table 2 below. The standard name table can be configured to allow duplicate records (e.g., the same combination of name and type). With this configuration, dependent services can provide different views of the same dependent service tenant from the perspective of different runners. For example, tenant WaTaskSN1 is upgraded with a new VIP 200.1.4.6 instead of 200.1.3.5. The collector of SVD has this upgrade information and inserts a new record (e.g., VIP|200.1.4.6|WaTaskSN1|2013-07-04 11:05:17|), as shown in Table 2 below. The timestamp column can indicate the freshness of the data. Based on this, garbage collection or cleanup logic can be implemented to delete records maintained by the daemon thread. The search logic is based on a combination of kind and value, where the combination of kind and value is advantageously unique.

[0057]

[0058] Table 2

[0059] Once the SVD runner gets the standard name, it can update the metadata in the table "TenantMetadataEntities". For example, the table "TenantMetadataEntities" can look like Table 3:

[0060]

[0061] Table 3

[0062] The dependency management system 300 may also support an artifact table that stores multiple objects defined in the dependency management system. An exemplary artifact may be a component of a dependent service, where the properties of the component are captured in the artifact table. For example, as shown in Table 4, if the component name is WaTask, the corresponding properties of WaTask may be populated in the table. In particular, the "RelativePath" column in the artifact table may be a fully qualified name, and uniqueness may be enforced on this column.

[0063]

[0064] Table 4

[0065] The dependency management system includes several different types of collectors. Collectors can be deployment time, design time or runtime based collectors. Several collectors in each category can be further specified as MDS related collectors, standard name collectors, MDS dependent collectors and SVD based collectors. In particular, one or more runtime based collectors may include: MDS related collectors (e.g., standard name collectors, MDS dependent collectors), SVD based collectors. MDS related collectors can provide a baseline information set for runtime dependency collection. Collectors running within MDS can be completed using different platforms or services (e.g., runners, watchdogs, plug-ins, rules or embedded services) as needed.

[0066] refer to Figure 3B , Figure 3B 3. The data aggregation mechanism implemented using the dependency service manager is shown. At a high level, the data aggregation mechanism includes a name provider aggregator 360A and a standard name resolver 360B, a dependency analyzer 370, a network data resolver 380, and symbolic network data 386. The above components are operatively coupled to a dependency aggregator 390, which communicates with a dependency database 392 and a front end 394. In combination, the components support dependency aggregation and dependency data communication in the dependency management system.

[0067] The name provider aggregator 360A is associated with multiple standard name collectors (e.g., data services 362, event tenants 364, deployment events 366, data center monitors 368). The standard name collector can operate as a first-tier collector. The first-tier collector uses various types of information to build IPs (VIPs or DIPs) to stabilize dependent service tenant name mappings. The standard name service provides a stable platform to normalize name and dependent service tenant information for any further association or annotation. In one embodiment, the standard name collector can be implemented as a runner (e.g., MA list, CS) and rules (e.g., event processing) to generate a stable list of names and a current set of IP to standard name mappings.

[0068] The Standard Name Collector monitors different types of events. For example, the MDS monitors agent, hardware and software components, front-end, and tenant deployment and update events. This provides a list of known dependent service tenants and their current VIP assignments for dependency resolution. The CS Collector monitors data center inventory changes (by monitoring CS changes) and assigns names to hardware entities such as clusters, racks, power distribution units, top-of-rack switches, etc. These items also allow for future construction of physical views and assignments.

[0069] The second layer of collectors may include an MDS dependency collector. The MDS-based collector updates the dependency graph by converting raw network events (e.g., Windows socket events) into symbolically stable versions. The network data parser 380 may operate as a filter and utilize a standard name provider to resolve a specific IP address to a service dependency, triggering Winsock / DNS events and causing service-to-service dependencies to be updated as the event is processed. Figure 3B As shown, the MDS dependency collector includes network specifications 382 (e.g., Winsock / DNS) and a network naming system 384 (e.g., a DNS service), which operate in conjunction with a standard name resolver 360B (i.e., dynamic name resolution information) to update dependency data based on network events. In this regard, the network data resolver 380 aggregates data from specific machine instances, thereby providing an aggregated view of dependencies rather than individual machine information. The network data resolver 380 operates to provide a mapping of names (e.g., account.blob.storage.cloud-service.com) to IP addresses. In this regard, the network data resolver 380 provides more granular information of specific storage accounts (or other names) to IP addresses to enable association at a granular level and between dependencies and services through an intermediate storage account or other event system or mechanism. For example, if service A and service B both use the account ABQueue.queue.cloud-service.com, the dependency service system therefore provides information that services A and B depend on queue.cloud-service.com and that services A and B depend on each other. Although services A and B may not communicate directly.

[0070] An SVD-based collector (e.g., service model definition 372) can operate based on a service model definition to collect data for generating dependency data. As background, a service model can refer to a template that can be used to create a service instance and includes several different elements (e.g., services, roles, groups, channels, topologies, and hosting environments).

[0071] Service: A structured collection of roles, groups, and channels that describes a type of service. The service exposes a set of configuration settings (which must be bound to specific values for deployment), a set of input interfaces (which constitute its contract), and a set of dependencies on other service contract interfaces.

[0072] Components: Each component is independently scalable, which can be a role or a group. Roles: Each type of component within a service, programmatically, is designed to be instantiated multiple times. Groups: A collection of other groups, roles, and channels. The smallest group is a role. This enables instantiation of a predefined set of roles and channels.

[0073] Channels: Establish connections between groups and are associated with instances in various ways (e.g., load balancers, stateful and stateless switch channels).

[0074] Topology: A description of the structure of a service (groups, roles, channels and associated interconnections, affinities between roles, etc.).

[0075] Hosting environment: The runtime required by the role (e.g., a specific OS SKU).

[0076] Each tenant of a distributed computing infrastructure can be created or updated using a corresponding SVD file, which contains the service model definition of a service and some settings that imply references to other services. SVDs and operational modes (especially when specified or standardized) can be leveraged through the use of heuristics and advocacy of appropriate guidelines. In this regard, the service model definition can include objects within the definition, which can be identified by a collector and then used to generate dependency data. The dependency collector can discover most dependencies before the dependent service tenant actually runs. Identifying dependency data based on the SVD can be based on one or more of the following: the SVD's input endpoints; the SVD's specification, which declares the input endpoints for reference by other services; the setting's name follows a well-known naming convention; and the setting's value matches a well-known pattern (e.g., a DNS name). In one example, the collector can use an XML representation to generate dependency references to data. Thus, the collector can resolve a storage account (storage_account_alpha) to a specific VIP (IP_storage_account_alpha) and the source of the dependency. The overall dependency can include dependencies pointing to storage components and the names of the storage components.

[0077] Continue to refer Figure 3B, a design time collector (e.g., design time collector 374) operates to capture the intent of a user (e.g., a service administrator) using a symbolic representation. The symbolic representation allows for more powerful inferences from runtime dependencies (non-accidental) and detection of dependencies that are not always in use. The design time collection model allows for more properties, including: data flow direction, FMA planes, priority of business impacted dependencies, assumed design time dependencies (e.g., front end depends on location services, storage infrastructure, operating hardware or software infrastructure, or SQL server and services). The design collection model can be represented in XML. In particular, the representation of the design time collection is indented to capture information provided by the developer and prioritize dependencies discovered at runtime. Multiple collectors are used to convert other dependency tracking tool information (e.g., LayerMap, ALMap, package analysis) into a common format. LayerMap can refer to the declarative layering between parts of the software stack to ensure the correct pattern of references. LayerMap can be used within the operating system to ensure that code in higher parts of the operating system only references lower applicable parts and that there are no references in the other direction (i.e., from lower to higher). ALMap refers to a design for FMA that documents a layered graph across services within a cloud operating system, rather than a traditional OS. Package analysis can refer to taking an existing package (e.g., NuGet, cspkg) and opening its contents or dependency list to understand which other services can be leveraged. The benefit of a design-time collector is that it is generally less noisy and requires low processing cost.

[0078] Referring to the Deployment Collector, the Deployment Collector is designed to monitor deployment information so that additional metadata about the deployment (when, where, who) can be obtained and to trigger refreshes of parsing logic to obtain immediate updates to the data. The TFS Collector automatically enumerates the dependencies and sub-dependencies of the distributed computing infrastructure from TFS records. The TFS Source Code Manager includes automatic building of code and other features. The TFS Collector data helps to categorize tenants into service groups and associate them with component teams. The CS Collector enumerates configuration data stored in the CS configuration repository to collect the current settings for deployment (symbolic rather than specific) before the deployment transformation. It can also collect hardware location / IP / allocation to map from specific hardware / VM to cluster information. The storage of this information in CS is only an exemplary implementation and is not meant to be limiting. In another exemplary embodiment, the data can be stored in other data repositories or data structures, such as a production hardware management service.

[0079] Reference Figure 3B, the dependency aggregator 390 is operationally coupled to the standard name resolver 360B for dynamic name resolution, symbolic network data 386, and the dependency analyzer 370 that provides service model definitions and design time collector data. During the aggregation process, the dependency aggregator retrieves data from the collector and stores the dependency data in a dependency database 392, which supports the transmission of the dependency data to the front end 394. The dependency database 392 can also support the transmission of dependency data to a Web-API service to enable programmatic access to retrieve the data to enable automatic recovery operations, rather than displaying the data on the portal for users to resolve. It is envisioned that the dependency database 392 and the front end 394 can be synchronized with the on-premises infrastructure. Many core components support multi-tenancy, which results in the core components initiating network traffic on behalf of the dependency service tenants.

[0080] Table 5 is an illustration of the different types of collectors. The following table further summarizes the data collected from each of the above collectors:

[0081]

[0082]

[0083] Table 5

[0084] The symbols [DEPENDS_ON] indicate dependency—a coupling in which one object operates based on the functionality of another—and [CONTAINED_IN] indicates inclusion—when a particular item is part of a larger concept. For example, a blade is part of a rack, which is part of a data center. A role can be part of a service.

[0085] The dependency management system also supports manual editing. While most dependency information can be automatically inferred and associated using the components described herein, users still need to modify and annotate information. To this end, the dependency service interface (e.g., portal) supports additional editing experiences. For example, component teams can upload design dependencies through the portal or the underlying data service.

[0086] Advantageously, the component team can document all service references so that services are appropriately categorized. When there are runtime-detected dependencies, component team members can define the direction of the FMA planes and flow edges. The dependency management system can also operate to capture input in a central location. Capturing input in a central location ensures that the editing experience for service owners is smooth. Component teams can develop review processes so that changes are reflected back to the component team's source code and dependencies are appropriately advocated.

[0087] For example, the dependency service interface via the portal may further enable the user to associate unresolved communication targets with services or appropriately classified nodes like internal DNS servers. The dependency management system aggregates several sources to generate a dependency graph that is updated regularly. Different collectors retrieve and transmit data from several sources to collect information about platform tenants, group them into services and associate them with component teams. The collectors are configured to collect information about distributed computing infrastructure from various sources (code, configuration, runtime and deployment information), which includes cloud computing platforms and on-premises infrastructure. The aggregated data can be stored in multiple locations for high availability in disaster recovery (DR) situations and maintained within reasonable freshness at all locations. The dependency management system 300 operates to monitor the staleness of any data to ensure that it is providing a view that is consistent with the real world.

[0088] The dependency management system 300 also supports a reliability and maintenance framework. The dependency management system 300 can include a recovery dependency service UI. Recovery dependencies can be redundant to provide information independent of potential failures. In one embodiment, the recovery dependency service is located on-premises and within the cloud computing platform to provide redundancy for local and regional failures. The dependency management system 300 can utilize synchronization technology to ensure that both locations are kept up to date within a reasonable time.

[0089] Advantageously, the processing pipeline is located within a cloud computing platform to leverage the scalability and low-maintenance nature of the cloud environment. Multiple collectors access resources as part of the existing pipeline (e.g., CS replication, cloud computing platform analytics). The processing pipeline leverages existing monitoring technology (MDS) to monitor health, alert on pipeline issues, and monitor pipeline KPIs.

[0090] A dependency management system can support a dependency data layer. As described above, the dependency data layer can be implemented based on a dependency graph or other graphical representation. The dependency graph or data graph can include nodes and edges associated with the failure recovery mechanism implemented via the dependency management system. In an embodiment with a dependency graph, the nodes in the dependency graph are the units of recovery operations and dependency display for operators or developers. Some of the main nodes of interest are service instance (tenant) endpoints and utility machines (e.g., jump blocks to bootstrap services). Because recovery actions need to be presented in a human-manageable manner, the granularity of the recovery graph typically displays artifacts at the dependency tenant level. Smaller resources (e.g., storage devices, machines) can be highlighted for potential recovery actions, but are not required for full rotation options. The edges of the graph are directional; the direction of information flow is critical to the recovery order. The edges of the graph can contain failure models for services, such as the runtime plane, management plane, monitoring plane, or control plane. The edges contain weights that reflect the importance of the link (a first-order approximation would be traffic volume, but other measures can also be used).

[0091] The dependency data layer also includes a node naming mechanism. Nodes in the graph can be configured with global IDs that follow a standardized taxonomy. This approach can be used to identify nodes hierarchically. The hierarchy can be based on logical service ownership or physical location. Furthermore, nodes can be identified by a convention hierarchy, such as storage account access: component / tenant / account name / DNS name; tenant: component / tenant; role instance: component / tenant / role name / role instance; and blade: datacenter / cluster / rack / blade. By convention, nodes (components, tenants, roles, binaries, and source / configuration files) can have stable Uniform Resource Identifiers (URIs). The URI segments contain the component name (ComponentName), artifact kind (Kind), and artifact relative path (RelativePath). Relationship edges can still have detailed versions, so clients can selectively merge information. The dependency data layer can be further presented in a graphical representation (e.g., a dependency graph). The dependency graph can be used for batch uploads and end-user browsing scenarios. Information can be encoded in various formats to address functional and performance requirements for different scenarios.

[0092] The dependency data layer also includes artifacts / relationships that capture common data contracts to exchange dependency information. Figure 3C As shown, the exchange of dependency information can be based on a dependency graph logical format between artifacts and relationships (e.g., artifact type 302 and artifact 304, and relationship 306 and relationship type 308) and their corresponding attributes. Various services can exchange dependency information in binary files, XML, or other formats as appropriate.

[0093] Continuing with the reference to the graph representation supported via the dependency data layer, nodes and edges can carry a set of properties, with some well-known properties indexed for faster searching. The following are example labels with user-friendly names. Category is used to categorize nodes or links and simplify the search experience. Component Name (ComponentName): The logical name of the service. Relative Path (RelativePath): The unique path identifies the component and node within the category. Weight helps clients sort information by importance. LastUpdateTime is used for the last time the information was updated, so collectors can cache old information, perform incremental updates, and retire old records. Examples of categories, component names, and relative paths are shown in Table 6 below.

[0094]

[0095]

[0096] Table 6

[0097] The dependent data layer can provide additional data services that can query properties like the following. Each type of node can have a different type of property set, such as a service node has a deployment id, service model, etc. The primary storage device for the graph can be a SQL data source, and the database is backed up in the internal deployment to provide disaster recovery availability. In an exemplary implementation that is not meant to be limiting, the dependent data layer can use the Entity Framework to map the entity model to a table in the SQL database to simplify maintenance. The dependent data layer can also provide for uploading / downloading slices of the graph to files in xml / dgml / etc.

[0098] The dependency management system 300 can provide support for indirect dependencies. Additional dependency processing can be done to detect indirect dependencies between dependent service tenants. For example, an indirect dependency can refer to a dependency that uses storage, service bus, SQL as a communication channel. In this regard, the dependency is not just for one service on the "channel" (the service that provides communication - such as storage), but also between two services. These dependencies are more difficult to detect because there may not be direct communication between the two services. In this case, the communication channel (storage) will utilize the same account / queue / table name, and both services will read / write to these locations. By using dependency analysis for the exact account, it is possible to infer such a dependency by finding the same account that is utilized by multiple services. The indirect dependency discovery mechanism can detect collaborative dependencies between two dependent service tenants. Automated analysis can mark these dependencies for further processing, so component teams may be asked to declare them.

[0099] The dependency management system 300 can also support normalization. For example, if the dependency management system used raw dependency service tenant names like in Fabric, the dependency data layer would have to perform unnecessary operations with fragile bindings. The dependency management system provides a mechanism to standardize common dependency service tenant names in a distributed computing environment. Data can be appropriately aggregated to underlying logical entities that reflect service names and scaling unit names. Naming convention guidance can be provided to component teams so that dependency analyzers can automatically identify stable names for their dependency service tenants.

[0100] Now go to Figure 4 , a flowchart illustrating a method 400 for providing dependency management is provided. The method can be performed using the dependency service manager described herein. Initially at box 410, data is received from a plurality of collectors. The collectors access the data based on a collection time attribute associated with the corresponding collector, the collection time attribute being selected from one of the following: design time collection; deployment time collection; and runtime collection. The collectors retrieve and update data for dependency service tenants based on the corresponding collection time attributes. Design time collection includes identifying dependency information provided by a developer that supports identifying dependencies and subordination relationships of dependency service tenants. Deployment time collection includes mapping deployed services to dependency service tenants based on deployment operations of a distributed computing infrastructure that monitors the dependency management system. Runtime collection includes identifying dependencies of the dependency service tenant when operations of the dependency service tenant are being performed based at least in part on network traffic transmitted between components. In an embodiment, at least a portion of the data is transmitted to a standard name provider that uses a portion of the data to look up or generate a standard name for the dependency service tenant.

[0101] At block 420, data collected by multiple collectors is analyzed to cross-check and generate relationships between dependent service tenants and corresponding dependent and subordinate components. The analysis may include processing the data from the collectors and then generating dependency data. At block 430, upon analyzing the data, dependency data is generated, the dependency data including dependency and subordinate relationships associated with the dependent service tenants of the dependency management system. Generating the dependency data is based on implementing a dependency aggregation mechanism that operates to retrieve data based, at least in part, on a service model definition and heuristics defined to identify dependent service tenants based on the service model definition. Generating the dependency data is also based on implementing the dependency aggregation mechanism using a first-tier collector for constructing a mapping of dependent service tenants to names and a second-tier collector for providing a dependency data representation of network events. The method may further include transmitting the dependency data to support access to the dependency data based on a dependency service interface and a data graph representation, the dependency service interface including a logical view interface having at least two selectable views that support presenting and accessing the dependency data, and the data graph representation including nodes and edges associated with a failure recovery mechanism.

[0102] Now go to Figure 5 , a flowchart illustrating a method 500 for providing dependency management is provided. A computer storage medium has computer executable instructions embodied thereon that, when executed by one or more processors, cause the one or more processors to perform a method for dependency management. At box 510, a dependency service interface is generated. The dependency service interface includes a logical view interface having at least two optional views that support presenting and accessing dependency data. The dependency data is generated based on data from a plurality of collectors, the dependency data including dependencies and subordination relationships associated with tenant services of a dependency management system. The plurality of collectors access data for generating the dependency data based on a collection time attribute associated with the corresponding collector, the collection time attribute being selected from one of: design time collection; deployment time collection; and runtime collection. At box 520, the dependency service interface is populated with the dependency data generated from the data retrieved by the plurality of collectors.

[0103] A first optional logical view of the logical view interface is a dependency view by service that supports viewing faults of tenant services, and a second optional logical view of the logical view interface is a dependency view by location that supports viewing faults of tenant service locations. The dependency service interface further includes a dependency search bar that supports searching for tenant services, where incoming relationships and outgoing relationships are populated on a dependency service interface-based search performed using the dependency search bar. It is envisioned that it is possible to present more views of dependencies, such as filters by location, current health of a service or location. In addition, the views can be integrated with other data sources, such as compliance, health, error rates, current network load, and CPU load to provide a more comprehensive and integrated view of dependency data. Advantageously, the different additional views enrich the dependency graph and other health models of the distributed computing system.

[0104] The dependency service interface operates based on an API that supports querying and retrieving dependency data based at least in part on automated access to a data graph representation of the dependency data, the data graph representation including nodes and edges associated with a failure recovery mechanism.

[0105] The dependency service interface further operates as a portal for viewing dependency data, wherein the portal further supports providing access to a data graph representation of the dependency data, wherein nodes in the data graph representation are associated with recovery actions and edges indicate failure models of corresponding dependency service tenants.

[0106] With reference to a dependency management system, the embodiments described herein support configuring, discovering, and communicating dependencies between services in a distributed computing system. A dependency management system component refers to an integrated component for managing dependencies. An integrated component refers to a hardware architecture and a software framework that support data access functionality using a dependency management system service platform. The hardware architecture refers to the physical components and their interrelationships, while the software framework refers to software that provides functionality that can be implemented using hardware operating on a device. An end-to-end software-based dependency management system service platform can operate within the dependency management system service platform component to operate computer hardware to provide dependency management system service platform functionality. In this way, the dependency management system service platform component can manage resources and provide services for dependency management system functionality. Any other variations and combinations are contemplated by embodiments of the present invention.

[0107] As an example, the dependency management system platform may include an API library that includes specifications for routines, data structures, object classes, and variables that can support interaction between the hardware structure of the device and the software framework of the dependency management system service platform system. These APIs include configuration specifications for the dependency management system platform system so that driver components and components therein can communicate with each other in the dependency management system service platform, as described herein. In particular, the API can support external services (e.g., health monitoring, compliance review, etc.) to retrieve dependency information.

[0108] Having briefly described an overview of embodiments of the present invention, an exemplary operating environment in which embodiments of the present invention may be implemented is described below in order to provide a general context for various aspects of the present invention. Figure 6 , in particular, an exemplary operating environment for implementing embodiments of the present invention is shown and generally designated as computing device 600. Computing device 600 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the present invention. Neither should computing device 600 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

[0109] The present invention may be described in the general context of computer code or machine-usable instructions comprising computer-executable instructions (such as program modules) executed by a computer or other machine (such as a personal data assistant or other handheld device). Generally, program modules, including routines, programs, objects, components, data structures, etc., refer to code that performs a specific task or implements a specific abstract data type. The present invention may be practiced in a variety of system configurations, including handheld devices, consumer electronics, general-purpose computers, more specialized computing devices, etc. The present invention may also be practiced in distributed computing environments, where tasks are performed by remote processing devices that are linked via a communications network.

[0110] Reference Figure 6 , computing device 600 includes a bus 610 that directly or indirectly couples the following devices: memory 612, one or more processors 614, one or more presentation components 616, input / output ports 618, input / output components 620, and an illustrative power supply 622. Bus 610 represents a bus that can be one or more buses, such as an address bus, a data bus, or a combination thereof. Although Figure 6 The various boxes are shown with lines for clarity, but in reality, delineating the various components is not so clear, and the lines are more accurately described as gray and fuzzy. For example, a presentation component such as a display device can be considered an I / O component. In addition, a processor has memory. We recognize that this is the nature of the art and reiterate that Figure 6The figures in the figures are merely illustrative of exemplary computing devices that can be used in conjunction with one or more embodiments of the present invention. No distinction is made between categories such as "workstation," "server," "laptop," "handheld device," etc., as all of these are contemplated herein. Figure 6 within the scope of and with reference to “computing devices”.

[0111] The computing device 600 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computing device 600 and includes both volatile and non-volatile media, and removable and non-removable media. By way of example and not limitation, computer-readable media can include computer storage media and communication media.

[0112] Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by the computing device 600. Computer storage media itself excludes signals.

[0113] Communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery medium. The term "modulated data signal" refers to a signal that has one or more of its characteristics set or changed in such a way as to encode information in the signal. By way of example, and not limitation, communication media include wired media such as a wired network or a direct wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

[0114] Memory 612 includes computer storage media in the form of volatile and / or non-volatile memory. Memory can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical drives, and the like. Computing device 600 includes one or more processors that read data from various entities (such as memory 612 or I / O components 620). Presentation component 616 presents data indications to a user or other device. Exemplary presentation components include a display device, a speaker, a printing component, a vibration component, and the like.

[0115] I / O ports 618 allow computing device 600 to be logically coupled to other devices including I / O components 620, some of which may be internal. Illustrative components include a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc.

[0116] Now refer to Figure 7 , Figure 7 An exemplary distributed computing environment 700 is shown in which implementations of the present disclosure may be employed. In particular, Figure 7 Shown is a high-level architecture of a dependency management system ("system") in a cloud computing platform 710 that supports seamless modification of software components. It should be understood that this arrangement and other arrangements described herein are set forth only as examples. In addition to or in place of those shown, other arrangements and elements (e.g., machines, interfaces, functions, sequences, and functional groupings, etc.) may be used, and some elements may be omitted entirely. Further, many of the elements described herein are functional entities that may be implemented as discrete or distributed components or in combination with other components, and in any suitable combination and position. The various functions described herein as being performed by one or more entities may be performed by hardware, firmware, and / or software. For example, the various functions may be performed by a processor executing instructions stored in a memory.

[0117] The data center can support a distributed computing environment 700, which includes a cloud computing platform 710, racks 720, and nodes 730 (e.g., computing devices, processing units, or blades) in the racks 720. The system can be implemented using the cloud computing platform 710, which runs cloud services across different data centers and geographic regions. The cloud computing platform 710 can implement a fabric controller 740 component for resource allocation, deployment, upgrades, and management of cloud services. Typically, the cloud computing platform 710 functions to store data or run service applications in a distributed manner. The cloud computing infrastructure 710 in the data center can be configured to host and support the operation of endpoints for specific service applications. The cloud computing infrastructure 710 can be a public cloud, a private cloud, or a dedicated cloud.

[0118] Node 730 can be supplied with host 750 (e.g., operating system or runtime environment), which runs a defined software stack on node 730. Node 730 can also be configured to perform specialized functions within cloud computing platform 710 (e.g., compute node or storage node). Node 730 is allocated to run one or more parts of a tenant's service application. A tenant can refer to a customer who utilizes the resources of cloud computing platform 710. The service application components of cloud computing platform 710 that support a particular tenant can be referred to as tenant infrastructure or lease. The terms service application, application, or service are used interchangeably herein and broadly refer to any software or portion of software that runs on or accesses storage within a computing center and computes device locations within a computing center.

[0119] When node 730 is supporting more than one separate service application, the node can be divided into virtual machines (e.g., virtual machine 752 and virtual machine 754). Physical machines can also run separate service applications in parallel. Virtual machines or physical machines can be configured as personalized computing environments supported by resources 760 (e.g., hardware resources and software resources) in the cloud computing platform 710. It is envisioned that resources can be configured for specific service applications. In addition, each service application can be divided into functional parts so that each functional part can run on a separate virtual machine. In the cloud computing platform 710, multiple servers can be used to run service applications and perform data storage operations in a cluster. In particular, servers can perform data operations independently, but are exposed as single devices called clusters. Each server in the cluster can be implemented as a node.

[0120] The client device 780 can be linked to the service application in the cloud computing platform 710. The client device 780 can be any type of computing device, for example, it can correspond to the reference Figure 7 The computing device 7 described above is a client device 780. The client device 780 can be configured to issue commands to the cloud computing platform 710. In an embodiment, the client device 780 can communicate with the service application via a virtual Internet Protocol (IP), and a load balancer or other device that directs the communication request to a designated endpoint in the cloud computing platform 710. The components of the cloud computing platform 710 can communicate with each other over a network (not shown), which can include, but is not limited to, one or more local area networks (LANs) and / or wide area networks (WANs).

[0121] Having described various aspects of the distributed computing environment 700 and cloud computing platform 710, it should be noted that any number of components may be used to implement the desired functionality within the scope of the present disclosure. Figure 7The various components in are shown with lines for clarity, but in reality, delineating the various components is not so clear, and the lines are more accurately described as gray and fuzzy in metaphorical terms. Furthermore, although Figure 7 Some components of the present disclosure are depicted as single components, but the description is exemplary in nature and quantity and is not to be construed as limiting for all embodiments of the present disclosure.

[0122] The embodiments described in the following paragraphs may be combined with one or more of the alternatives specifically described. In particular, the claimed embodiments may include references, but alternatively, may include more than one other embodiment. The claimed embodiments may specify further limitations of the claimed subject matter.

[0123] The subject matter of the embodiments of the present invention is described herein with specificity to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. On the contrary, the inventors have contemplated that the claimed subject matter may also be implemented in other ways, in combination with other current or future technologies, to include different steps or combinations of steps similar to the steps described in this document. Furthermore, although the terms "step" and / or "box" may be used herein to suggest different elements of the method employed, these terms should not be interpreted as implying any particular order among or between the various steps disclosed herein unless and except when the order of the individual steps is explicitly described.

[0124] For purposes of this disclosure, the word "including" has the same broad meaning as the word "comprising," and the word "access" includes "receiving," "referring to," or "retrieving." Additionally, unless otherwise indicated, words such as "a" and "an" include the plural as well as the singular. Thus, for example, the constraint of "feature" is satisfied where one or more features are present. Furthermore, the term "or" includes conjunctions, disjuncts, and both (a or b therefore includes a or b, as well as a and b).

[0125] For the purposes of the detailed discussion above, embodiments of the present invention are described with reference to a distributed computing environment; however, the distributed computing environment depicted herein is merely exemplary. Components may be configured to perform novel aspects of the embodiments, including being programmed to perform specific tasks or to implement specific abstract data types using code. Furthermore, while embodiments of the present invention may generally refer to a head-mounted display unit and the schematics described herein, it should be understood that the described techniques may be extended to other implementation contexts.

[0126] The embodiments of the present invention have been described with respect to specific embodiments which are intended in all respects to be illustrative rather than restrictive. Alternative embodiments will become apparent to those skilled in the art to which the present invention pertains without departing from the scope of the present invention.

[0127] From the foregoing it will be seen that this invention is one well adapted to attain all the ends and objects set forth above, together with other advantages which are obvious and inherent to the structure.

[0128] It will be understood that certain features and subcombinations are of utility and may be employed without reference to other features or subcombinations. This is contemplated by the claims and is within the scope of the claims.

Claims

1. A system for implementing dependency management, the system comprising: one or more hardware computer processors; as well as Computer memory storing computer-usable instructions that, when used by the one or more hardware computer processors, cause the one or more hardware computer processors to perform operations comprising: enabling a plurality of collectors to access data for generating dependent data based on a collection time attribute assigned to a corresponding collector, the corresponding collector providing an operation on a target set of data at a collection time of the collection time attribute, Each of the plurality of collectors is assigned a corresponding collection time attribute, and the corresponding collection time attribute is selected from one of the following: design time collection, deployment time collection, and runtime collection, so that the plurality of collectors perform operations on a target set of data at design time, deployment time, and runtime based on their assigned collection time attributes, wherein the design time, the deployment time, and the runtime are classifications of declarative artifacts or analysis operations for a target set of design data, deployment data, and runtime data, and the design data, deployment data, and runtime data are analyzed to generate dependency data for tenant services.

2. The system according to claim 1, further comprising a dependency service manager configured to: accessing the data collected by the plurality of collectors; analyzing the collected data to cross-check and generate relationships between dependent service tenants and corresponding dependent and subordinate components; as well as Dependency data is generated based on the data retrieved by the plurality of collectors, the dependency data including dependency relationships and dependencies associated with the dependency service tenants of the system for implementing dependency management.

3. The system of claim 2, wherein the dependency service manager further comprises a standard name provider that supports naming conventions across dependency service tenants to generate and look up standard names for dependency service tenants, wherein the plurality of collectors retrieve and update data for dependency service tenants based on corresponding collection time attributes, wherein at least a portion of the data is transmitted to the standard name provider, and the standard name provider uses the at least a portion of the data to generate and look up standard names for dependency service tenants, wherein the standard name provider operates at least in part with a network naming system to update dependency data based on network events.

4. The system of claim 2, wherein the dependency service manager communicates the dependency data with a portal, the portal providing access to a dependency service interface and a data graph representation of the dependency data.

5. The system of claim 2, wherein the dependency service manager further comprises: a dependency aggregator implementing a dependency aggregation mechanism having a first-tier collector for building a mapping of dependency service tenants to names and a second-tier collector for providing dependency data representations of network events; or A dependency aggregator implements a dependency aggregation mechanism for retrieving data based at least in part on a service model definition and heuristics defined for identifying dependent service tenants based on the service model definition.

6. The system of claim 1 , further comprising: During design-time collection, a design-time collector from the plurality of collectors retrieves data associated with one or more of: static dependency analysis, layer mapping, and fault model analysis; During deployment time collection, a deployment time collector from the plurality of collectors retrieves data associated with one or more of: Team Foundation Service TFS and Configuration Repository CS; and During runtime collection, a runtime collector from the plurality of collectors retrieves data associated with one or more of: a service model definition and monitoring events of the distributed computing infrastructure of the system for implementing dependency management.

7. A system according to claim 2, wherein the dependency service manager transmits the dependency data to cause the generation of a dependency service interface and a data graph representation, the dependency service interface including a logical view interface, the logical view interface having at least two optional views supporting presentation and access to dependency data, and the data graph representation including nodes and edges associated with a fault recovery mechanism.

8. A computer-implemented method for providing dependency management, the method comprising: receiving data from a plurality of collectors, wherein the plurality of collectors access the data based on collection time attributes assigned to corresponding collectors, the corresponding collectors providing operations on a target set of data at a collection time of the collection time attributes, wherein each of the plurality of collectors is assigned a corresponding collection time attribute, the corresponding collection time attribute being selected from one of the following: design time collection, deployment time collection, and runtime collection, causing the plurality of collectors to perform operations on the target set of data at design time, deployment time, and runtime based on the assigned collection time attributes, wherein the design time, the deployment time, and the runtime are classifications of declarative artifacts or analysis operations for target sets of design data, deployment data, and runtime data, the design data, deployment data, and runtime data being analyzed to generate dependency data for tenant services; as well as Dependency data generated from data collected by the plurality of collectors is transmitted to cause generation of a dependency service interface having the dependency data generated from the data retrieved by the plurality of collectors.

9. The method according to claim 8, further comprising: analyzing the data collected by the plurality of collectors to cross-check and generate relationships between dependent service tenants and corresponding dependent and subordinate components; as well as When analyzing the data, dependency data including dependency relationships and subordination relationships associated with the dependent service tenants of the system for implementing dependency management is generated, wherein the plurality of collectors retrieve and update the data of the dependent service tenants based on corresponding collection time attributes.

10. The method of claim 8, wherein design-time collection includes identifying developer-provided dependency information that supports identifying dependencies and dependencies of dependent service tenants.

11. The method of claim 8, wherein the deploy time collection comprises mapping deployed services to dependent service tenants based on monitoring deployment operations of a distributed computing infrastructure for implementing a system for dependency management.

12. The method of claim 8, wherein runtime collection comprises identifying dependencies of dependent service tenants while operations of the dependent service tenants are being performed based at least in part on network traffic communicated between components.

13. A method according to claim 8, wherein generating dependency data is based on identifying indirect dependencies, wherein the indirect dependencies between dependent service tenants are based on a communication channel between the dependent service tenants, and the communication channel is selected from one of the following: a storage device; a service bus; a queue; and a structured query language (SQL) database.

14. The method of claim 8, wherein generating dependency data is based on implementing a dependency aggregation mechanism using a first tier collector for building a mapping of dependency service tenants to names and a second tier collector for providing dependency data representation of network events.

15. The method of claim 8, further comprising transmitting the dependency data to support access to the dependency data based on the dependency service interface and a data graph representation, the dependency service interface comprising a logical view interface having at least two selectable views supporting presentation and access to dependency data, and the data graph representation comprising nodes and edges associated with a fault recovery mechanism.

16. One or more computer storage media having one or more hardware processors and memory, the memory storing computer-executable instructions embodied thereon, the computer-executable instructions, when executed by the one or more hardware processors, causing the hardware processors to perform a method for dependency management, the method comprising: receiving data from a plurality of collectors, wherein the plurality of collectors access the data based on collection time attributes assigned to corresponding collectors, the corresponding collectors providing operations on a target set of data at a collection time of the collection time attributes, wherein each of the plurality of collectors is assigned a corresponding collection time attribute, the corresponding collection time attribute being selected from one of the following: design time collection, deployment time collection, and runtime collection, causing the plurality of collectors to perform the operations on the target set of data at design time, deployment time, and runtime based on the collection time attributes assigned thereto, wherein the design time, the deployment time, and the runtime are classifications of declarative artifacts or analysis operations for target sets of design data, deployment data, and runtime data that are analyzed to generate dependency data for tenant services; generating a dependency service interface that supports presentation and access to dependency data, wherein the dependency data is generated based on data from a plurality of collectors, the dependency data including dependencies and subordination relationships associated with tenant services of the dependency management system; as well as The dependency service interface is populated with dependency data generated from the data retrieved by the plurality of collectors.

17. The medium of claim 16, wherein the dependency service interface comprises a logical view interface having a first optional logical view and a second optional logical view, the first optional logical view of the logical view interface being a dependency view by service, the dependency view by service supporting viewing of failures of tenant services, and the second optional logical view of the logical view interface being a dependency view by location, the dependency view by location supporting viewing of failures of tenant service locations.

18. The medium of claim 16, wherein the dependency service interface further comprises a dependency search bar that supports searching for tenant services, wherein incoming relationships and outgoing relationships are populated on a search based on the dependency service interface performed using the dependency search bar.

19. The medium of claim 16, wherein the dependency service interface further comprises an application programming interface (API) that supports querying and retrieving dependency data based at least in part on automated access to the dependency data.

20. The medium of claim 16, wherein the dependency service interface operates as a portal for viewing dependency data, wherein the portal further supports providing access to a data graph representation of the dependency data, the data graph representation including nodes and edges associated with a failure recovery mechanism.

Images