100 via a computer network such as the network 106. The input device 104-E may include one or more peripheral device such as a detached keyboard or mouse, or an integral device such as a capacitive touch screen of a portable computing device. The output device 104-F may be a suitable display device such as a computer monitor, capacitive touch screen, television screen, etc. In some embodiments, the avatar 104 may be a VM. In other embodiments, the avatar 104 may be a VM downloaded by the customer from the IT service provider. The avatar VM may be a large (e.g., gigabytes or larger) image file.

In some embodiments, the avatar 104 may be installed at the premises of the customer or a facility related to a customer (e.g., a corporate office, datacenter, etc.). In those embodiments, a customer employee/contractor may interact with the avatar 104 via the input device 104-E, the display device 104-F, and/or via a computer terminal communicatively coupled to the avatar 104.

The avatar 104 may include one or more modules implemented as hardware (e.g., a hardware appliance) and/or computer readable instructions (e.g., software). For example, the avatar 104 may include the application 104-G. The application 104-G may include instructions that execute upon the occurrence of an event. For example, the avatar 104 may include a set of instructions for establishing one or more tunnel via network 106 at boot time, and/or in the event of a network change (e.g., if a new dynamic IP address is assigned by a dynamic host configuration protocol (DHCP) server). The avatar 104 may be communicatively coupled to an electronic database 110-B. The electronic database 110-B may store data relating to the customer's business operations.

In operation, a customer may have a contract with the IT services provider, or may be considering hiring the IT services provider to provide services. That is, the customer may be an established customer or a new customer contracting with the IT services provider on a trial basis. The customer may contact the IT services provider by visiting a website hosted in the remote computing device 102 or another computer of the IT services provider. The website may serve a web page to the customer including a menu of available services. The menu may differ, depending on the status of the customer (e.g., new customer or existing customer). It should be appreciated that in some embodiments, the customer may add more services or order new services via another electronic medium (e.g., a telephone call to the IT services provider). The customer may then select from the menu of available services, and submit a list of desired services.

The application 102-G may analyze the list of services desired by the customer and, based on the desired services of the customer, generate either a customized VM appliance and/or generate an order for the creation of a physical appliance (i.e., an avatar). The application 102-G may include instructions for immediately delivering the generated customized VM appliance to the customer via a download link, via email, and/or via an automated installation in the computing cloud 108. The computing cloud 108 may include a resource (e.g., an existing VM) owned/controlled by the customer. In some embodiments, the customer may be required to grant access to the IT services provider before the customized VM appliance may be installed. Part of the grant of access may include granting access to firewall rules of the customer. In that case, the IT services provider may automatically configure the customized VM appliance to run in the chosen cloud, optionally based on the type of cloud, instantiate the customized VM appliance, and automatically configure the firewall rules associated with the VM appliance. In some embodiments, instructions for installing and/or configuring the customer's VM and associated firewall rules manually may be displayed/communicated to the customer, such as when the customer indicates that they will perform the VM installation/configuration on their own.

The instructions for installing/configuring the customer's firewall rules manually may instruct the customer to, inter alia, download the customized VM appliance, launch the VM appliance in an appropriate hypervisor/VM emulator, provide the VM appliance with certain permissions in the virtualization environment (e.g., to network layers and/or devices), and/or perform certain networking tasks (e.g., create virtual/physical networking device nodes, modify permissions, open ports, filter network packets (e.g., IPv4 packets, IPv6 packets, etc.) by type, etc.). However, in general, the instructions may be limited to asking the customer to boot the VM and to open ports in the customer's external firewall. Specifically, the VM may be instantiated behind a general corporate or router-based firewall of the customer, and ports exterior to that corporate firewall may need to be opened to allow the IT services provider to reach the avatar 104 (i.e., the instantiated VM appliance/physical appliance). In some embodiments, the avatar 104 may be installed in a de-militarized zone (DMZ) of a network, which may obviate the need to open ports. In other cases, more complex procedures may be advised, such as establishing port-knocking software. Access-based controls such as VPN passthroughs via IPSec may be used.

When the customer boots the avatar for the first time, whether virtual or physical, the avatar may execute an initialization procedure including a set of executable program instructions. In an embodiment, the IT services provider may instantiate two or more multiple remote computing device 102. The two or more remote computing device 102 may perform different functions. For example, a first remote computing device 102 may perform a port forwarding function. A second remote computing device 102 may perform an intermediary host function. A third remote computing device 102 may perform a connection funnel function. A fourth remote computing device 102 may perform a firewalling function, and so on. Each of the two or more remote computing device 102 may include more or less hardware and/or software, and different sets of installed hardware and/or software as appropriate. For example, the port forwarder remote computing device 102 may include multiple physical interface devices to perform forward and reverse proxying operations using multiple physical and/or virtual (e.g., TUN/TAP) virtual network interface. The IT services provider may associate the remote computing device 102 with a particular customer. In that case, the remote computing device 102 may be known as a Base Management Node (BMN). The BMN may run services of the customer (e.g., a Remote Authentication Dial-In User Service (RADIUS)). In some embodiments, each customer of the IT services provider may be provided with a BMN wherein each BMN has an address that corresponds to the customer's environment. When a BMN is used, the avatar 104 provided by the IT services provider to the customer may be a thin client. If the thin client is stolen or misplaced, then sensitive material on the avatar may be minimized. Full disk encryption may, therefore, not be necessary and the avatar 104 may be invalidated and blocked from connecting to the BMN. From a risk perspective, keeping information segmented by the use of the avatar 104 is very beneficial and results in a much smaller hardware footprint and software footprint in the customer's network customer side. The avatar 104 may be a relatively low-powered device (e.g., an Internet-of-Things (IoT) device).

