Location services
Dustin Amrhein
I really like the pCard concept. One question just for clarification.
If I had a payload that had to run/store data in a certain
geographical region for whatever reason, do you see that requirement
expressed within layer 3 or layer 4 because I could see it either way.
jamesurquhart
Layer 3 (the "deployment" section) is about initial state. Thus if the
data had to be placed in a specific geographic region (or a few
specific regions) to start with, you would describe that condition
there.
Layer 4 (the "runtime" or "SLA" section) is about rules to operate the
system. Thus, if the data needed to moved around due to one
*operational* condition or another (not sure why), you'd describe the
rules in Layer 4.
If the application needed to partition data, or move data around
within existing deployments, it would be described in one way or
another as a part of the application, and not explicitly described in
the pCard.
Thoughts?
James
Dustin Amrhein
operational (#4), but thanks for clarifying.
Seems to me your last statement really boils down to what the pCard
shouldn't attempt to do.
In this case, application configuration is not a part of the pCard.
Did I miss something?
jamesurquhart
Application architecture likely should be described as a part of
pCard. (Not sure how, yet. Perhaps not explicitly?)
Application configuration dependencies, such as the executables and
services required to support application configuration MIGHT need to
be a part of the pCard (e.g. "my application requires a Linux image
with the following Chef and the following recipes installed").
Application configuration scripting, policies or properties are
usually NOT a part of the pCard.
Application SLA requirements (target values for specific metrics or
policies(?) to be supported) should be described as a part of pCard.
Custom application SLA scripts, etc. to calculate metric values, etc.
need not be a part of pCard.
That's my thinking, though it's vagueness shines a spotlight on now
much I haven't figured out yet...
James
Dustin Amrhein
I think there's going to be a fine line on what part of the
application configuration makes it into the pCard and what doesn't. I
guess when I said application configuration above I mainly meant
configuring the internal behavior of the application. I think that's
going to be important to keep out of the pCard as much as possible
(probably obvious, but also it would probably be easy to cross the
line and have some of that information start leaking into the pCard).
Rodos
are going to pass the info around to lots of people and you want at
this stage have a low level of trust. "Hey, could you run this
workload for me if I wanted you to." Once you agree to hand over the
workload you are moving into a new trust zone and can share a lot more
details about the workload.
Rodos
jamesurquhart
If you think about it, passing the bits around is a big FAIL:
- You may be handing data to untrusted source
- You may be handing code to untrusted source (see concerns about
China in this regard)
- You may be giving away a classified purpose for the application
- The size of the package may be huge, and sending the whole thing
just to see if it can be served by the provider is a big waste
Furthermore, finding a home for an app simply by running queries
against a wide variety of service catalogs is also suboptimal from the
app owner's perspective:
- Puts the onus for analysis logic on the consumer, not the provider
- Without a standard catalog format, querying a diverse provider base
is expensive
- With a standard catalog format, breaking a request down into
individual API calls is relatively expensive
The beauty of pCard is that it allows a system to generate one
description of the payload(s), and then put the onus for analysis of
applicability to any given service on the provider and (possibly)
their chosen service catalog system.
The security point is key, though, Rodos. Nice observation.
James