SLA
Abhijit
Service Level Agreement is very crucial in the step of moving to
cloud.
Can we have a discussion over this SLA.
My inputs are as
SLA - Are the technocommercial agreement between the Cloud
Consumer and the Cloud Provider. It ensures the services provided by
the Service (Cloud) provider.
Following points needs to be incorporated
1. Service Unavailability Target - It gives the idea for the time
period for which the service would be unavailable. A typical service
provider gives and availability targeet of 99.95% which means that for
22 minutes in a caleder month the services would be unavailable.
2. Service Unavailability Credit - Based on the Service Unavailability
Target, if the services are exceeding the unavailability target then
the consumer should be entitled for the credit. This is linked to the
percentage of Monthly Recurring Charges (MRC). Generally it is up to
20% of MRC.
3. Exclusions - It is the definition of instances for which the
consumer is not entitled to receive any credit despite of service
unavailability. Ex- Natural Calamity, Floods, Fire etc.
4. Time Frame to process the Credit - Time taken by the Service
Provider to process the Credit request.
To meet this SLA for each SLA some Service Level Objectives (SLO)
needs to be defined. SLO are actually provides the tool by whihc the
SLA is monitered.
Please take this further.
Regards
Abhijit Chakole
ser...@gmail.com
CloudSigma
I think you make some good points. I'd like to add some insight from
the IaaS vendor's perspective. I think I basically agree with the
points you make and just wanted to add a couple of nuances.
For the Service Unavailability Target or 'Availability Target' as we
like to say (!!), I think its important to distinguish between service
delivery and compensation reference points. For example, we offer a
100% SLA, does that mean we guarantee to be available 100%? Of course
not, this would be impossible against all possibilities and also
disingenuous. What it does mean however is that even relatively minor
outages start attracting significant credit for customers without
having 'pain free' down time from our perspective each month. We
combine this with a x50 credit on downtime so you can imagine this
adds up to significant compensation quite quickly.
Essentially I'd say the combination of your points 1 and 2 give an
implicit indication of the cost to a vendor of any downtime. The
higher the SLA reference availability and the higher the compensation
rates, the more costly any down time is to the vendor. This of course
has direct impacts on the investment choices that a vendor makes to
improve availability. No-one is saying that the cost to the cloud
vendor of down-time is equal to that of the clients but if the cost is
higher, the incentive to 'invest this downtime away' is that much
stronger. As a result higher SLA reference points create built in
incentives for investing in greater redundant components and better
quality in equipment in general.
Finally, one area rarely covered which is a bit of a grey area is
performance degradation. In such a scenario customers could experience
poor networking performance but not an outage. This usually wouldn't
attract compensation in an SLA. As such inclusion of performance
metrics into an SLA are very advantageous from a customer's
perspective. From our perspective we aim to incorporate this aspect by
having an internal networking metric of a maximum of 1ms. If we are
suffering networking issues this would usually rise above this
triggering the SLA again. Its designed to help address the edge case/
grey areas regarding SLAs and performance.
Interested to hear feedback and also others' opinions on current cloud
SLAs.
Best wishes,
Robert
--
CTO
CloudSigma
http://www.cloudsigma.com/blog
http://www.twitter.com/CloudSigma
Miha Ahronovitz
(stricter rules for outages and/or performance degradation permitted)
Looking an an example of IaaS server costs
http://www.cloudsigma.com/en/pricing/price-schedules
I do not see explicitly Unavailability Target (UT)s.
IMHO, these costs should increase exponentially for esoteric
extremeness high UT
Miha
David Moskowitz
Miha Ahronovitz
> BOTH parties. In other words, the SLAs (yes, there may be more than 1) have
> to address how the various key performance indicators will be measured by
> both sides...
implement.
How does an AWS customer monitor what charges he receives in the AWS
bill?
How do I, a customer of PG&E (utilities electrical gas) in California,
monitor my charges?
.Beside the cost on kwh. prices are jacked up above the baseline
consumption by 40%
The price increases go in a couple of levels. In newer areas , the PGE
lowers the baseline..
The pricing function of the SLA is a closely related issue to SLAs
definition
We are used to pay more for support 24x7, versus 8x5.
I am familiar with the SLA implementation of Grid Engine, now an
Oracle product.
They use SLO (Server level objectives (measurable values). See more
details here:
http://wikis.sun.com/display/GridEngine/Using+SDM+With+the+Sun+Grid+Engine+Adapter
GE also has Acounting and Reporting Console (ARCO), that can report
resources used over time.
What they have not done yet, because Oracle Grid Engine is not widely
marketed, is to price more the higher availability SLA.
Miha
On Dec 12, 9:00 pm, David Moskowitz <david.moskow...@gmail.com> wrote:
> Pricing is a separate issue...
>
> Nothing should go into the SLA that can't be easily monitored and measure by
> BOTH parties. In other words, the SLAs (yes, there may be more than 1) have
> to address how the various key performance indicators will be measured by
> both sides...
>
> Contract issues should address how discrepancies in measurement between the
> parties will be handled.
>
> David
>
CloudSigma
Yes you are right, to deliver 100% availability (or very close to it)
would take exponentially higher costs, that's why I make the point
between the reference compensation level and actual delivered
availability. Clearly if the delivered availability level was
drastically lower most customer would leave and the company itself
would have financial difficulties in the medium to long term. As such
setting a 100% reference level:
- creates a culture within the company that any downtime is
unacceptable
- removes 'pain free' downtime that a lower reference level would
implicitly include
- creates a financial incentive to invest in delivering an
availability rate close to 100% (although as you point out and I
agree, actual 100% over the long-term isn't commercially viable)
http://www.twitter.com/CloudSigma
On Dec 13, 7:00 am, David Moskowitz <david.moskow...@gmail.com> wrote:
> Pricing is a separate issue...
>
> Nothing should go into the SLA that can't be easily monitored and measure by
> BOTH parties. In other words, the SLAs (yes, there may be more than 1) have
> to address how the various key performance indicators will be measured by
> both sides...
>
> Contract issues should address how discrepancies in measurement between the
> parties will be handled.
>
> David
>
drus...@ca.ibm.com
Have you looked at what has already been done as part of the Cloud
Computing Use Cases White Paper V4, which can be found at
http://opencloudmanifesto.org/Cloud_Computing_Use_Cases_Whitepaper-4_0.pdf
? Japanese and Chinese versions can be found at http://cloudusecases.org/.
Dave
On Dec 13, 12:00 am, David Moskowitz <david.moskow...@gmail.com>
wrote:
>
> Nothing should go into the SLA that can't be easily monitored and measure by
> BOTH parties. In other words, the SLAs (yes, there may be more than 1) have
> to address how the various key performance indicators will be measured by
> both sides...
>
> Contract issues should address how discrepancies in measurement between the
> parties will be handled.
>
> David
>
Tom Hanan
effective deployment SLA.
In a truly heterogeneous cloud deployment a "good" SLA guarantees "best
volume pricing" even if the service user must shift large volumes of service
requests away from an underperforming (non compliant) service provider. This
aspect of the SLA is critical in maintaining consistent service cost by
eliminating negative pricing disincentives resulting from large shifts of
service volumes to maintain service reliability.
It would usually also provide the pickup service provider with a sustained
redirection of volume to reward them for picking up the slack and or helping
out in an emergency. This process rewards service providers for
"availability" with consistently growing volume and penalizes over committed
service providers with lost business.
Without this guaranteed best pricing service providers are drawn to over
committing "locked in" users by ensuring that their infrastructure has
maximum utilization even as they fail to achieve their customer's
reliability goals.
The volume shifting price lock clause in the SLA breaks that incentive and
ensures that the provider correctly prices a reliable service or at least
allows the customer to receive those services from someone else who has them
available.
Thus it can again be seen how heterogeneous cloud deployments are crucial to
reliable cloud service fulfillment and profitability.
Tom Hanan
If you can't keep it Real,
Don't do the deal!
Dave
--
You received this message because you are subscribed to the Google Groups
"Cloud Computing Use Cases" group.
To post to this group, send email to
cloud-comput...@googlegroups.com.
To unsubscribe from this group, send email to
cloud-computing-us...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/cloud-computing-use-cases?hl=en.
CloudSigma
I can't say that I agree regarding mixing pricing with quality of
service and volume pricing. An IaaS vendor such as ourselves is a
utility company. In the short term we have a fixed capacity so it is a
classic yield management issue. Over-commitment is an old model
deployed in a traditional shared hosting setting that doesn't
translate well to the cloud. What underpins the over-commit model is
the low churn in clients and relatively static resource usage levels
over time. That doesn't sound like IaaS to us and it isn't. That's why
(nameless!) vendors that employ this model get a lot of complaints
surrounding performance because in the cloud the demand is fluctuating
much more often over short periods of time and performance then
suffers during peak times when you want the best performance! So what
model can you use then to manage utilisation?
The first thing to grasp is that there are different IaaS uses and
they need to be priced differently. The second thing to understand is
that markets clear through price adjustment.
So the first point is that some users of IaaS have medium to long term
computing needs, this might just be their core need with peaks above
it but regardless there is for many a core computing usage that varies
little. For this need a fixed price with discounts for longer
subscription periods and potentially volume discounts for large
customers makes sense. The vendor has a defined commitment period and
can therefore price accordingly. In our system we call this
'subscription pricing' and you can subscribe from anything from 1
month to 3 years. That capacity is then reserved for the customer 24/7
over that period of time.
The second model is called 'burst pricing' and this deals with the
second main component to IaaS computing and that's short term
computing needs. This is where the yield management comes in. You can
think of this as a bit of a fractal. Customers each have their core
computing level with peaks or temporary needs (there are pure 100%
burst computing users but most aren't) and the cloud becomes similar.
There is a base load that represents subscribed capacity and then
there are the short term fluctuations but unlike each customer the
cloud can't vary in size to accommodate at such short notice. So as a
vendor you can either have capacity standing idle during off peak
times (commercially and environmentally wasteful) or over-commit
capacity during peak times with the resulting poor performance as
outlined above. There is another way and that is to use the price. So
in our cloud the price of short term on demand 'burst' capacity varies
dynamically with the utilisation of the cloud.
How does that work? Basically we have a rolling billing system with 5
minute billing periods, users using above their subscribed capacity of
any resource automatically get billed on the burst pricing on demand
system. It means our customers can automatically combine subscription
and burst usage transparently.
The burst pricing levels are announced one billing period in advance
by RSS (i.e. T+5min). This gives users time to perform orderly shut-
downs on their servers and this is the critical difference between our
on-demand and other vendors. In our cloud the customer is given the
control and choice about when and how they perform their computing.
The up-shot of all this is that during off peak times, the clearing
price for the capacity is LOWER than during peak times. Our customers
know this. We've given our customers a direct financial incentive to
shift discretionary computing away from peak times and benefit from
cheaper prices and this is exactly what happens. Users script off the
back of the RSS feed and set price tolerance levels which trigger API
calls to bring up and down their computing. It sounds complicated but
its basically a script of a few lines running every five minutes or
so. We've designed the pricing to give benefits of savings off-peak
rather than charging huge premiums during peak times so the highest
burst usage rates are not penal and you can make real savings by
shifting computing off-peak where possible.
The end result is that the utilisation of our cloud is managed in real-
time through the price mechanism. In principle this is no different
from airlines managing their seats on a particular flight. So as a
cloud provider we don't need to overcommit yet we can run our cloud at
a high utilisation rate; it is a win win. This brings us back to your
point regarding pricing. Pricing in the short term on a cloud should
be dynamic, the idea of fixing prices in an SLA breaks this model and
forces vendors to rely on the 'bad old days' with over-commitment
which harms performance for users. In essence if someone wants to
shift 500GHz CPU/500GB RAM at 3am to our cloud, the price they would
get would be very different from 3pm in the afternoon and that is how
it should be, just like with electricity. Over time as customers
become more experienced and sophisticated they will be able to
arbitrage between clouds which again will further increase the
efficiency of resource allocation and improve cloud performance
overall. There are already the first signs of this new age taking
shape, a great example is SpotCloud ( http://www.spotcloud.com ).
The cloud turns computing resources into utilities and that means
utility style pricing and yield management. Customers gain greatly
from this shift through more reliable performance whether they are
using short term on demand computing or not.
Kind regards,
On Dec 13, 11:06 pm, "Tom Hanan" <tom.ha...@switchcomputing.com>
wrote:
> To: Cloud Computing Use Cases
> Subject: [Cloud Computing Use Cases 1076] Re: SLA
>
> This is a very good discussion on SLAs.
>
> Have you looked at what has already been done as part of the Cloud
> ? Japanese and Chinese versions can be found athttp://cloudusecases.org/.
Tom Hanan
You make some good points.
I can understand your position as an IaaS "utility" provider trying to
balance infrastructure costs and customer expectations. I also agree that
yield management is a huge issue for any utility.
The problem is that this creates a rather large conflict of interest between
the public good and private profits. This conflict is especially large when
the smooth operation of the society becomes "dependant" on the "utility"
making it "essential" or "mission critical". Thus there has always been a
sharp line between society / "mission critical" utilities which are
legislatively regulated and "best effort" utilities which are regulated only
by the unseen hand of the market.
Most "Good" IaaS / SaaS providers are in fact a mix of the two classes of
service "Mission Critical" and "Best Effort". The best IaaS providers
"Commit" dedicated resources to their mission critical deployments and
"Sell" the rest as "Best Effort". There is NO in between! The service is
either there when you need it or it is not! If you did not pay for it to be
there and the SLA does not guarantee it to be there then it is "Best
Effort".
This is not intended to paint IaaS providers as evil. Although most of their
SLA are not clearly marked as "Mission Critical" "Guaranteed Delivery" or
"Best Effort". More frequently I have seen the blame fall on the deployment
teams that deploy mission / business critical services on "Best Effort"
"Best Cost" IaaS and or SaaS.
As I have said before on this forum, there are some businesses and some
services that thrive on "Best Cost" / "Best Effort" infrastructure but few
if any of these are mission or business critical.
The more prevalent deployments are hybrids of "Mission / Revenue Critical"
and "Growth / Market Cap Critical" where established profit streams are
maintained with predictable "Mission Critical" services and Company
Valuation is grown with "New" profit streams acquired using lower cost "Best
Effort" infrastructure.
Thus it is essential that companies deploying services onto IaaS and SaaS:
1) Clearly understand how both revenue & growth are impacted by their
heterogeneous mix of Revenue & Growth Critical deployments.
2) Select and work with providers that can and will distinguish between
their "Best Effort" (growth) and "Mission / Revenue Critical" offerings.
3) Provide a clear heterogeneous framework for reliably shifting Dynamic
"Best Effort" to Guaranteed "Mission Critical" as the company's revenue
dependency grows.
4) Provide a clear heterogeneous framework for reliably and dynamically
shifting "Mission / Revenue Critical" deployments to other providers to
maintain the SLA's maximum response times.
5) Provide a clear financial "incentive" to the IaaS and SaaS provider(s) to
maintain mission critical response times below the SLA's maximums. This
includes eliminating any financial "disincentive" for the IaaS / SaaS
consumer for load shifting as a result of the breach.
These critical capabilities allow both the IaaS / SaaS provider and consumer
to create and manage a solid win/win heterogeneous deployment that provides
a clear path to profitable growth for both.
Robert,
Having said this it is obvious that you have described a "Best Effort"
pricing model that dynamically "prices" resources to maximize profits and
utilization. That is a great example of the unseen hand of the market
appropriately pricing "Best Effort" services.
Unfortunately you did not describe a "subscription pricing" mechanism by
which you managed "Mission Critical" services in the event of a breach of
the SLA during predictable "Peak Demand" and or infrastructure failure /
over commitment. You vaguely described that you had "large" high volume
customers whom you implied received a volume discount but made no mention of
structured prioritization and or guaranteed resource availability.
OK so you will probably have one of the lowest "Best Effort" costs in the
market place but how will I "KNOW":
1) You will not re-allocate my SLA capacity to someone willing to pay more
for it during peaking?
2) You will not penalize "MY" volume pricing based on "MY" need to shift my
loading somewhere else when your response times exceed my mission critical
SLA requirements?
I have to go back to my assertion that there are very few IaaS / SaaS
deployments that are not Hybrids of "Known Cost" "Revenue Critical" &
"Lowest Cost" "Best Effort".
So how can I use your IaaS service to address the "Known Cost" "Revenue
Critical" core of my deployment? I can't figure out how your RSS system
provides me with the ability to manage quality of service and price. But the
IaaS / SaaS deployments I help succeed MUST do just that. Even low cost and
free services fail if they are not reliably available / responsive to the
customers upon which their critical revenue streams are dependant.
I can figure out how to "shift" loading away from your "Best Effort" service
as response times approach critical points that will destabilize my ability
to deliver revenue critical services. But now I am likely shopping for those
services at the worst possible time!
Unless of course I find one or preferably more IaaS / SaaS providers that
will provide me with core "guaranteed resource availability" (prioritized
over all dynamic "best effort" pricing). I will of course need an SLA that
allows me to back that guarantee of performance up with an ability to
maintain my volume pricing even if SLA breaches by the IaaS / SaaS provider
drop my volume levels. In a best case scenario I would have an aggressive up
and coming IaaS / SaaS provider acting as a backstop to the tried and true
provider. The up and coming provider gets a "Best Effort" dynamic load
sharing commitment which ratchets up as mission critical loads are shifted
due to SLA availability breaches.
This is a win / win for everyone:
1) The tried and true IaaS / SaaS provider can continue to rapidly grow
revenue & profits by optimizing revenue during peak periods.
2) The up and coming IaaS / SaaS provider has a built in growth plan based
on best effort services which ratchet up as a result of accepting increasing
volumes of mission critical loads which are not satisfied by the tried and
true provider. These are typically price matching contracts based upon the
tried and true providers. Thus the up and coming IaaS / SaaS provider gets
stabilized pricing critical to his growth.
3) The deployment team gets a reliable frame work within which it can
optimize BOTH it's revenue and growth critical IaaS and SaaS deployments.
Robert,
This is a discussion about SLA. The objective of IaaS / SaaS SLA are
reliable & cost effective delivery of services.
The SLA either includes availability criteria which support the service
recipient's revenue and growth objectives or it does not.
If the IaaS / SaaS service recipient's revenue & growth objectives are not
clearly protected by the SLA then the "SLA" is pure "Best Effort" "CYA"!
You just can't have it both ways.
The following anecdotal musing is not targeted at Robert or his highly
appreciated response.
============================================================================
================
Snake Oil is when someone sells you a $30 bottle of $2 heroin laced mineral
oil with a fancy label, because they market it as cure for cancer.
In the bad old days of patent medicines, when you did not have to disclose
what was in the bottle, the cure(s) killed more people than the disease.
A business run "solely" on dynamically allocated / priced "Best Effort" IaaS
/ SaaS is a lot like someone taking snake oil laced with heroin. They
quickly get addicted to an unsustainable dependency. A dependency that ends
abruptly when management / owners force a transition to sustainable revenue
/ profitability.
The business equivalent of rehab! (A heroic effort to break life / company
threatening habits)
Tom Hanan
If you can't keep it real,
CloudSigma
I don't agree with your categorisation to begin with. Your whole
premise that IaaS is somehow a public good misses the obvious fact
that there are very few barriers to entry and fierce competition.
Putting that aside you seem to misunderstand the posting. We aren't
allocating resources away from subscribed capacity users. We are using
the price mechanism to clear free capacity in the cloud throughout the
day, not sell again capacity already purchased. We aren't over-
committing and that's the whole point of the utilisation management.
It is about moving away from traditional hosting models which do rely
on bundling, over-allocation etc. In light of this I find most of your
comments therefore slightly incomprehensible as we aren't providing
resources on a 'best efforts' basis as you describe. Likewise there is
little or no correlation between reliability and performance and size
of vendor.
On Dec 14, 10:46 pm, "Tom Hanan" <tom.ha...@switchcomputing.com>
wrote:
>
> read more »
Tom Hanan
1) I did not say that you did not provided subscribed services that were not
prioritized over "best effort". I said your post did not describe the
mechanism by which availability is assigned and guaranteed to your customers
who purchase that service. I was hoping you would take my post as an
opportunity to do just that so the readers of this blog could put such
services into perspective. I failed and I apologize.
Perhaps you could take that opportunity now?
2) Fierce competition does not in itself negate the value of a "Utility" to
the public good or its need for regulation. Cell phone companies are an
example of a rapidly growing "public good" utility that is fiercely
competitive and highly regulated. Neither price or availability are
regulated. What is regulated is the relationship and contract with the
customer. Thus it is the portability and common description of services that
is ultimately regulated.
3) My underlying point is not that IaaS / SaaS vendors and or competition
are bad or good. It is that their SLA & contracts do not support true
heterogeneous competition for best availability at the best price. If
anything their contracts and SLA go out of their way to make their services
less portable in a heterogeneous environment.
Again I encourage you to let us all know how your service, SLA & contracts
and overcome this vexing issue.
4) I agree that there is little correlation between size of vendor and
reliability. But I have found that larger providers, with larger aggregated
deployments, have more dynamic (utilization priced) resource availability
than smaller providers who are focused on increasing their base revenue by
providing exceptionally responsive services and flexible SLA that stand
behind the customers core needs.
Again I am not saying one is better than the other, just the opposite, I am
saying that many organization combine the strengths of both into a
heterogeneous deployment that is far better matched to business goals than
if it were deployed on one or the other.
Again I mean no disrespect and I am not targeting your companies' service. I
am describing an elephant in the room that has been stomping the life out of
many organizations transitioning their deployments away from dedicated
resources and into the cloud.
I also do not wish to imply that this is any more of a problem than that
faced by an organization attempting to "own" all of its core and dynamic
computing capacity. Frankly it is not!
5) My hope in posting this response is that you will take a hard look at
your service offerings and SLA and post an optimistic response on how your
services could be packaged for use in a "State Of the Cloud" heterogeneous
deployment. Real feedback from vendors and customers alike are crucial. My
personal experience is that most providers have the capability to provide
these services but only do so when challenged to do so by a major customer
and their pesky consultant(s).
Take the initiative, draw business to you, by providing a heterogeneous
frame work for cloud deployments that makes your company a standout in a
crowded room!
Your organization has already come a great deal of the way by providing a
simple, automated mechanism, for pricing and clearing underutilized Dynamic
resources. I honestly think we are agreeing more that we disagree.
Structure that dynamic script into a multi vendor (heterogeneous) script and
you’re a few yards from the finish line and ten steps ahead!
Robert,
I would again like to thank you for your posts.
If you would like to "talk" offline before you reply
you can e-mail me at tom....@switchcomputing.com.
You have earned my respect thus some my time.
Tom Hanan
Dear Tom,
Kind regards,
Robert
--
Abhijit
It seems to be very interesting.
What I got from this discussion is the Service Providers Perspective
about the SLA, I think though SLA is a Techno commercial agreement
between User and the Service Provider but it is not the bondage if
taken in good spirit it is Win - Win situation for both. With taking
into account the user's need 1. Fixed 2.Fluctuating two strategies can
be implemented like - Fixed Pricing & Burst pricing. With this Service
Provider can prompt the user to use the resources in an optimum manner
and at the same time the Service Provider's resources are also
utilized to maximum extend without hampering the performance which is
under the SLA scrutiny.
Keep Sharing the information.
Regards
Abhijit Chakole
>
> read more »- Hide quoted text -
>
> - Show quoted text -
Abhijit
Thanks for the input.
I agree that it is the Cloud user who has to first underatand about
it's own business and has to categorize it's need as
1. Critical or the Essential - The most important time and for which
needs to have the service available
2. Best Available - The time for which the average availability of
services will serve the purpose.
Basis of this the Cloud User has to categorize it's need for the
system and then needs to define the SLA.
Please clarify if I am wrong in interpritation , for both type of
service need we need to have separate Service Provider ?
Regards
Abhijit Chakole
CloudSigma
I've addressed the points you raise in turn below but as stated
previously, while you wish to frame the debate about 'best efforts'
versus 'guaranteed', this is neither how we nor (from experience) our
customers actually go about provisioning resources.
Point 1
It isn't clear whether you are talking about the actual virtualisation
level or cloud wide level. We use the KVM hypervisor and as outlined
previously when customer purchase resources these are reserved for
them. KVM does not work in the same was as Xen and others which is why
there might be some confusion.
At the cloud wide level, as outlined previously utilisation is managed
dynamically. As we have dynamic pricing for on-demand it means we can
afford to have a great deal more 'spare capacity' over and above
steady 24/7 capacity purchased on subscription. This is because we can
clear additional capacity through the dynamic price mechanism in a way
that isn't feasible with traditional shared hosting or other providers
that lack this mechanism. The reality is that we don't see the
situation that customers can't get the resources they want to purchase
because a substantial percentage of our cloud usage is what I could
best describe as 'floating' . As an additional measure, if we ever
were looking like potentially having a problem we'd simply stop taking
on new customers to keep remaining space for existing customers. Again
this has never happened because we order capacity well ahead of need.
Point 2
Now I understand. Actually your use of the word 'public good' is not
the economic one or at least very loosely applied. A utility is a
style of business delivery of a resource and not connected in any way
to whether it is a 'public good' or not. Contrary to your statements,
the mobile telephony market is now characterised by 'fierce
competition' but by a small number of oligopoly players with the
relevant government licenses. This situation is particularly bad in
the US market.
The internet grew very well powered by private co-location, shared web
hosting etc. all without government regulation. Cloud computing is not
fundamentally different to both of those private services at all.
Questions regarding data protection are not in fact not specific to
the cloud at all and need to be defined whatever form data is held in.
In fact it is the different treatment of data that causes most of the
issues. Again, our customers want to understand the laws that govern
the data in our cloud (Swiss law which is very strong as you might
expect), no customer in our discussions at events, shows etc. has ever
thought that the government has anything useful to add to making
specifically cloud computing work better. As always no doubt those who
stand to gain from such actions; governments that always like to be
seen to be 'doing something' about whatever the topic of the day is,
traditional delivery model incumbents that are threatened that know
the stifling effect of regulation and existing large players that
understand that regulation is one of the most effective barriers
against new entrants and unsettling innovation will be right behind
such efforts.
Point 3
I really don't see the connection between service level agreement and
portability which is a standards and tools defined characteristic.
Customers have a choice before choosing a provider and can see what
approach and policies that provider has in place. As for our cloud,
you can FTP in and out your whole drive images in RAW ISO format. We
couldn't think of an easier way to allow users to get quite literally
all their data out of our cloud in a convenient cost effective manner
that they can immediately re-deploy.
We also have a Rackspace API emulator although almost none of our
customers end up using it as it means going back to fixed instance
sizes, having no drive/server separate entity methodology, no data
encryption options etc. It is of course almost identical to the 'open'
OpenStack API and when that is in a usable form we'll re-label it as
such for those that want to use it. Our cloud in general uses standard
architectures and computing processes which makes it easy to move from
our platform to others which are generally a lot more proprietary.
Point 4
Which providers have you used with dynamically priced on-demand
resources? The only ones we know of are Amazon EC2 and ourselves but
we may have missed some operations. We weren't aware you had used us.
Having looked at your website it is a GoDaddy holding page so I wasn't
able to understand what you were doing.
Point 5
Have you read our SLA? If so what is your feedback. As I've outlined,
we don't tier performance which is against our approach and in our
opinion artificial. You don't get different qualities of electricity
although you get good and bad providers and that's the same approach
we take.
As outlined previously, management of IaaS is about reliability in
terms of performance levels and availability. As with the traditional
dedicated and shared hosting spaces, those that don't provide this
quickly find customers moving to competitors. No SLA or regulation
fixes poor management, technology or execution. That is what customers
in general are looking to ascertain. People forget, even today in this
early stage of the market development, it is a lot easier to move
cloud computing provider than dedicated hosting provider.
Kind regards,
Robert
CTO
CloudSigma
http://www.cloudsigma.com
>
> read more »
CloudSigma
I am happy to discuss things further some time. My email is
rob...@cloudsigma.com , you can drop me an email and we could organise
a skype call etc.?
Kind regards,
Robert
>
> read more »
Tom Hanan
The need for a Heterogeneous (Multi Vendor) deployment is more a function of
ensuring that you have options when service availability / disruption issues
arise due to outages or unexpected (but desirable service growth).
Providing maximum UP-Side opportunity when and if your business grows faster
than your vendor or has seasonal peaks that grow faster than your vendor.
That's the kind of stuff that separates the boys from the men where
investors are concerned.
Social networking is a great example of deployments that "sometimes" have
nearly unmanageable user acquisition rates and rapidly growing peak resource
consumption. Something their founders and investors are working hard to
encourage!
All in all it's about best business practices (maximizing revenue growth and
retention opportunity) driving best cloud deployment practices.
Dear Tom,
Thanks for the input.
Regards
--
David Moskowitz
Tom Hanan
This is a great discussion everyone!
Just the kind of feedback and insight from both sides necessary to create solid agreements.
I wanted to take a moment to highlight what I see as the best underlying practices discussed.
1) Simpler, clearer, decisive objectives and language are ALWAYS better.
2) There are only (4) things to define:
a. What you are offering / guaranteeing. (Don’t include things BOTH parties can’t independently measure)
b. How and by whom it is measured (see “a” above)
c. What is the customer’s recourse when the guaranteed & measured levels are not delivered
d. The terminology used in the SLA (not as well agreed upon as you might think, especially in court)
3) The core of the SLA should be three pages or less:
a. A section describing the service and what is guaranteed.
b. A section describing how the service is measured and by whom.
c. A section describing the customers recourse when the guaranteed services are not met.
d. A section describing the definitions for all terms used in the SLA. (Quote standardized definitions whenever possible)
I am working on a boiler plate for the above and am looking for feedback from IaaS, SaaS and PaaS providers and customers.
Robert, from CloudSigma, has already provided some great feedback.
They sound like a customer focused group, who like to keep things simple and concise.
Remember a good SLA is ALWAYS cheaper than ANY litigation!
Tom Hanan
If you can’t keep it real,
Don’t do the deal!
--
Abhijit
Yes, the discussion is very fruitful. You, Robert and others have
given a very nice feedback, we should continue such discussions.
1. SLA - Needs to be clearly defined. It takes very less time to
define the SLA than to go on for litigations.
2. SLA - should be clear, easy to understand, there should not be any
ambiguity.
3. SLA - should be a win-win situation for both Service provider and
consumer. Consumer's right for the services should be protected at the
same time Service provider should be rewarded for the extraordinary
support in case of unplanned need of the consumer.
But some questions appear in my mind which is for everybody to ponder
-
1. What about the Service Level Objectives?
2. How to develop mechanism to monitor SLA?
3. Should third party SLA monitoring software be used?
Please give your inputs.
Thanks and regards
Abhijit
On Dec 22, 10:44 pm, "Tom Hanan" <tom.ha...@switchcomputing.com>
wrote:
>
>
>
> > Nothing should go into the SLA that can't be easily monitored and measure
> by
> > BOTH parties. In other words, the SLAs (yes, there may be more than 1)
> have
> > to address how the various key performance indicators will be measured by
> > both sides...
>
> David, interesting. Yes and No. Beautiful statement but hard to
> implement.
> How does an AWS customer monitor what charges he receives in the AWS
> bill?
> How do I, a customer of PG&E (utilities electrical gas) in California,
> monitor my charges?
> .Beside the cost on kwh. prices are jacked up above the baseline
> consumption by 40%
> The price increases go in a couple of levels. In newer areas , the PGE
> lowers the baseline..
>
> The pricing function of the SLA is a closely related issue to SLAs
> definition
> We are used to pay more for support 24x7, versus 8x5.
>
> I am familiar with the SLA implementation of Grid Engine, now an
> Oracle product.
> They use SLO (Server level objectives (measurable values). See more
> details here:
>
> dapter
> read more »- Hide quoted text -
>
>
> - Show quoted text -- Hide quoted text -
Abhijit
As I want to discuss ferther I would like to mail you peronsally from
my personal email ID (ser...@gmail.com) with same subject. Please
respond.
Regards
Abhijit Chakole
On Dec 22, 10:44 pm, "Tom Hanan" <tom....@switchcomputing.com>
wrote:
> dapter
David Moskowitz
Difficulty doesn't get in the way of what is necessary. Failure to have agreeable metrics available to both sides opens the door to litigation.
Tom Hanan
Good observations David.
I have some thoughts to add on the legal aspects of the SLA.
1) An SLA should be written so that it “CAN” act as the “Guarantees” section of a contract. The “Guarantees” section is the most litigated section in my experience. Clearly written SLA significantly reduce the time / cost an arbiter / judge needs to achieve a resolution. A simple 3 page SLA could require arbitration around clear service level objectives with clear and limited recourse.
2) Heterogeneous (multi provider) deployments allow simpler SLA which describe simpler limited liability for the service provider(s). This is due to the fact that the customer is indemnified by the provider(s) for any financial penalty for shifting workload from one provider to another when service level objectives are not met. Thus both the customer and provider are mutually indemnified against the “cascading losses” that “good lawyers” are trying to protect their clients against. Thus a SHLA (Simplified Heterogeneous Liability Agreement) uniquely allows both the service provider and consumer to optimize their deployment, in very dynamic conditions, without dynamically changing their liability exposure.
3) I do have to agree with David that there are SLA guarantees, such as data security, where a heterogeneous deployment will not be able to address cascading liability. The good / bad news is that these aspects are almost all regulated by law and thus the SLA need only refer to the mandated provider requirements. Litigation of these standardized / regulated aspects of the provided service will be covered by the contracts standardized and regulated legal clauses.
4) Data integrity is however commonly mandated and addressed using heterogeneous backups and mirrors. Thus data integrity can be addressed using the same SHLA (Simplified Heterogeneous Liability Agreement).
Just a few quick thoughts:
The SHLA (Simplified Heterogeneous Liability Agreement) provides simplified “limited liability”, for both the provider AND customer, through simplified “customer recourse”. Essentially it is shifting the burden back onto the deployment team to forsake the promises written on a piece of paper for the ability to respond to dynamic shifts in demand and supply provided by a heterogeneous deployment. SHLS are based on a solid capitalistic foundation that both prices and deploys reliable heterogeneous resources efficiently.
Stability and opportunity,
the core goals of any “real” deployment!
Look for my draft SHLA (Simplified Heterogeneous Liability Agreement) at the beginning of 2011. I encourage any service providers interested in an open source SHLA (Simplified Heterogeneous Liability Agreement) to send me their < 3 page SLA. I would like to incorporate as many of the best practices they contain in my initial open source draft.
If you would like to privately address the opportunity for a customized SHLA (Simplified Heterogeneous Liability Agreement) then send me a private e-mail.
I have some time available at the beginning of the year.
Tom Hanan
If you Can’t keep it real,
Don’t do the deal!
************* Legal Disclaimer *********************
Tom Hanan is not a licensed attorney or a representative of a licensed attorney. All comments related to legal precedence and or documents are my own opinions and suggestions and should not be considered or used without proper review by a qualified legal professional licensed to practice in the appropriate judicial jurisdictions.
***********************************************
--
David Moskowitz
Good observations David.
I have some thoughts to add on the legal aspects of the SLA.
1) An SLA should be written so that it “CAN” act as the “Guarantees” section of a contract. The “Guarantees” section is the most litigated section in my experience. Clearly written SLA significantly reduce the time / cost an arbiter / judge needs to achieve a resolution. A simple 3 page SLA could require arbitration around clear service level objectives with clear and limited recourse.
2) Heterogeneous (multi provider) deployments allow simpler SLA which describe simpler limited liability for the service provider(s). This is due to the fact that the customer is indemnified by the provider(s) for any financial penalty for shifting workload from one provider to another when service level objectives are not met. Thus both the customer and provider are mutually indemnified against the “cascading losses” that “good lawyers” are trying to protect their clients against. Thus a SHLA (Simplified Heterogeneous Liability Agreement) uniquely allows both the service provider and consumer to optimize their deployment, in very dynamic conditions, without dynamically changing their liability exposure.
3) I do have to agree with David that there are SLA guarantees, such as data security, where a heterogeneous deployment will not be able to address cascading liability. The good / bad news is that these aspects are almost all regulated by law and thus the SLA need only refer to the mandated provider requirements. Litigation of these standardized / regulated aspects of the provided service will be covered by the contracts standardized and regulated legal clauses.
4) Data integrity is however commonly mandated and addressed using heterogeneous backups and mirrors. Thus data integrity can be addressed using the same SHLA (Simplified Heterogeneous Liability Agreement).
Just a few quick thoughts:
The SHLA (Simplified Heterogeneous Liability Agreement) provides simplified “limited liability”, for both the provider AND customer, through simplified “customer recourse”. Essentially it is shifting the burden back onto the deployment team to forsake the promises written on a piece of paper for the ability to respond to dynamic shifts in demand and supply provided by a heterogeneous deployment. SHLS are based on a solid capitalistic foundation that both prices and deploys reliable heterogeneous resources efficiently.
Stability and opportunity,
the core goals of any “real” deployment!
Look for my draft SHLA (Simplified Heterogeneous Liability Agreement) at the beginning of 2011. I encourage any service providers interested in an open source SHLA (Simplified Heterogeneous Liability Agreement) to send me their < 3 page SLA. I would like to incorporate as many of the best practices they contain in my initial open source draft.
If you would like to privately address the opportunity for a customized SHLA (Simplified Heterogeneous Liability Agreement) then send me a private e-mail.
I have some time available at the beginning of the year.
Tom Hanan
If you Can’t keep it real,
Don’t do the deal!
************* Legal Disclaimer *********************
Tom Hanan is not a licensed attorney or a representative of a licensed attorney. All comments related to legal precedence and or documents are my own opinions and suggestions and should not be considered or used without proper review by a qualified legal professional licensed to practice in the appropriate judicial jurisdictions.
***********************************************
From: cloud-comput...@googlegroups.com [mailto:cloud-comput...@googlegroups.com] On Behalf Of David Moskowitz
Sent: Wednesday, December 29, 2010 7:16 PM
Subject: Re: [Cloud Computing Use Cases 1106] Re: SLA
--
You received this message because you are subscribed to the Google Groups "Cloud Computing Use Cases" group.
To post to this group, send email to cloud-comput...@googlegroups.com.
To unsubscribe from this group, send email to cloud-computing-us...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cloud-computing-use-cases?hl=en.
Miha Ahronovitz
accustomed from lawyers.
What set's these posts apart is that you present legal issues as a
solution and not as problem. As an entrepreneur, one is often advised
NOT to consult lawyers during the initial germination of the business,
as they are trained to find all the catastrophic "what if" cases, even
the one with a remote risk
I like the idea of David Moskowitz:
reference the SLA by inclusion as an addendum or appendix or..".
of an "SHLA (Simplified Heterogeneous Liability Agreement)", except
this could be broken in two documents as David M. suggests. Also we
may want to take out the word "liability" from the title.
Kindly advise us, or at me privately, when the draft is ready. I a
would be very grateful indeed.
Cheers,
Miha
On Jan 6, 12:03 pm, David Moskowitz <david.moskow...@gmail.com> wrote:
> Comments interspersed...
>
> David
>
> > cloud-comput...@googlegroups.com] *On Behalf Of *David Moskowitz
> > *Sent:* Wednesday, December 29, 2010 7:16 PM
>
> > *To:* cloud-comput...@googlegroups.com
> > *Subject:* Re: [Cloud Computing Use Cases 1106] Re: SLA
> > cloud-comput...@googlegroups.com] *On Behalf Of *David Moskowitz
> > *Sent:* Tuesday, December 21, 2010 8:08 PM
> > *To:* cloud-comput...@googlegroups.com
> > *Subject:* Re: [Cloud Computing Use Cases 1101] Re: SLA
> > Difficulty doesn't get in the way of what is necessary. Failure to have
> > agreeable metrics available to both sides opens the door to litigation.
>
> > Just had this with a client and a vendor most of last week. THe vendor
> > started with the same concept expressed in your message. The client lawyers
> > accept recommendations and insisted on a different approach. By the end of
> > the week the vendor agreed.
>
> > If you can't figure out how to monitor and measure it, don't put it in the
> > SLA.
>
> > Pricing is related to the terms of the SLA (among other things the SLA
> > needs to address things like functionality, availability, capacity,
> > security continuity (aka DR), and maintainability, support and response,
> > etc. Want higher availability, pay more, etc. So, in that sense, yes SLA
> > terms related to pricing. However, each of these need to
> > be quantifiable and have associated metrics.
>
> > David
>
>
> > > Nothing should go into the SLA that can't be easily monitored and measure
> > by
> > > BOTH parties. In other words, the SLAs (yes, there may be more than 1)
> > have
> > > to address how the various key performance indicators will be measured by
> > > both sides...
>
> > David, interesting. Yes and No. Beautiful statement but hard to
> > implement.
> > How does an AWS customer monitor what charges he receives in the AWS
> > bill?
> > How do I, a customer of PG&E (utilities electrical gas) in California,
> > monitor my charges?
> > .Beside the cost on kwh. prices are jacked up above the baseline
> > consumption by 40%
> > The price increases go in a couple of levels. In newer areas , the PGE
> > lowers the baseline..
>
> > The pricing function of the SLA is a closely related issue to SLAs
> > definition
> > We are used to pay more for support 24x7, versus 8x5.
>
> > I am familiar with the SLA implementation of Grid Engine, now an
> > Oracle product.
> > They use SLO (Server level objectives (measurable values). See more
> > details here:
>
> > .
> >http://groups.google.com/group/cloud-computing-use-cases?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Cloud Computing Use Cases" group.
> > To post to this group, send email to
> > cloud-comput...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
Rizwan Ahmad (Ryu taichi)
It's better to separate the legal issues from the performance issues. Guarantees and penalties should be part of the contract that reference the SLA by inclusion as an addendum or appendix or... I'm less concerned about page length than I am about simple, easy to understand, and crafted primarily in business terms (versus technical language). That said, I agree the SLA portion of the contract should not be any longer than needed -- with shorter better.
2) Heterogeneous (multi provider) deployments allow simpler SLA which describe simpler limited liability for the service providerllevel objectives are not met. Thus both the customer and provider are mutually indemnified against the “cascading losses” that “good lawyers” are trying to protect their clients against. Thus a SHLA (Simplified Heterogeneous Liability Agreement) uniquely allows both the service provider and consumer to optimize their deployment, in very dynamic conditions, without dynamically changing their liability exposure.
There needs to be clear and unambiguous declaration of responsibility. Which provider (if there's more than one) owns (and is, therefore, responsible for) the customer relationship and satisfaction. Agreements have to be crafted to avoid the typical finger pointing that is part of all too many relationships.
Again, it's necessary to separate legal from performance issues with liability being a legal issue. The SLA has to be negotiated based on realistic and achievable performance targets. Also included should be the specific events that will trigger service improvement plans (without having to renegotiate the entire contract), if performance doesn't meet agreed levels.
3) I do have to agree with David that there are SLA guarantees, such as data security, where a heterogeneous deployment will not be able to address cascading liability. The good / bad news is that these aspects are almost all regulated by law and thus the SLA need only refer to the mandated provider requirements. Litigation of these standardized / regulated aspects of the provided service will be covered by the contracts standardized and regulated legal clauses.
What needs to be included in the SLA are statements about more than just what is regulated/mandated. Very often a customer will have their own requirements in this area. Also considered needs to be issues of continuity (what happens if... and there are at least 2 aspects of this: what happens if the provider has to invoke or if the customer invokes), capacity (aka performance levels), availability, maintainability, etc...
4) Data integrity is however commonly mandated and addressed using heterogeneous backups and mirrors. Thus data integrity can be addressed using the same SHLA (Simplified Heterogeneous Liability Agreement).
Liability has a specific legal meaning which is why I recommend the word be kept out of the SLA portion of the contract
To unsubscribe from this group, send email to cloud-computing-us...@googlegroups.com.
David Moskowitz
Tom Hanan
David,
I guess we may have a bit of a break in philosophy here.
The concept of using a SHLA (Simplified Heterogeneous Liability Agreement) is that everyone’s liability and exposure are reduced by dynamic provider portability. But simplified heterogeneous provider portability “requires” standardization of the infrastructure AND the liability contract across providers. The very concept of having a unique contract with each provider builds in barriers to dynamic portability which negates the ability of customers to move dynamically between suppliers with “Like” service offerings to mitigate liability to themselves and their providers. The legal work to “qualify” multiple heterogeneous providers is just too time consuming for an overloaded deployment team.
Insurance companies have fully developed the legal process and definition of the “clients responsibility to minimize damage” and it is under this umbrella that the SHLA allows / requires the client to dynamically move loads (as their primary recourse) when a provider fails to meet their SLA. The ability to move the load is the sole protection afforded both the customer AND the provider.
When you think about it the simplest limited liability agreement possible is a provider that allows you to dynamically and or permanently re-deploy resources to another provider when they are unable to meet the customer’s dynamic growth and or contracted minimum volume.
1) When due to unplanned demand by the customer, that exceed minimum volume guarantees, the providers are protected by keeping the volume loading they contracted for and delivered. The customer is then free to satisfy the peaks and or rapid growth with increases to the existing contracts minimum availability and or shifting the additional “un-guaranteed’ loading to another provider willing and able to provide “guaranteed” service for the additional loading. This scenario is complicated a little when you add in a “first right of refusal” clause that gives the existing “contracted” provider the ‘first option” to ratchet up their minimum guaranteed volumes under the existing terms, if they have not previously failed to deliver that volume of service dynamically.
2) When due to a temporary failure by the provider to “deliver” the minimum volumes contracted for by the customer, the client is allowed to dynamically re-deploy the unsatisfied volumes to another provider without an increase in cost and or services associated with the lower levels of volume. >98% of the “beyond our control” service interruptions fit into this category.
3) When due to catastrophic and or repetitive failures to deliver “minimum guaranteed” volumes “a breach” (a consistent failure to deliver contracted volume), then the customer may, at their option, permanently re-deploy the contracted volume to another provider without penalty. This just doesn’t happen very often with quality providers! Especially the ones that provide subscription based volume services.
The net of these three simple recourse categories, backed up by three pages of “standardized” legalese, is an SHLA (Simplified Heterogeneous Liability Agreement) that clearly places the burden to address dynamic and or consistent “provider” unavailability on the customer and clearly protects the customer from higher deployment costs due to that dynamic and or consistent failure to meet their volume needs.
It also clearly places the burden of “keeping” their customers on the providers ability to reliably “deliver” the guaranteed service levels. Satisfying the customer’s dynamic and growing baseline volume needs is the clear path to growth already practiced by the best providers.
It should be noted that providers are naturally protected from abusive customers since the customer must shop (Price) the re-deployed services out to another provider at current market or pre-negotiated rates.
Again the goal here is to enable real dynamic growth and reliable deployments through SHD (Simplified Heterogeneous Deployments). Standardizing the deployment contracts (if not the price) across multiple providers is at the core of SHD. SHDP (Standardized Heterogeneous Deployment Packaging) is already far ahead of the SHLA.
Again 99% of all the “customized legalese” in existing SLA are intended to address the unreasonable expectation of customers that they can “Guarantee” deployment success with a piece of paper (SLA / Contract) instead of “Assuring” it with a heterogeneous deployment. Once you eliminate that “unreasonable” expectation you eliminate 99% of the stuff the lawyers argue back and forth about as they seek to provide their clients with the best wiggle room if expectations are not met. Each of these “customized” agreements is unique and essentially binds the hands of the deployment team preventing them from “knowing” the financial impact of a redeployment which must be done to “protect” revenue “now”! So unless you’re a CIO with a degree in contract law and finance you’re not likely to be able to make that critical decision until you wake up the lawyers and the rest of the O’s. A career limiting event at best!
I have looked at a wide range of non heterogeneous SLA and frankly “NONE” of them protect the customer from the lost revenue / opportunity / valuation that accompanies a poorly timed outage. No provider lawyer in his right mind would allow their client to place themselves at that level of financial risk! Providers are not in the business of providing loss of revenue insurance.
Thus the core of SHD is that it concentrates on “Assurance” instead of “Insurance”. Insurance contracts are convoluted heavily litigated documents, Assurance contracts are simple. If I don’t deliver the service you are free and able to get the service elsewhere (true technical & financial portability). Think of it as a meritorious “Servocracy”.
As I have pointed out before, SHD with SHLA are not for everyone, but their core business advantages for customers and providers will likely create a rapidly growing segment which addresses the dynamic volume and high availability needs of large and small customers and providers.
I see:
1) A growing number of aggressive providers implementing the initial SHD with SHDP & SHLA.
2) Competent deployment teams moving new deployments to SDH until they gain the confidence to re-deploy existing deployments to SHD.
3) Startup companies, and their VC, that live and die on creating and enabling dynamic upside, making SDH the new “best practice” for rapidly growing deployments.
4) Initial SDH providers capturing market share because of their aggressive support of their customer’s true needs.
5) SDH provider volumes hockey-stick as customers drive SDH as the new “best practice” for highly dynamic / available deployments.
6) Traditional providers implementing SDH to protect their core customer base as their contracts expire.
Again David,
I think your comments are good and very consistent with existing non SDH contracts and SLA.
Perhaps you could contribute to the specifics of the legalese needed to back up a solid SHLA?
Something that looks more like a fill in the blank non disclosure agreement than a 20 page contract?
Something that could one day be made machine readable / actionable?
David Moskowitz
These are my observations,as I am working on governance, SLAs, Contracts and international security standards determine the course of governance within the clouds during the relative shift of controls between cloud user and cloud provider within the layers of the cloud SaaS, PaaS and IaaS.) An SLA should be written so that it “CAN” act as the “Guarantees” section of a contract. The “Guarantees” section is the most litigated section in my experience. Clearly written SLA significantly reduce the time / cost an arbiter / judge needs to achieve a resolution. A simple 3 page SLA could require arbitration around clear service level objectives with clear and limited recourse.
It's better to separate the legal issues from the performance issues. Guarantees and penalties should be part of the contract that reference the SLA by inclusion as an addendum or appendix or... I'm less concerned about page length than I am about simple, easy to understand, and crafted primarily in business terms (versus technical language). That said, I agree the SLA portion of the contract should not be any longer than needed -- with shorter better.The legal issues cannot be seperated, (not referencing SLA) cloud has legal issues rather then technical.SLAs are meant for Quality of Service (QoS), what cloud provider may provide to the user. I am using "may" because cloud providers dont invisage any form of guranttee that they can provide 100% service. if you consider it from the technical perspective, they are allowed the"due care" to the extend that a normal netwrok can provide the information or process it. Then there are some technological controls which are not in the power of cloud provider or user, for example the bradband excess, routing, network confidentiality, these things must be in mind while designing SLAs.
to reinforce SLAs to produce governance, confidence in consumer, the general contracts may be designed in a manner that should not be harsh to cloud provider nor to the user. For example lets take Guarantees, cloud provider and user agrees that security in terms of confidentiality, integrity and availability, is provided by cloud provider, if any dispute occurs, both parties may refer the arbitration for dispute resolution, cloud in its definition is transnational , therefore here the jurisdiction matters which law is needed to be applicable. second point is despite Guarantee is provided, the law enforcements comes and asks for the data. The common rule as espoused by 4th amendment united states constitution (katz case) is whenever the data is substancially in controll of the third party, the victim cannot seek the remedy under reseable expectancy of privacy (4th ammendment). In this case the cloud provider can provide the data to the law enforcement under patriot act etc. Giving guarantee in this context may not work, similarly, in security terminology we describe that nobody is 100% secure. Guarantee clause cannot provide defence for this.I agree that SLA should not be part of COntract, However, I suggest that SLAs should be designed in a way to substantially commensurate the contracts.
Tom Hanan
Thanks for the great comments Rizwan!
Your comments about the reality of performance QoS being read by the courts as “may” is the reality between unrealistic (phantom) limited recourse “insurance” guarantees with Due Care, Due Diligence and 3rd party exclusions verses the (real) “Assurance” recourse available in SHD (Simplified Heterogeneous Deployment). E.g diversifying your deployments diversifies your real service and network provider risks. The more intelligently you diversify your deployment the higher your real deployment assurance. Server and network Provider as well as geographic and political diversity can be a major consideration in any true “assured” deployment.
Such diversity means that server and network providers in different jurisdictions have different assurance capabilities based upon the regional laws that govern their standards for due care / diligence. This is the area where I think you and David bring up the best arguments for legal addendums that describe how and where each provider’s definition of these terms are governed. As an example Katz has no basis in the actions of Swiss providers or US firms who use such providers to provide services outside the US, typically through a foreign subsidiary.
Espionage aside, such 3rd party diligence of encrypted data with the “expectation” of privacy are fairly clear. The right / liability of making public “encrypted data” with an expectation of privacy is also fairly clear in most jurisdictions around the world. In all of these cases the providers and their customers are indemnified by the legal and or illegal actions of third parties so long as they perform “Due Care” as described in their governing jurisdiction.
It is interesting to note that common “Due Care” clauses include an exception clause that exempt specific assurances where they are not supported by governing law in either the provider, customer or end user jurisdiction. Thus a company in the US using a Swiss service provider could provide higher levels of assurance than if the same servers and data were located in China or the United States. However their recourse would be limited to that of the lesser of the two jurisdictions. It is in this last “lowest common denominator” statement that a simplified description is available.
“The level of assured “due care” is thus the lowest required within the jurisdictions in which the infrastructure provider, service deployer and or end user resides or accesses the service.”
Thus a document / table of governing case law by jurisdiction could describe and or summarize the lowest assurance for a given deployment across multiple jurisdictions. It might also include exclusions which prevent certain types of information, who’s security are governed by regional law, from being processed, transported and or delivered in some regions.
Today’s reality is that most people have no idea how badly exposed their data is or how little actionable recourse they have.
This is why some heterogeneous deployments maintain 100% regional deployments to service regional end users.
Try communicating that without an SDH!
Rizwan,
Perhaps you could contribute to the development of a simplified “due care” statement and jurisdictional table.
Tom Hanan
As Davit points out it can sometimes be beneficial to separate objectives
from legal obligations. But I have found that if you make the legal
obligations simple enough you can bring the two much closer together! In
either case you need standardized contracts / SLA to achieve true
portability. To do that you need obligations and liabilities that are simple
enough to agree upon!
-----Original Message-----
From: cloud-comput...@googlegroups.com
[mailto:cloud-comput...@googlegroups.com] On Behalf Of Miha
Ahronovitz
Sent: Friday, January 07, 2011 9:22 AM
To: Cloud Computing Use Cases
Cheers,
Miha
cloud-computing-us...@googlegroups.com.
Tom Hanan
David,
how do you propose a standardized connection between a business term SLA, which is considered a contract or at least a referenced document / addendum and there for modifying document by most jurisdictions and “the” contract?
Are you arguing for a standardized contract / SLA to achieve the goal of standardized / simplified heterogeneous deployments and the necessary standardization of the supporting agreements / contracts or are you against the goal and such standards?
I did not see supporting standardized contracts for the documents at ITIL.
Did I miss them? Are they less than a few weeks old?
--
You received this message because you are subscribed to the Google Groups
"Cloud Computing Use Cases" group.
To post to this group, send email to
cloud-comput...@googlegroups.com.
To unsubscribe from this group, send email to cloud-computing-us...@googlegroups.com.
Tom Hanan
I have also seen that a very small amount of well crafted and practically unintelligible legalese outside the context of the SLA and or SLO completely eliminate any legitimate recourse. This is what changed my focus years ago to availability “assurance” through “diversity” instead of allowing lawyers to confuse the difference between a promise made and one fulfilled.
As I have said here many times the bulk of all agreements are really “best effort” when you get in front of a judge or arbiter. So why not admit it and architect your offerings and solutions to make that work for everyone instead of against everyone.
A friend of mine, a corporate lawyer, once told me that his job in creating language for contracts was that of a street magician.
1) No one signs until they “believe” they know which shell the pea is hidden under.
2) Everything is fine until someone turns over the last shell and find out there is no pea!
In the case of most deployment agreements, that reference but supersede their attachments, there is no practical recourse which matches the actual damage due to the failure and therefore no pea! The pea is the value and ability of anyone to make a greater assurance than “I will not financially penalize you or block you from moving volume when I do not fulfill it.” That is a very simple statement to describe even in legalese!
So why not eliminate the pea and the shell game to begin with?
Thus is the goal of SDH.
Understand what you “need” from a deployment and “pay” for what you get.
David Moskowitz
Depending on the organizations involved, the lawyers will write the contracts and may very well be that the cloud-provider lawyers have a standard contract. The instant you define an SLA either with legal language or in the title of the document, it is more than likely it will be lawyers who handle the bulk of the negotiations. I don't think that is your intent.
Insurance companies are in a regulated industry with most terms and conditions (or at least the boundaries on the terms and conditions) are set by the various States. Cloud-computing isn't (at least not yet) subject to the same oversight.
Please review my message about "vendor homework" to determine patterns of likely activity that should lead to the discovery of packages or tiers of service -- with each tier covered by an appropriate SLA (separate from the contract but made part of the contract by reference as Appendix Q (or whatever)).
I just happened to look at this now and have to leave to pick up someone at the airport, so I'll have more either later tonight or tomorrow.
David
Tom Hanan
If you can’t keep it real,
Don’t do the deal!
From: cloud-comput...@googlegroups.com [mailto:cloud-comput...@googlegroups.com] On Behalf Of David Moskowitz
Sent: Thursday, January 06, 2011 12:03 PM
Subject: Re: [Cloud Computing Use Cases 1109] Re: SLA
Tom Hanan
Sounds good.
Let’s look at this from the heterogeneous portability aspect.
That is where the differences in our comments seem to be centered.
I look forward to your feedback.
--
David Moskowitz
Sounds good.
Let’s look at this from the heterogeneous portability aspect.
That is where the differences in our comments seem to be centered.
I look forward to your feedback.
From: cloud-comput...@googlegroups.com [mailto:cloud-comput...@googlegroups.com] On Behalf Of David Moskowitz
Sent: Saturday, January 08, 2011 5:54 PM
Subject: Re: [Cloud Computing Use Cases 1119] Re: SLA
--
You received this message because you are subscribed to the Google Groups "Cloud Computing Use Cases" group.
To post to this group, send email to cloud-comput...@googlegroups.com.
To unsubscribe from this group, send email to cloud-computing-us...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cloud-computing-use-cases?hl=en.
Miha Ahronovitz
SHDP & SHLA. ?
SLA, SHLA, SHD, SHDP, SHLA.
I appreciate your honesty, you don't know
quote---
relationship between multiple cloud vendors to a single client. What
I'm
really saying is that I don't know how to structure the agreement in a
way I
could actually recommend that clients accept.
So if you don't know, the thousands of readers on this forum were
anxiously waiting for someone who know.
My 2 cents. There is NOT a unique SLA (all other acronyms are
impractical) Yet the hosting , colocation and cloud industry thrives.
The best way is to read the agreements of RackSpace, AWS,
Savvis,CloudSigma you name who else to include see what you like, see
what it's not applicable, add your stuff if you think it's important.
and write yout HLA or SHDLA, but please call it SLA . Any other name
will awake suspicions in customers.
If you get an objection from a key customer, be flexible. Change
according to the request(or as closely as possible to the request) in
exchange for more money to cover the risk. Never say No. Say, yes, we
will do it, by this will cost you 3X, instead of X.
Miha
On Jan 12, 10:09 pm, David Moskowitz <david.moskow...@gmail.com>
wrote:
>
> To address your point about"heterogeneous portability aspect"... I
> mentioned I would respond later and didn't... until now. :-)
>
> I agree that a heterogeneous relationship reduces risks on both providers
> and consumers of the service(s). Ultimately there is going to be (or should
> be) a prime contractor that will be the customer's single point of contact.
> I do (and have) recommended clients make sure there is a defined, clear,
> and unambiguous accountability to the client for the cloud services. I
> recommend the client avoid a decision tree (or conditional use-case) to
> figure out who to call if there are issues with the cloud (as service).
>
> I do not know how to structure a SLA that surfaces heterogeneous
> relationship between multiple cloud vendors to a single client. What I'm
> really saying is that I don't know how to structure the agreement in a way I
> could actually recommend that clients accept. The various vendor
> organizations need to determine how they are going to collaborate with each
> other. The customer wants the heterogeneity at the supply end and
> homogeneity at the support end.
>
> David
>
>
> > Sounds good.
>
> > Let’s look at this from the heterogeneous portability aspect.
>
> > That is where the differences in our comments seem to be centered.
>
> > I look forward to your feedback.
>
> > cloud-comput...@googlegroups.com] *On Behalf Of *David Moskowitz
>
> > *To:* cloud-comput...@googlegroups.com
> > *Subject:* Re: [Cloud Computing Use Cases 1119] Re: SLA
> > Tom,
>
> > Depending on the organizations involved, the lawyers will write the
> > contracts and may very well be that the cloud-provider lawyers have a
> > standard contract. The instant you define an SLA either with legal language
> > or in the title of the document, it is more than likely it will be lawyers
> > who handle the bulk of the negotiations. I don't think that is your intent.
>
> > Insurance companies are in a regulated industry with most terms and
> > conditions (or at least the boundaries on the terms and conditions) are set
> > by the various States. Cloud-computing isn't (at least not yet) subject to
> > the same oversight.
>
> > Please review my message about "vendor homework" to determine patterns of
> > likely activity that should lead to the discovery of packages or tiers of
> > service -- with each tier covered by an appropriate SLA (separate from the
> > contract but made part of the contract by reference as Appendix Q (or
> > whatever)).
>
> > I just happened to look at this now and have to leave to pick up someone at
> > the airport, so I'll have more either later tonight or tomorrow.
>
> > David
>
>
> read more »
Tom Hanan
Thanks for the candid response.
Your points about “points of responsibility” are well taken.
I think you will be pleased by what comes out in the near future.
It will include Multi vendor SLA as well as provisions for prime contractors who aggregate the multivendor relationship(s) into a single customer facing relationship.
Here are some probable prime contractor business models:
1) Prime contractor will be a deployment teams’ primary infrastructure vendor.
2) Prime contractor will be a third party who aggregates multiple vendors into a heterogeneous deployment by providing varying levels of service & support.
3) Prime contractor will be a virtual infrastructure provider aggregating all their customers in to a single heterogeneous load while providing levels of service & support.
The above examples cover a very wide and diverse set of existing business models for cloud deployments.
To be frank all of them already exist to some degree or another!
Anyone interested in understanding the unique nature of HDPC (Heterogeneous Deployment Prime Contractor) opportunities is welcome to contact me privately.
It’s a field that will no doubt experience rapid growth among existing and emerging players.
Tom Hanan
If you can’t keep it real,
Don’t do the deal!
Tom Hanan
Miha,
Your request to call a Simplified Heterogeneous SLA just that is warranted and a good one that I will incorporate.
Please be patient I am trying to incorporate received suggestions here and elsewhere that I think will make the first draft both simple and comprehensive enough so others can productively comment upon and improve it.
-Tom
David Moskowitz
I know this is possible, though I'm not suggesting it's easy.
As I was writing this message the following popped up on twitter:
@stephenmann 1:37pm via HootSuite Interesting comment from #Diligenta customer this morning. They manage outsourced services by agreed objectives rather than the contract.
David