Once the avatar 104 is delivered to the customer, whether the avatar 104 is a physical device or a virtual machine, the avatar 104 may run an initialization procedure. The initialization procedure may take place only one time, when the avatar 104 is first connected to the network 106, for example. The initialization protocol may include the avatar 104 connecting to one of a plurality of purpose-built computing environments that are accessible via the network 106. The initialization protocol may include establishing a set of one or more tunnels between the avatar 104 and a set of one or more a BMNs. The initialization protocol is discussed further below.

Example Data Flow Diagram

FIG. 2 is a data flow diagram 200 illustrating the operation of methods and systems for operation of automated IT services management. Some embodiments may include one or more data center. The data centers may include data center 202-1, 202-2, through 202-l, each of which may be located in the United States or elsewhere. The data flow diagram 20 may include BMNs 204-1, 204-2 through 204-m. The data flow diagram 200 may include customer infrastructure 206-1, 206-2 through 206-n. The numbers l, m, and n may be any positive integers. That is, data flow diagram 200 may include any number of data centers, BMNs, and/or customer infrastructure. The data flow diagram 200 depicts each data center as being communicatively coupled to each BMN via communication links 208-A, and each BMN as being communicatively coupled to each customer infrastructure via communication links 208-B. However, in some embodiments fewer links may exist. For example, links 208-A may include one communicative link between the data center 202-1 and the BMN 204-1. In some embodiments, each BMN may be linked to one corresponding customer infrastructure. Customer infrastructure 206-1 through 206-n may each include a respective set of one or more avatar 210, each of which may correspond to the avatar 102, for example.

As discussed above, the avatar 210 may connect to one of a plurality of purpose-built computing environments during the initialization procedure. The avatar 210 may first connect to a connection broker, identifying the avatar 210 by providing a unique identifier (e.g., a universally-unique identifier (UUID)) to the connection broker as a parameter. The connection broker may compare the UUID to a list of avatars in a database, such as database 110-A, to identify a data center corresponding to the avatar 210. Based on the UUID, the connection broker may determine which BMN to build a connection to. Connecting to the connection broker may include identifying a monitoring environment for the customer. For example, a small customer may have a subscription with the IT services company to a service (e.g., a monitoring service) in a first data center (e.g., a data center located in Chicago). The tunnel may then be established to the first data center (e.g., the data center 202-1). Building the connection may include creating multiple TUN devices in the avatar 210. The connection broker may transmit a set of initialization data to the avatar 210, the initialization data including an IP address for the avatar. The avatar 210 may build a point-to-point (P2P) link, using the IP address, wherein packets flow seamlessly between the BMN 204-1 and devices in the customer infrastructure 206-1 via the avatar 210, over the P2P link. A P2P link may differ from an Ethernet link insofar as that the P2P link may be a network level (i.e., layer-3) link, whereas the Ethernet link may be a level-2 link. Various protocols (e.g., NTP, HTTP, RDP, etc.) may be simultaneously routed between the customer environment 206-1 and the BMN 204-1. The initialization protocol may be run at given times (e.g., when a connection of the avatar 210 is disconnected, when the device or virtual machine implementing the avatar 210 reboots, on a schedule, etc.). The avatar 210 may also include a second initialization routine. For example, if the selected data center is unavailable, such as in the event of catastrophic failure, disaster recovery test, etc., then the avatar 210 may include a set of instructions for automatically routing to a fallback data center.

The avatar 210 may require two or more IP addresses in the customer infrastructure 206-1. For example, a first IP address may be used by the avatar 210 for connectivity inbound to the customer infrastructure 206-1, and a second IP address may be used for outbound connectivity to the BMN 204-1. The BMN may masquerade for services behind it, that is, services that are only accessible to users of the customer infrastructure 206-1 via the BMN. The customer may have limited visibility of the services behind the BMN. The linkages between the customer infrastructure 206-1 and the BMN 204-1 may be such that a user of customer infrastructure 206-1 through 206-n inspecting the network environment of customer infrastructure 206-1 (e.g., via ping) would not see any evidence of the IP address of the avatar 210 installed in the customer infrastructure 206-1. Rather, the customer would see an IP address belonging to the BMN. Additionally, the avatar 210 may enable computers in the customer's network to access the BMN without configuring firewalls, routers, etc. The customer may need only open two or more ports in the customer infrastructure 204-1 firewall or another firewall. The avatar 210 may be located in any location that is communicatively coupled to the customer infrastructure can be located anywhere, and need not be located in the customer's physical or virtual network. In some embodiments, the avatar 210 can be located in a geographic region other than where the customer infrastructure 206-1 is located (e.g., in another country).

