Note: Descriptions are shown in the official language in which they were submitted.
CA 02935352 2016-07-06
s
MULTI-CLOUD NETWORK PROXY FOR CONTROL AND NORMALIZATION OF TAGGING DATA
INVENTORS:
Catherine Wood
Technical Field
[001] This application relates to centralized control over tagging data
applicable to
technical components, such as virtual machines and other resources, which may
be
provisioned into a complex global network architecture of virtualized
resources.
Background
[002] The processing power, memory capacity, network connectivity and
bandwidth,
available disk space, and other resources available to processing systems have
increased exponentially in the last two decades. Computing resources have
evolved to
the point where a single physical server may host many instances of virtual
machines
and virtualized functions. These advances had led to the extensive
provisioning of a
wide spectrum of functionality for many types of entities into specific
pockets of
concentrated processing resources that may be located virtually anywhere. That
is, the
functionality is relocated into a cloud of processing resources handling many
different
clients, hosted by many different service providers, in many different
geographic
locations. Improvements in multiple cloud system control will facilitate the
further
development and implementation of functionality into the cloud.
BRIEF DESCRIPTION OF THE DRAWINGS
[003] Figure 1 shows an example of a global network architecture.
1
CA 02935352 2016-07-06
. =
[004] Figure 2 illustrates an example implementation of a multi-cloud network
proxy.
[005] Figure 3 shows an example of resource and metadata discovery.
[006] Figure 4 shows a logical flow for discovery.
[007] Figure 5 shows a metadata control interface for controlling metadata tag
identifiers.
[008] Figure 6 shows a metadata control interface for controlling metadata tag
content.
[009] Figure 7 shows a metadata control interface for metadata tag
synchronization.
[010] Figure 8 shows logical flow for controlling metadata tag identifiers and
metadata
tag content.
[011] Figure 9 shows a logical flow for metadata tag synchronization.
[012] Figure 10 shows a technical component request interface.
[013] Figure 11 shows a logical flow for generating a technical component
request
interface.
DETAILED DESCRIPTION
[014] Effectively provisioning and ensuring the proper operation of computing
resources in the cloud is a significant technical challenge. New cloud service
providers
regularly emerge, each offering different target hosting platforms, supporting
disparate
services, assets, supported technical components, and other features. The
multi-cloud
network proxy described below controls and facilitates normalization of the
metadata
tag identifiers and metadata tag content attached to the technical components
hosted
across multiple target hosting platforms by many different service providers.
The
network proxy provides a central control mechanism for discovering,
monitoring, and
updating complex tagging data applied to the technical components provisioned
with the
cloud service providers, regardless of whether any given service provider
natively
supports metadata tagging. The network proxy also dynamically generates
technical
component request interfaces (e.g., to request provisioning of a new resource)
that
include specifically prioritized metadata tags.
2
CA 02935352 2016-07-06
=
[015] Figures 1 and 2 provide an example context for the discussion below of
technical
solutions for complex metadata tagging and control. The examples in Figures 1
and 2
show one of many possible different implementation contexts. In that respect,
the
technical solutions are not limited in their application to the architectures
and systems
shown in Figures 1 and 2, but are applicable to many other cloud computing
implementations, architectures, and connectivity.
[016] Figure 1 shows a global network architecture 100. Distributed through
the global
network architecture 100 are cloud computing service providers, e.g., the
service
providers 102, 103, 104, 106, and 108. The service providers may be located in
any
geographic region, e.g., United States (US) East, US West, or Central Europe.
The
geographic regions that characterize the service providers may be defined
according to
any desired distinctions to be made with respect to location. A service
provider may
provide cloud computing infrastructure in multiple geographic locations.
[017] The service providers may provide computing resources via hosting
platforms
that are generally publicly available. Service providers may additionally or
alternatively
provide computing resources in "on-premises" hosting platforms, which
typically refers
to a location with increased privacy and security compared to public cloud
resources.
An on-premise location may be within a secure facility owned by an enterprise
which
has moved computing functionality to a cloud based implementation, for
instance.
Examples of service providers include Amazon, Google, Microsoft, and
Accenture, who
offer different target hosting platforms, e.g., Amazon Web Services (AWS),
Google
Compute Engine (GCE), Microsoft Azure (Azure), Accenture Cloud Platform (ACP),
and
Windows Azure Pack (VVAP) for on-premise cloud implementations, as just a few
examples.
[018] Throughout the global network architecture 100 are networks, e.g., the
network
110, that provide connectivity within the service providers and between the
service
providers and other entities. The networks 110 may include private and public
networks
defined over any pre-determined and possibly dynamic internet protocol (IP)
address
ranges. A multi-cloud network proxy (MNP) 112 makes complex cloud
architectural
3
CA 02935352 2016-07-06
,
provisioning and execution decisions across multiple cloud services, taking
into account
the global network architecture 100, the various service provider locations
and
capabilities, and other factors. The metadata tagging and dynamic technical
component
request interface aspects of the MNP 112 are described in more detail below.
[019] As an overview, the MNP 112 may include a metadata tagging repository
114
configured to, among other functions, store, analyze, and manipulate metadata
tags for
technical components, e.g., VMs, networks, disk images, and a wide range of
other
types and assets, provisioned in any of the target hosting platforms. A 'type'
may refer
to a managed object, and technical components, such as types and assets,
provisioned
into a region hosted by a resource provider or service provider may be
referred to as
'resources'. A 'region' may refer to a unit of hosting capacity in a
particular geographic
region, where types may be deployed. Another aspect of MNP 112 is the proxy
circuitry
116 that is configured to locally maintain metadata tags regardless of whether
any
particular target hosting platform natively supports metadata tagging.
Metadata 152,
including metadata tag identifiers and metadata tag content, also flows
between the
MNP 112, the enterprise 150, and the service providers and their target
hosting
platforms.
[020] The MNP 112 also includes operator control circuitry 118. The operator
control
circuitry 118, among other functions, is configured to generate metadata
tagging control
interfaces for adding, changing, and deleting the metadata tag identifiers and
the
metadata tag content. The operator control circuitry 118 may also accept
designations
of prioritized or specifically managed metadata tags from among the many
possible
metadata tag identifiers. In addition, the operator control circuitry 118
dynamically
generates a technical component request interface. The request interface
facilitates
enterprise submission functionality requests 154 for new technical components
to be
provisioned into a particular target hosting platform. The technical component
request
interface adapts to the prioritized metadata tags by including the prioritized
tags and
providing content entry fields for those tags.
4
CA 02935352 2016-07-06
[021] Each service provider has a widely varying set of technical
characteristics in the
individual target hosting platforms. For instance, Figure 1 shows a target
hosting
platform implemented by a data center 124 for the service provider 108. The
data
center 124 supports running many different virtual machines (VMs), each
potentially
running many different virtual functions (VFs). The data center 124 may
include a high
density array of network devices, including routers and switches 126, and host
servers
128. The host servers 128 support a particular set of computing functionality
offered by
the service provider 108 from the data center 124.
[022] As just one of many examples, the service provider 108, through the data
center
124 and its other infrastructure, may support many different types of virtual
machines,
differing by number of processors, amount of RAM, and size of disk, graphics
processors, encryption hardware, or other properties; multiple different types
of web
front ends (e.g., different types and functionality for websites); several
different types of
database solutions (e.g., SQL database platforms); secure data storage
solutions, e.g.,
payment card industry (PCI) data (or any other secure data standard) compliant
storage; several different types of application servers; and many different
types of data
tiers. Further, the service provider 108 and the data center 124 may have
further
characteristics, including whether the data center 124 is an on-premise or
public
location; which networks can provide connectivity to the data center 124;
which assets
the service provider 108 supports; and other characteristics.
[023] Figure 2 shows an example implementation of the MNP 112. The MNP 112
includes communication interfaces 202, system circuitry 204, input/output
(I/O)
interfaces 206, and a display circuitry 208 that generates user interfaces 210
locally or
for remote display, e.g., in a web browser running at the enterprise 150. The
user
interfaces 210 and the I/O interfaces 206 may include graphical user
interfaces (GUIs),
touch sensitive displays, voice or facial recognition inputs, buttons,
switches, speakers
and other user interface elements. Additional examples of the I/O interfaces
206
include microphones, video and still image cameras, headset and microphone
input /
output jacks, Universal Serial Bus (USB) connectors, memory card slots, and
other
CA 02935352 2016-07-06
types of inputs. The I/O interfaces 206 may further include magnetic or
optical media
interfaces (e.g., a CDROM or DVD drive), serial and parallel bus interfaces,
and
keyboard and mouse interfaces.
[024] The communication interfaces 202 may include wireless transmitters and
receivers ("transceivers") 212 and any antennas 214 used by the transmit and
receive
circuitry of the transceivers 212. The transceivers 212 and antennas 214 may
support
WiFi network communications, for instance, under any version of IEEE 802.11,
e.g.,
802.11n or 802.11ac. The communication interfaces 202 may also include
wireline
transceivers 216. The wireline transceivers 216 may provide physical layer
interfaces
for any of a wide range of communication protocols, such as any type of
Ethernet, data
over cable service interface specification (DOCSIS), digital subscriber line
(DSL),
Synchronous Optical Network (SONET), or other protocol.
[025] The system circuitry 204 may include any combination of hardware,
software,
firmware, or other logic. The system circuitry 204 may be implemented, for
example,
with one or more systems on a chip (SoC), application specific integrated
circuits
(ASIC), microprocessors, discrete analog and digital circuits, and other
circuitry. The
system circuitry 204 is part of the implementation of any desired
functionality in the
MNP 112. As just one example, the system circuitry 204 may include one or more
instruction processors 218 and memories 220. The memory 220 stores, for
example,
control instructions 222 and an operating system 224. The processor 218
executes the
control instructions 222 and the operating system 224 to carry out any desired
functionality for the MNP 112. The control parameters 226 provide and specify
configuration and operating options for the control instructions 222,
operating system
224, and other functionality of the MNP 112.
[026] The MNP 112 also includes volume storage devices, e.g., hard disk drives
(HDDs) and solid state disk drives (SDDs). The storage devices may define and
store
databases that the control instructions 222 access, e.g., through a database
control
system, to perform the functionality implemented in the control instructions
222. In the
example shown in Figure 2, the databases include a metadata tag identifier
database
6
CA 02935352 2016-07-06
. .
228, a metadata tag content database 230, and a resource database 246. The
metadata tag identifier database 228 and metadata tag content database 230 are
logically grouped into a proxy metadata tagging repository 232 for maintaining
key/value
pairs for metadata characterizing resources deployed into the target hosting
platforms.
In other implementations, any of the databases may be part of a single
database
structure, and, more generally, may be implemented logically or physically in
many
different ways. Each of the databases 228, 230, 246 defines tables storing
records that
the control instructions 222 read, write, delete, and modify to perform the
processing
noted below.
[027] The system circuitry 204 may implement the proxy circuitry 116 and the
operator
control circuitry 118, e.g., as control instructions 222 executed by the
processor 218.
The control instructions 222 implement a central proxying control 234 for
discovering,
monitoring, updating, and proxying complex tagging data applied to the
technical
components provisioned with the cloud service providers. The control
instructions 222
also implement an operator control 236 that dynamically generates technical
component
request interfaces that include specifically prioritized metadata tags.
[028] Figure 2 also shows several of the service providers. Note that the
service
provider 108 has established a target hosting platform via the data center
124. The
target hosting platform supports local metadata tagging. To that end, the
target hosting
platform defines a provider-controlled metadata tagging repository 238,
including a
locally (with respect to the target hosting platform) controlled metadata tag
identifier
database 240 and a locally controlled metadata tag content database 242. In
connection with native metadata tagging, the target hosting platform may
implement its
own interface console through which the enterprise 150 may establish and
modify
metadata tags for virtual resources. In contrast, the service provider 102
has
established a target hosting environment 244 that does not include native,
provider-
controller metadata tagging. Various service providers may or may not
implement local
metadata tagging, and their metadata tagging capabilities may change over
time.
[029] Multi-Cloud Network Proxy with Centralized Resource Tagging Control
7
CA 02935352 2016-07-06
[030] The MNP 112 controls and facilitates normalization of the metadata tag
identifies
and metadata tag content attached to the technical components hosted in the
various
target hosting platforms by the service providers. The MNP 112 performs this
role
regardless of whether any particular target hosting platform natively supports
metadata
tagging. In that regard, the MNP 112 maintains the proxy metadata tagging
repository
232 as a centralized source of metadata tagging information. Further, the MNP
112
may store provider capability specifiers (e.g., as data fields in a database,
program
instructions, program variables, or parameter files) that indicate whether any
given
target hosting platform natively supports metadata tagging.
[031] Figure 3 shows an example of resource and metadata discovery 300 by the
MNP
112, and Figure 4 shows a corresponding logical flow 400. In support of its
multi-cloud
metadata control role, the MNP 112 implements resource discovery, and, to the
extent
supported by a given target hosting environment, metadata discovery. The MNP
112
may, for instance, connect through service provider application programming
interfaces
(APIs) 302, 304, and 306 to transmit discovery request messages 308, 310, 312
to the
target virtual hosting platforms 314, 316, and 318 of the service providers
102, 106, and
108 respectively (402). The discovery messages specify a request for the
target
hosting platform to return identifiers of each resource deployed in the target
virtual
hosting platform for a given enterprise 150, specific enterprise project, user
identifier, or
at some other specified level of granularity. The MNP 112 receives discovery
responses 320, 322, and 324 enumerating the resources as a result of
transmitting the
discovery request messages 308, 310, 312 (404).
[032] The discovery may include obtaining access credentials 326, e.g. logon
username / password from an account owner at the enterprise 150. The MNP 112
submits the access credentials to the corresponding service provider to access
and
request the resources and attached metadata (if any) for the resources.
[033] The MNP 112 updates its resource database 246 according to the resource
discovery responses. For instance, the MNP 112 may add newly discovered
resources
8
CA 02935352 2016-07-06
and remove deleted resources, according to the current state provided in the
resource
discovery responses.
[034] The MNP 112 also engages in metadata discovery for the resources
provisioned
in the target hosting platforms. In one implementation, the MNP 112 is
configured to
call the APIs provided by a service provider to obtain metadata tagging
information.
Accordingly, when the service provider supports native metadata tagging and
has
defined such an API, then the MNP 112 may transmit metadata discovery requests
328
to the target hosting platforms (408). The metadata discovery messages request
the
target hosting platform to return metadata tag identifiers and metadata tag
content
stored remotely in the provider-controlled metadata tagging repository. The
MNP 112
receives the metadata discovery responses 330 (410).
[035] The MNP 112 facilitates centralized proxy control by updating the
metadata tag
identifiers and metadata tag content locally in the proxy metadata tagging
repository
232 (412). The metadata tag identifiers and metadata tag content may drive
other
processes within the MNP 112 (414), such as the generation of interactive
metadata
tagging control interfaces and driving dynamic adaptation to technical
component
request interfaces. For example, the MNP 112 (as described further below) may
add
specifically identified metadata tag identifiers and tag content fields to
technical
component request interfaces.
[036] The updates may include adding, modifying, and deleting metadata tag
identifiers
and adding, modifying, and deleting metadata tag content for the associated
metadata
tag identifiers. In that regard, the MNP 112 may implement a metadata
synchronization
ruleset 248 to determine how to process differences between the metadata
obtained
from the target hosting platform and the metadata currently in the proxy
metadata
tagging repository 232. For instance, the metadata synchronization ruleset 248
may
direct the MNP 112 to overwrite the metadata tag content in the proxy metadata
tagging
repository 232 with the metadata tag content returned from the target hosting
platform,
e.g.,: in all cases, when the proxy metadata tagging repository 232 has no
content
values yet, or when other conditions are met. As another example, the metadata
9
CA 02935352 2016-07-06
synchronization ruleset 248 may specify obtaining a decision from the
enterprise 150
whether to overwrite, or may specify to never overwrite existing metadata tag
content in
the proxy metadata tagging repository 232. In other implementations, the
metadata
synchronization ruleset 248 specifies whether the proxy metadata tagging
repository
232 or the provider-controlled metadata tagging repository is the
authoritative version of
the baseline metadata. That is, synchronization may occur from the proxy
metadata
tagging repository 232 to the provider-controlled metadata tagging repository,
or vice-
versa.
[037] The MNP 112 may execute discovery as desired. For instance, the MNP 112
may execute discovery on a regular schedule for all accounts or selected
accounts. As
another example, the MNP 112 may execute discovery in response to event
triggers.
One example of an event trigger is registration of a service provider account
within the
MNP 112. In response to the registration, the MNP 112 may log the account and
execute discovery to find, e.g., the servers, networks, and related resources
that
already exist in the service provider account. Another example of an event
trigger is
when an operator activates a GUI link for executing discovery.
[038] Expressed another way, the MNP 112 may include a communication interface
operable to establish a data connection with a target virtual hosting
platform. The MNP
112 establishes a primary metadata tagging repository for technical components
hosted
by the target virtual hosting platform. The metadata tagging repository stores
a
metadata tag identifier set and a metadata tag content set linked to the
metadata tag
identifier set.
[039] The MNP 112 executes proxy circuitry coupled to the communication
interface
and the metadata tagging repository. The proxy circuitry configured to make a
determination of whether the target virtual hosting platform provides metadata
tag
capture capability, synchronize metadata tag identifiers to the metadata tag
identifier
set in the primary metadata tagging repository, and synchronize metadata tag
content to
the metadata tag content set in the primary metadata tagging repository.
Furthermore,
the proxy circuitry dynamically buffers the metadata tag identifiers and
metadata tag
CA 02935352 2016-07-06
content, when the determination is that the metadata tagging repository
provides
metadata tag capture capability, by transmitting an instruction message over
the data
connection to direct the virtual hosting platform to synchronize its provider
metadata
tagging repository to the metadata tag identifiers and the metadata tag
content.
Synchronization may include adding, deleting, or modifying metadata tag
identifiers and
metadata tag content according to a metadata synchronization ruleset 248, as
noted
above.
[040] Figure 5-7 show examples of many possible variations of metadata control
interfaces. Figure 8 shows a corresponding logical flow 800 for controlling
metadata tag
identifiers and metadata tag content.
[041] Figure 5 shows a metadata tagging control interface ("control
interface") 500. In
particular, the MNP 112 generates the control interface 500 (802) to
facilitate adding,
deleting, and renaming new metadata tags, and to facilitate synchronizing
metadata
tags to target hosting platforms. In this example, the control interface 500
includes tag
search filters 502 by resource type, client, and project (804). The matching
metadata
tags appear in the metadata tag window 504, along with the metadata tag
identifiers
506 and prioritization fields 508 (806). The prioritization fields 508 allow
the operator to
choose whether any given metadata tag is one of particular relevance (808). If
so, the
MNP 112 may include the prioritized metadata tag in the synchronization of
metadata
tags noted above. In other implementations, the MNP 112 may include the
prioritized
metadata tags and content fields on technical component request interfaces.
[042] The control interface 500 also includes an actions window 510. The MNP
112
populates the actions window 510 with metadata control options. One control
option is
the Modify Tag control 512. Responsive to activation of the Modify Tag control
512, the
MNP 112 performs metadata tag addition, deletion, or renaming according to
further
operator input. The MNP 112 may then responsively update the proxy metadata
tagging repository 232 (810), e.g., by creating a new metadata tag and
inserting it into
the proxy metadata tagging repository 232.
11
CA 02935352 2016-07-06
[043] Figure 6 shows a metadata tagging control interface ("control
interface") 600. In
particular, the MNP 112 generates the control interface 600 (812) to
facilitate adding,
deleting, and changing metadata tag content. In this example, the control
interface 600
also includes tag search filters 602 by resource type, client, and project
(814). The
MNP 112 retrieves the matching metadata tags and their metadata tag content,
if any is
currently set, from the proxy metadata tagging repository 232 and populates
the
metadata tag window 604 (816). The MNP 112 generates a provider field 606 to
indicate the provider to which the metadata tag applies, a metadata tag
identifier field
608 to name the metadata tag, and a metadata content field 610 to show the
current
value, if any, of the metadata tag. The MNP 112 may limit the displayed
metadata tags
to only those tagged designated as prioritized tags. The control interface 600
accepts
inputs to the metadata content fields 610 to add, delete, and change metadata
tag
values, which the MNP 112 saves in the proxy metadata tagging repository 232
(818).
Tag content synchronization to the service provider may occur when directed by
the
enterprise 150, e.g., via the Synchronize Tag option 514 described below, at
pre-
scheduled times, in response to specific trigger conditions, or at other times
or for other
reasons.
[044] The MNP 112 controls metadata locally through its proxy metadata tagging
repository 232. As a result, the MNP 112 may store, maintain, and manipulate
metadata tags for target hosting platforms that do not natively support
metadata
tagging. That is, the MNP 112 acts as a proxy for metadata tagging, and
thereby
provides a centralized control mechanism across all target hosting platforms
for
metadata tagging.
[045] Another control option in the control interface 500 is the Synchronize
Tag option
514. Figure 7 shows an example metadata tag synchronization control interface
("control interface") 700 and Figure 9 shows a corresponding location flow
900. The
MNP 112 generates the control interface 700 (902). In this example, the
control
interface 700 includes a credentials window 702 and a resource details window
704.
The credentials window may accept login name and password information, for
instance,
12
CA 02935352 2016-07-06
with which the MNP 112 connects to a particular target hosting platform (904).
The
resource details window 704 provides input fields 706 for provider, location,
and
resource type. The input fields 706 allow the operator to specify which types
of
resources to synchronize at which provider and which provider location (906).
[046] An operation selector 708 allows the operator to specify which type of
discovery
operation the MNP 112 will perform (908). In response to the Discover option,
the MNP
112 establishes a data connection to the target hosting platform (910) and
issues
discovery requests for resources, and, if supported by the target hosting
platform,
discovery requests for the metadata tags and metadata tag content attached to
the
resources. The MNP 112 updates the proxy metadata tagging repository 232 with
the
discovered metadata tag identifiers and metadata tag contents (914).
[047] In response to the Update option, the MNP 112 establishes a data
connection to
the target hosting platform (916) and transmits the metadata tags and metadata
content
currently in the proxy metadata tagging repository 232 to the specified target
hosting
platform to perform synchronization (918). To push the data, the MNP 112 may
call,
e.g., APIs provided by the target hosting platform. In some implementations,
the MNP
112 may limit the pushed metadata to those metadata tags marked as prioritized
metadata tags. In addition, the operation selector 708 provides a combined
option to
both discover and update metadata tags.
[048] Dynamic Technical Component Request Interfaces
[049] In addition to centralized metadata control, the operator control
circuitry 118 in
the MNP 112 supports provisioning new resources to a target hosting platform.
In that
regard, the operator control circuitry 118 may generate resource request
interfaces
through which the enterprise 150 interacts to specify resource type,
placement, account,
and other elements that characterize a new resource to be provisioned.
[050] Figure 10 shows an example technical component request interface
("request
interface") 1000. The enterprise 150 interacts with the request interface 1000
to submit
a request for a new resource to provision to a target hosting environment.
Figure 11
shows a corresponding logical flow 1100 for generating a technical component
request
13
CA 02935352 2016-07-06
interface. As described in more detail below, the MNP 112 supports
customization of
the request interface 1000 responsive to the metadata control features
described
above.
[051] In particular, as explained above, the MNP 112 obtains designations of
prioritized
metadata tags. In response to an enterprise 150 requesting provisioning of a
new
resource (1102), the MNP 112 may generate the request interface 1000 (1104).
For
purposes described further below, the MNP 112 also determines which of the
metadata
tags are designated as the prioritized metadata tags (1106).
[052] The MNP 112 generates the request interface 1000 with baseline resource
request content 1002 and dynamic resource request content 1004. For the
baseline
resource request content 1002, the MNP 112 generates content that is static
across
multiple different technical component request interfaces (1108) and that is
relevant to
ordering a particular type of virtualized resource. In the example in Figure
10, the
baseline resource request content 1002 includes parameter fields 1006 that are
consistent across multiple different requests for resource provisioning. The
baseline
resource request content 1002 may be present on each request interface for a
new VM
for a given service provider, for instance. Baseline request content may vary
widely
from implementation to implementation. Some examples of baseline resource
request
content may include: customer information, such as login ID and email address;
client/project information, including client name, project name, and billing
identifier; and
account and server details, such as an account name, subscription name,
subscription
identifier, provider location or region, network, disk image, username,
password, and
resource size.
[053] For the dynamic resource request content 1004, the MNP 112 adds resource
request content to the request interface 1000 that is variable and that is
also relevant to
ordering a particular virtualized type of resource. In the example in Figure
10, the
dynamic resource request content 1004 includes metadata tag identifiers 1008
and
metadata tag content fields 1010. The MNP 112 selects metadata tags for
inclusion, as
dynamic resource request content 1004, that have been designated as
prioritized
14
CA 02935352 2016-07-06
metadata tags (as also shown in Figure 5). For instance, when the enterprise
150 is
requesting a new VM hosted by the Red service provider, the MNP 112 may add to
the
request interface the metadata tags previously designed as prioritized for VMs
for the
Red service provider. The same is true for resources of other types. In other
words,
the MNP 112 dynamically generates a request interface including metadata tags
designated as prioritized for that resource and for that service provider.
[054] The prioritized metadata tags may vary over time, and they often
represent the
metadata tags that the operator has selected to track most closely. As a
result, the
MNP 112 generates a request interface 1000 that is more efficient and
effective for the
enterprise 150. In particular, the request interface 1000 gives the enterprise
150 a head
start in defining and characterizing the new resource with respect to the
closely tracked
metadata. Furthermore, the MNP 112 acts as a centralized metadata control
system
regardless of whether any given service provider natively supports metadata
tagging.
That is, the MNP 112 may locally maintain the metadata tags and metadata
content for
the new resource in the proxy metadata tagging repository 232, regardless of
whether
the target hosting platform can receive and store the metadata tagging content
entered
into the request interface 1000.
[055] Note that in that regard, the MNP may also generate a provider
synchronization
selector 1012 as part of the dynamic resource request content 1004 (1112) If
the
enterprise 150 proceeds with resource placement, then the MNP 112 stores the
metadata tag content that was entered into the request interface 1000 into the
proxy
metadata tagging repository (1114, 1116). The MNP 112 also initiates
provisioning, by
the virtual hosting platform, of the resource as specified in the request
interface 1000
(1118, 1120).
For resources for which the enterprise 150 has selected the
synchronization option on the request interface 1000, the MNP 112 initiates
the
provisioning, also including the dynamic request content. In one
implementation, the
MNP 112 provides the dynamic request content with provisioning by transmitting
(e.g.,
via API calls), to target hosting platform, the metadata tag identifiers and
metadata tag
contents entered into the request interface 1000.
CA 02935352 2016-07-06
[056] The methods, devices, processing, circuitry, and logic described above
may be
implemented in many different ways and in many different combinations of
hardware
and software. For example, all or parts of the implementations may be
circuitry that
includes an instruction processor, such as a Central Processing Unit (CPU),
microcontroller, or a microprocessor; or as an Application Specific Integrated
Circuit
(ASIC), Programmable Logic Device (PLD), or Field Programmable Gate Array
(FPGA);
or as circuitry that includes discrete logic or other circuit components,
including analog
circuit components, digital circuit components or both; or any combination
thereof. The
circuitry may include discrete interconnected hardware components or may be
combined on a single integrated circuit die, distributed among multiple
integrated circuit
dies, or implemented in a Multiple Chip Module (MCM) of multiple integrated
circuit dies
in a common package, as examples.
[057] Accordingly, the circuitry may store or access instructions for
execution, or may
implement its functionality in hardware alone. The instructions may be stored
in a
tangible storage medium that is other than a transitory signal, such as a
flash memory,
a Random Access Memory (RAM), a Read Only Memory (ROM), an Erasable
Programmable Read Only Memory (EPROM); or on a magnetic or optical disc, such
as
a Compact Disc Read Only Memory (CDROM), Hard Disk Drive (HDD), or other
magnetic or optical disk; or in or on another machine-readable medium. A
product,
such as a computer program product, may include a storage medium and
instructions
stored in or on the medium, and the instructions when executed by the
circuitry in a
device may cause the device to implement any of the processing described above
or
illustrated in the drawings.
[058] The implementations may be distributed. For instance, the circuitry may
include
multiple distinct system components, such as multiple processors and memories,
and
may span multiple distributed processing systems. Parameters, databases, and
other
data structures may be separately stored and controlled, may be incorporated
into a
single memory or database, may be logically and physically organized in many
different
ways, and may be implemented in many different ways. Example implementations
16
CA 02935352 2016-07-06
include linked lists, program variables, hash tables, arrays, records (e.g.,
database
records), objects, and implicit storage mechanisms. Instructions may form
parts (e.g.,
subroutines or other code sections) of a single program, may form multiple
separate
programs, may be distributed across multiple memories and processors, and may
be
implemented in many different ways. Example implementations include stand-
alone
programs, and as part of a library, such as a shared library like a Dynamic
Link Library
(DLL). The library, for example, may contain shared data and one or more
shared
programs that include instructions that perform any of the processing
described above
or illustrated in the drawings, when executed by the circuitry.
[059] Various implementations have been specifically described. However, many
other
implementations are also possible.
17