In general, the collection of avatar 210 machines and their respective links allow the IT services company to effectively manage customer environments at scale on a customer-by-customer basis, to meet the need of each customer. For example, some customers may be provided with redundant environments, data centers, avatars, and/or BMNs. A customer representing monthly revenue of $50 may not be provisioned redundantly. However, a $25,000/month customer may be provisioned using fully replicated/redundant resources. The IT services provider may operate a cloud system that enables on-demand horizontal scaling without practical resource limitations.

The present techniques are much more cost effective than hardware-based systems of the past. As noted above, under old models, the IT services company had to send hardware to the customer at the outset of a business relationship, and periodically throughout the business relationship. Using the techniques described herein, the IT services company can provide just-in-time backend services, and can project services to the customer on demand by, for example, modifying a BMN associated with the customer. The scaling aspect is also very useful for prototyping and marketing purposes. Normally, an IT services company that wanted to provide 5,000 samples of IT services would need to send 5,000 managed hardware devices to individual customers. However, using the present techniques, the IT services company can send 5,000 invitations, and only activate as many avatar device resources (virtualized or hardware) as interested customers respond to the invitations.

The avatar 210 may be deployed into an existing cloud computing platform (e.g., via Amazon Web Services) by virtual deployment. The IT services provider may then connect to the customer infrastructure associated with the avatar 210 via the existing cloud to manage resources in the customer infrastructure that are not in the existing cloud as well as resources that are accessible via the existing cloud. Each customer may have their own virtual infrastructure from a networking and data traffic perspective. This isolation satisfies numerous compliance and security requirements.

The methods and systems described herein are applicable to any managed services environment including, without limitation, those of insurance, healthcare, manufacturing, e-commerce, and financial services companies. Federal, state, and municipal government IT resources may be managed using the present techniques. In some embodiments, concerns and/or suggestions regarding the present techniques may result in infrastructure upgrades that may be propagated between customers. The present techniques allow the IT services provider to expand the IT services provider's existing toolset into the customer's environment. For example, a service VM may be transferred via the avatar 210 to the customer infrastructure 206-1. The service VM may be accessible only by the IT services provider, and may include instructions for analyzing and modifying aspects of the customer infrastructure 206-1. Tools, firewall rules, and other resources that customers might typically need for IT services may be eliminated. Further, because the IT services provider has greater direct control over the service environment (e.g., the remote computing device 102), the IT services provider can tune those critical aspects of the service environment (e.g., geographic redundancy, high-availability, etc.) on an as-needed basis.

Example Automated it Services Management System

FIG. 3 depicts a system diagram 300 including an IT service provider infrastructure 302 including respective customer hosting regions and customer infrastructure, and a network 306. The IT service provider infrastructure 302 may include a customer service region 302-A, a customer service region 302-B, a connection funnel 302-C, a central port forwarder 302-D, a firewall 302-E, and an intermediary host 302-F. Although only two customer service regions are depicted, any practical number of customers and service regions may be supported in IT service provider infrastructure 302. System diagram 300 may also include a customer infrastructure 304-A and a customer infrastructure 304-B, which may correspond, respectively, to the customer service region 302-A and the customer service region 302-B. The customer infrastructure 304-A and the customer infrastructure 304-B may represent data centers of the respective customers. The IT service provider infrastructure 302 may be communicatively coupled to the customer infrastructure 304-A and the customer infrastructure 304-B via the network 306. The network 306 may correspond to the network 106 depicted in FIG. 1.

As noted above, the avatar in customer infrastructure 304-A may execute initialization instructions based upon the occurrence of an event (e.g., at boot time, if connectivity is lost, upon receiving/retrieving a signal, etc.). In some embodiments, the avatar may correspond to the avatar 104 and/or the avatar 210. The initialization instructions may include connecting the avatar to one or more connection broker (not depicted). The connection broker may be thought of as a traffic director. The avatar may identify itself by providing an identification parameter to the connection broker, and the connection broker may determine the owner/controller customer associated with the avatar by associating the identification parameter in a database comprising customer information, such as the database 110-A. The connection broker may determine one or more priority data centers (e.g., Chicago and Milwaukee). The data center(s), which may correspond to the data center 202-1 through the data center 202-l of FIG. 2, may be based on geographic proximity to the avatar, in some embodiments. Because multiple priority data centers are identified, if one of the data centers is unreachable, one of the other data centers may act to handle the customer's connectivity.

The avatar may then connect to the intermediary host 302-F. By default, the avatar may be unreachable from the Internet. When the avatar connects to the intermediary host 302-F (e.g., via secure shell (SSH)), the avatar may create a persistent connection to the intermediary host 302-F. The intermediary host 302-F may reside in the provider infrastructure 302, and may be accessible only from within the provider infrastructure 302. Therefore, in an embodiment, a host (e.g., a networked computer) in the provider infrastructure 302 may be able to connect to the avatar via the intermediary host 302-F and the customer firewall within the customer infrastructure 304-A, without creating a connection that is visible to hosts on the open Internet (e.g., hosts accessible via the network 306). Here, the intermediary host 302-F may have a level of trust that is higher than other hosts, and various forms of authentication may be used to enforce access to the customer infrastructure 304-A (e.g., public and/or private key authentication, multi-factor authentication, etc.).

In an embodiment, the connection between the avatar and the intermediary host 302-F may comprise two network tunnels. The two tunnels may allow traffic to flow to and from the avatar via the intermediary host 302-F. Further, one or more additional persistent tunnels may be created between components of the customer service region 302-A and the avatar via the intermediary host 302-F. establishing one or more tunnel linked to the one or more respective remote computing device 102.

From the perspective of a customer within the customer infrastructure 304-A, the BMN of customer service region 302-A may appear to be directly connected to the customer infrastructure 304-A, even though several network hops are required to reach the BMN. The BMN may be located in a data center. Furthermore, the BMN may be associated with one or more services that the BMN is responsible for forwarding to the customer in the forward and reverse direction. For example, one or more monitoring collector may be associated with the BMN. Each of the one or more monitoring collector may collect data from the customer infrastructure 304-A via the connection(s) linking the avatar to the BMN discussed above. The BMN may transparently proxy/masquerade the connections to and from the avatar via the BMN, such that if the customer were to inspect the packets, the customer would not be able to tell that a particular one of the one or more monitoring collector was initiating and/or receiving the traffic. Additionally, the customer may not able to determine the ultimate destination of any packets sent to the BMN.

In some embodiments, 302 is a single pod. Each one may have a central port forwarder 302-D, connection funnel 302-C, etc. In this way, a customer may have their own set of services and tunnel stack, keeping the customer environments segregated and not inter-accessible. In some embodiments, the separation may be enforced in user space via a software-defined network. The firewall 302-E may restrict the packets that may be passed between the intermediary host 302-F and the connection broker.

In some embodiments, the connection funnel 302-C may include IP blacklists on a per-BMN and/or per-customer basis. For example, the connection funnel 302-C may include a list C of customers C₁-C_nin association with an address space for each customer C, wherein n is a positive integer. The connection funnel 302-C may be a software-driven firewall including rules for filtering packets according to whether a given BMN may transmit packets to a given address space of a particular customer in C. For example, the BMN depicted in customer service 302-B may have a first Ethernet card (e.g., eth0). Connection funnel 302-C may include firewall instructions such that packets from the first Ethernet card having an IP address matching the BMN may only be sent to hosts in the IP range 8.9.10.0-8.9.10.255. That is, only 256 hosts could possibly receive packets from that BMN, and no others. In some embodiments, the firewall instructions may similarly restrict other BMNs (e.g., the BMN in customer service region 302-A) from sending packets to those IP ranges. In some embodiments, the IP range may be specified as a set of Classless Inter-Domain Routing (CIDR) network specification. For example, to continue the example, the above IP range could be specified as 8.9.10.0/24. Network traffic may also be restricted to only that traffic sent via the intermediary host 302-F on a given port.

The customer funnel 302-C includes rules preventing customer service region 302-A from contacting customer service region 302-A. The connection funnel 302-C is automatically updated any time a new customer service region is added and/or deleted. When an appliance comes online, the customer service region is created, and the appropriate firewall rules are automatically added to the connection funnel 302-C.

Example Operation of Automated Information Technology Services Management

FIG. 4A depicts an example operation environment 400 including a customer service region 402, a customer infrastructure 404, and a network link 406. The customer service region 402 may correspond to the customer service region 302-A of FIG. 3. The customer service region 402 may reside in a data center of the IT services provider, such as data center 202-1 of FIG. 2. The customer infrastructure 404 may correspond to the customer infrastructure 304-A, or another customer infrastructure, of FIG. 3. Operation environment 400 may include a connection funnel, central port forwarder, firewall, and intermediary host; which may respectively correspond to the connection funnel 302-C, the central port forwarder 302-D, firewall 302-E, and intermediary host 302-F of FIG. 3. A connection broker may also be included in the environment 400. The connection broker may correspond to the remote computing device 102 of FIG. 1.

In operation environment 400, the customer service region 402 may correspond to the customer service region 302-A of FIG. 3, for example. The customer service region 402 may include a BMN virtual machine and a desktop host. The customer infrastructure 404 may include an appliance and one or more customer device, behind a firewall associated with the customer infrastructure 404. The network link 406 may correspond to the network 106 of FIG. 1 and the network 306 of FIG. 3.

FIG. 4B depicts an example operation environment 400 including a storage area network (SAN) 408 according to an embodiment. In this embodiment, the SAN 408 may be used by a storage administration team of the IT services provider. The SAN 408 may reside in a data center of the IT services provider. The SAN 408 may be scaled according to the input/output operations (IOPs) and/or network throughput of the network 406. The SAN may store a VM within the data center. Herein, the resources provided via the IT services provider may be any suitable IT resources, including without limitation labor of employees/contractors, access to information (e.g., a database), an API of the IT services provider or a third party, etc.

FIG. 4C depicts an example operation environment 400 including a hardware BMN 410 collocated in the customer infrastructure 404, according to an embodiment. In FIG. 4C, the customer infrastructure 404 may have high storage and/or data processing requirements. The customer infrastructure 404 may have very low allowable latency. For example, the customer infrastructure 404 may include a firewall that generates large amounts of data very quickly, or an application that processes equity trades in near real-time. The hardware BMN 410 collocated in the customer infrastructure 404 may function identically to the BMNs residing in the customer service region 402 in FIG. 4B. In an embodiment, the collocated BMN 410 may be a virtualized computing instance, in some embodiments. Because the BMN 410 is collocated, the customer can still monitor core systems via the BMN 410 given a loss of connectivity to the network link 406.

FIG. 4D depicts an example block diagram 400 including an example method for the automated delivery and/or usage of a copy of licensed software to a customer's BMN. In the depicted embodiment, the licensed software may be a scanning utility. The method may include loading the software tool in a virtual machine (VM) template (block 1). The VM template may be based on a GNU/Linux VM, for example. Next, the VM may be initialized (i.e., booted) and populated with data needed to use the licensed software. The method may include using the software on behalf of the customer infrastructure 404-1 (e.g., scanning the customer infrastructure 404-1 via the network link 406-1) to generate an output based on the scanning (block 2). The method may include posting the results of the scanning to a cloud services provider, including an identifier uniquely identifying the customer (block 3). The method may include destroying the initialized VM, to avoid passing a VM between customers that could have been infected or which contains private customer data (block 4). After the completion of a task, the VM hosting the licensed software may be destroyed, reducing potential liability and overall software footprint. The method may include repeating blocks 1-4 of the method on behalf of any number of additional customers (e.g., on behalf of the customer infrastructure 404-2) (block 5). Thus, the present techniques provide a way for one or more licensed software to be shared amongst multiple customers. In some embodiments, free software and other types of software may be provisioned as discussed with respect to FIG. 4D. Further, the provisioning may be scaled to run either on demand or on a schedule. The software may be run for a period of time, in some embodiments, and then may reside in the customer VM until the customer completes a task. In some embodiments, a licensed hardware asset or quasi-hardware asset (e.g., access to a particular virtual machine or device) may be provided in place of, or in addition to, the licensed software asset.

FIG. 4E depicts an example operation environment 400 including a software tool 420, installed in the customer service region 402, and communicatively coupled to a BMN associated with the customer. The software tool 420 may correspond to the scanning utility depicted in the method of FIG. 4D, above. Here, the IT services provider may replace a software tool running on the BMN with a VM is communicatively coupled to the BMN (i.e., the software tool 420). The BMN may masquerade all traffic from the software tool 420 (e.g., an appliance), so that to other machines, traffic from the software tool 420 by way of the BMN appears as though it originated from an IP address associated with the BMN. Consequently, devices in the customer infrastructure 404 will not be able to tell that the virtualized software tool 420 is different from the non-virtualized scanning utility that was replaced. No customer devices will need to be touched in order to make the switch, highlighting a benefit of the techniques disclosed herein.

FIG. 4F depicts an example operation environment 400 including a software tool 422, installed in the customer service region 402, and communicatively coupled to a BMN associated with the customer. The deployment VM 422 may be used during the installation of a multi-server deployment 424. Specifically, a customer may order a product requiring a complex deployment which may take several weeks to complete. In the meantime, the avatar 404-A may be downloaded or shipped to the customer, and installed as discussed above. The IT services provider may then configure and build the deployment VM 422 based on a template maintained by the IT services provider (e.g., by the engineers performing the multi-server deployment 424). The engineers may push data (e.g., installation files) to the customer infrastructure 404 via the avatar 404-A, so that when the engineers arrive onsite at the customer, they are in a position to work immediately. In some embodiments, the engineers may be able to complete the multi-server deployment 424 once the servers arrive. Once the engineers have performed the install, the deployment VM 422 will be destroyed, thus reducing the risk of leaving assets behind in the customer infrastructure 404.

It should be appreciated by those of skill in the art that in the examples discussed above, the IT services provider is well-positioned to provide additional assistance to the customer. In general, the techniques discussed above allow the IT services provider to deploy assets (e.g., VMs) into the customer's environment on an as-needed basis, and to be poised to provide additional services without any delay.

Example Avatar Device

FIG. 5 depicts an exemplary physical avatar 502. The avatar 502 may correspond to the avatar 104, the avatar 210, and/or the avatar depicted in the customer infrastructure 304-A of FIG. 3. The avatar 502 may include a power supply 504, a set of data transfer and power cables 506, and a set of hardware ports 508. However, as noted above, in other embodiments the avatar may be a VM (i.e., composed of software). The power supply 504 may include a direct current (DC) and/or alternating current (AC) power supply suitable for the electric power requirements of the avatar 502. The set of data transfer and power cables 506 may include any suitable cabling (e.g., 2-wire, 4-wire, Ethernet cables, USB cables, HDMI cables, etc.). The set of hardware ports 508 may include one or more suitable power and/or data transmission ports, including without limitation RJ-45 connector ports (e.g., Ethernet ports), AC/DC power ports, HDMI ports, USB ports, etc. In hardware embodiments, the avatar 502 may be of any suitable dimensions, and may be implemented using any suitable computing device(s) (e.g., a laptop, a server, a tablet, a mobile computing device, etc.). The physical avatar 502 may be a relatively low-powered device, in some embodiments, such as a thin client, internet-of-things device, etc.

Example Provisioning User Interface

Turning to FIG. 6A, an example user interface 600 is depicted for provisioning IT services management tunnels. The user interface 600 may include a shell application including a configuration script 602 for building tunnels between the IT services provider and a customer. The shell application and configuration script may be implemented using any suitable operating system, programming language, and/or development frameworks. Although a command-line tool is depicted, in some embodiments, the shell application and/or configuration script may be web-based tools, a mobile application, etc.

The script 602 may include a plurality of flags for performing various actions regarding tunnels. For example, the script 602 may include a plurality of flags 604 for starting, restarting and displaying the status of a tunnel, wherein each flag in the plurality of flags 604 may include one or more additional parameters, wherein the additional parameters are depicted as hyphenated parameter names. For example, the plurality of flags may include parameters for specifying a customer, a BMN, an instance, and/or a tunnel to which the flag will be applied. Other flags may include authenticate/deauthenticate flags for, respectively, confirming and revoking the authentication status of a tunnel; a daemon flag for running the script 602 as a background process, a pause and unpause command for temporarily halting a tunnel, a refresh flag for reestablishing the tunnel, a remove flag for removing the tunnel, a cancel flag for canceling data sent in a tunnel, and a forward flag for setting a forwarding status. Each of the flags may be associated with different optional parameters. The parameters corresponding to each flag may include -key=value parameters and/or -key parameters.

FIG. 6B depicts an example of executing the script 602 with a series of arguments 606. The series of argument 606 include a status flag, an abbrev parameter, a bmn_name parameter, and a tunnel parameter. The status flag corresponds to a set of instructions that, when executed, cause the status of one or more BMN to be retrieved and displayed as output 608. The remainder of the arguments 606 may filter the output 608 to display only those of a particular customer (e.g., pmlab), a particular BMN by name (e.g., bmn03), wherein the instance is of type tunnel. The arguments 606 may be used to construct an efficient query, and to avoid returning a large data set. Each line in the output 608 depicts a link that may correspond to the tunnels discussed above. In some embodiments, each line in the output 608 may correspond to the communication links 208-A and/or the communication links 208-B of FIG. 2. Each line may correspond to a bidirectional tunnel between a BMN (e.g., a BMN with the hostname pmlab-s-bmn03) and an avatar device. Each column of the output 608 may include information relating to the tunnel.

For example, the instance column may correspond to the name of a virtual network kernel interface (e.g., a TUN or TAP device). In general, virtual network kernel interfaces/virtual network interface controllers (VNICs) are abstract network interfaces that provide packet reception and transmission for user space programs. They may be configured as point-to-point and/or Ethernet devices that receive packets from a user space program and/or send packets via a user space program. To the operating system, a TUN/TAP device appears and behaves the same as a physical interface, in that the assignment of IP addresses, routing, gateways, and firewall rules work as they do with respect to physical devices. However, by using VNICs, a large number of network devices may be emulated (e.g., thousands or more). When an avatar such as avatar 104 is delivered as a virtual appliance (e.g., a virtual machine) a VNIC may be used to provide a network interface for the virtual machine that is able to communicate with a host operating system. Importantly, VNICs allow packets to be exchanged in both IP (e.g., IPv4 and/or IPv6 protocols) and/or via raw Ethernet packets. A cryptographic network protocol (e.g., SSH) may be used to secure the packets transmitted via the VNIC. The output 608 includes the process identifier (PID) of an SSH process used to encrypt packets exchanged via the links depicted in output 608. In some embodiments, more than one SSH process may be used.

FIG. 6C displays the configuration of the VNIC tun6 depicted in FIG. 6B. In FIG. 6C, an ifconfig command is used to display a configuration 612 of VNIC tun6. The configuration 612 includes an IP address corresponding to the VINC tun6 of 172.20.16.14, corresponding to the LOCAL_SOCKET_ADDR displayed in FIG. 6B. A point-to-point (P-t-P) address of 172.20.16.15 is also displayed, corresponding to the BMN_SOCKET_ADDR displayed in FIG. 6A. FIG. 6C also includes an END_SYSTEM_SOCKET_ADDR column, which indicates the IP address and/or CIDR block to which the tunnel refers. In general, the LOCAL_SOCKET_ADDR socket is an IP address of a local NIC (e.g., NIC 102C), which may be a physical NIC or a VNIC, and the BMN_SOCKET_ADDR is a point-to-point IP address, and the END_SYSTEM_SOCKET_ADDR is the IP address of the corresponding end system. Generally the local socket address and BMN socket address are located in the IT services provider's environment (e.g., in the remote computing device 102) whereas the end system socket address(s) are located at the customer's environment (e.g., a set of network addresses within the customer infrastructure 304-A). As can be seen in FIG. 7, the end system socket address that may be bound to a remote host may correspond to a plurality of popular services, such as SSH (port 22), HTTP/HTTPS (ports 80 and 443 respectively), SMTP (port 25), etc. Importantly, when a user attempts to connect to these ports, the connections are transparently passed through to the BMN, as depicted. Each row of the table in the output 608 corresponds to a routing rule of a routing database (e.g., from the electronic database 110-B of FIG. 1). In other embodiments, routing information may be stored in another location within system 100.

In some embodiments, the user interface 600 may be implemented using other computer interface designs. For example, the user interface 600 may be implemented as a web interface, wherein a user may access the user interface 600 via a web browser, an application in a mobile computing device, a desktop application, etc. A web user interface 600 may use the script 602 through a translation layer (not depicted). For example, the user interface 600 may be implemented as a web application installed in an HTTP server of a computing device such as the remote computing device 102. A user may access the web application via a web browser. The HTTP server of the computing device may render web pages to the user via the web browser which correspond to the output of the script 102, and which accept inputs corresponding to the script 102. For example, the user may create, start, restart, and terminate a tunnel by accessing a web page displaying a list of tunnels. The server may provide web-based functionality for any of the operations supported by the script 602.

Example Routing Database

FIG. 7 depicts a table 700 of a routing database. The routing database and table 700 may be included in a database of the IT services provider, such as database 110-A of FIG. 1. The table 700 may include many (e.g., tens of thousands) of routing rules (i.e., individual rows) corresponding to one or more customer. The routing rules may be grouped by column (e.g., a BMN column 702-A). Different customers may have the same IP addresses within their respective networks, and the BMN column 702-A may be used to disambiguate between the different customers. That is, a combination of BMN column 702-A plus socket is a unique combination within the table 700. Herein, a “socket” may include a combination of an IP address and a port number. An INSTANCE column 702-B of the table 700 may be used to group services in the customer's environment. For example the rows in table 700 wherein column 702-B is 1 may be a set of web servers, whereas the rows wherein column 702-B is 255 may be operating system patch servers, etc. A column 702-C may indicate the status of the corresponding instance in 702-B, and a column 702-D may indicate the SSH process handling encryption of the tunnel, as discussed with respect to FIG. 6B. A set of columns 702-E, 702-F, 702-G, and 702-H may indicate sockets associated with the tunnels in table 700 as discussed with respect to FIG. 6A and FIG. 6B. Note that the last three lines of FIG. 7 correspond to the lines in output 608 of FIG. 6B.

In operation, rows may be programmatically added to table 700 by the IT services provider using a configuration tool, such as the configuration script 600. Rules may be executed when rows are added and/or deleted from the table 700 that automatically create routing rules in the IT services provider environment and/or the customer environment. For example, the application 102-G and/or the database 110-A may include instructions that trigger various network configuration operations (e.g., create firewall rules, port forwarding rules, create/destroy tunnels, etc.) when the table 700 is modified. In this way, an operator at the IT services provider may merely modify the table, and the rules may be automatically propagated to local devices and the customer's devices. Many flexible configurations are envisioned.

For example, the customer may have a Microsoft Windows computer located in the customer's computing environment, such as one of the customer devices depicted in the customer infrastructure 404 of FIG. 4. The Windows computer may need to retrieve patches periodically for the purpose of securing and/or updating the operating system. The IT services provider may want to manually initiate such an update on behalf of the customer in performance of the IT services provider's duties under an IT services contract. As discussed above, historically, the IT services provider would need to contact the customer via telephone, email or some other means to request that the customer adjust the customer's firewall rules to allow the Windows computer to access a patch server. The patch server may be provided by a Microsoft, for example, or by the IT services provider. Traditionally, in a large corporation, the IT services provider may need to constantly contact the customer with such firewall management requests, which may prove burdensome over time and strain the resources of the customer.

Referring again to FIG. 7, the present techniques allow the IT services provider to add a new row to the table 700, without the need to involve the customer at all, or to access any particular devices in the customer's infrastructure. For example the IT services provider may add a new line which includes a BMN of the customer, a local socket address corresponding to the Windows patch server, and an end system socket address corresponding to the customer's Windows computer needing upgrades/patching. When the Windows computer seeks to connect to a patch server, a request is forwarded by the avatar in the customer's environment to the customer's BMN at a particular port number, and wherein the BMN then forwards the request to a patch server. The table 700 provides for both forward and reverse proxying, wherein forward proxying allows the IT services provider to access the customer's environment, and reverse proxying allows the customer to access services provided by the IT services provider, as discussed with regard to the patching server example. It should be appreciated that many other centrally-managed systems are possible. These include monitoring, email services, etc. The IT services management provider may locate the managed systems in any suitable management environment, such as in different data centers selected from data center 202-1 through data center 202-l.

The present techniques allow thousands of firewall rules to be determined in a central port forwarder (e.g., central port forwarder 302-D), wherein the firewall rules are driven by the routing database and are not manually programmed. Aspects of the present invention (e.g., the application 102-G) may include instructions that when executed analyze the table 700 and heal any broken rules. For example, a rule having an end system socket address that is nonexistent in the customer's infrastructure may be pruned from the database. As applications are added to the BMN of the customer, rules may be automatically generated.

In some embodiments, the services that the IT services provider publishes for the customer's access via reverse proxying techniques may allow access to the Internet. For example, a third-party company device (e.g., a Cisco Smart Net Total Care appliance) may be configured to forward connections to the customer's BMN, wherein the BMN is also configured to forward requests to the third-party company.

Additional Example Embodiments

In an embodiment, the present techniques enable the IT services provider to project resources into the customer's environment. For example, the customer may opt in to IT services management and, as discussed above, a hardware or software appliance may be deployed by the customer. The avatar, which may be an avatar device as described above, may include instructions that when executed enumerate other devices in the customer's environment by probing the customer's network infrastructure. As long as the customer has an active service contract with the IT services provider, the avatar may remain in place. The IT services provider may develop a new service. The new service may be deployed to the customer, as well as a set of other customers who have similar service contracts. Some of the service contracts include field services, long-term service engagement, and temporary service engagements. For example, when engineers go on vacation, other engineers may take over for the vacationing engineers without the need to provide physical access to the other engineers.

In some embodiments, third parties may be provided via the present techniques. For example, the IT services provider may contract with a third party that provides a third party service. The third-party service may be a specialized service that is a branded service. As discussed with respect to FIG. 4D, the third-party service may be a service that is a licensed software tool. In other embodiments, the third-party service may be a web service or API. In each case, the third-party service may be provided for access to the customer via a tunnel, and to the customer, the third-party service may appear identical to and/or indistinguishable from services provide by the IT services provider directly.

In some embodiments, the present techniques may allow unified communication. For example, the IT services provider may traditionally permit field engineers to download field tools to devices that they use to service customer devices. The field tools may accept input particular to the customer from engineers, and may then build a specific software package for the customer. Unfortunately, historically, individual field tools must be maintained for each separate software platform (i.e., separate tools for Windows, Linux, Mac OSX, etc.), adding expense and delay. Using the present techniques, tunnels may be developed to allow field engineers to use field tools via a tunnel, and to deploy the software package for the customer's access via a link between the IT services provider's computing environment and the customer's computing environment. When the customer wants to access the software package, the customer may access the software package. In this way, development resources are optimized, and the field tools are always current and create builds with the latest software. Also, the field tools remain in the IT services provider's control, obviating some security issues and allowing the software to be managed at scale. Once the customer has accessed the software package, the customer's access can be deactivated. The tools that the field engineers need to be included in their devices are also reduced.

In an embodiment, the present techniques enable the IT services provider to monitor software installed in the customer's computing environment for software licensing purposes. For example, a VM of the customer may include a set of licensed software. The IT services provider may query the customer's environment in real-time and may determine that the licensed software is present from the environment, or a list of which software is present. In some embodiments, the IT services provider may transmit a list of customer equipment and/or licensed software to a third-party licensor. The IT services provider may receive from the third-party licensor an indication of whether the equipment and/or licensed software is under warranty, is at its end-of-life, and/or contains any security vulnerabilities. Based on the indications, the IT services provider may query a database of available upgrades, and may transmit an indication to the customer identifying the available upgrades. The customer may be allowed to select one or more upgrades to be automatically applied to the customer's computing environment by the IT services provider via the present techniques. In some embodiments, an overall health of the customer's environment may be determined by the IT services provider. The health may be expressed as a percentage, such as the percentage of devices and/or software within the customer's environment that are currently supported. The IT services provider may generate sales opportunities by providing the customer with a report of the health, along with recommendations for increasing the health of the environment.

In some embodiments, the ability of the IT services provider to enumerate the devices and software in the customer's environment in real-time may allow the IT services provider to track end-of-sale, end-of-life, out of warranty, and product recall information. The IT services provider may also analyze the customer's environment to facilitate support contract renewal. Further, all of the information related to analyzing the customer's computing environment may reside in systems controlled by the IT services provider, such as the remote computing device 102. The remote computing device 102 may be a monitoring collector. The monitoring collector may retrieve information relating to the attributes of computers in the customer's environment (e.g., that a hard drive of a laptop computer is 95% full) for equipment inventory and/or remediation. The monitoring collector may retrieve data (e.g., a serial number, part number, etc.) via the BMN. In this way, the monitoring collector may be separated from critical customer infrastructure that is directly or indirectly communicating with the customer's environment. Such separation allows data retrieved by the monitoring collector to be stored indefinitely, and allows for the computational resources of the monitoring collector to be adjusted independent of the BMN.