I\u2019ve attended countless cloud presentations discussing vendor relationships and contract agreements. A common feature of these presentations is a discussion of the Service Level Agreement (SLA) and how to define, negotiate and enforce it. I\u2019ve always found this curious, but felt it was a relatively harmless, if not terribly, useful topic.\nNo longer. If you invest significant effort on a contractual SLA you\u2019re not only wasting time, you\u2019re focusing on the wrong thing. The SLA, if it ever made sense as a key contract topic, does so no longer. The traditional SLA is dead. Here\u2019s why:\nSLAs Are Pointless\nPeople spend time on SLAs because they think they\u2019ll make the cloud provider pay attention to availability. Guess what? They already spend time on availability and work really hard at it. Believing that your negotiation smarts are going to generate something above and beyond that from the provider is wrong. Outages happen and cloud providers respond as quickly as possible.\nIn any case, cloud providers recognize outages will occur, no matter how hard they try. So their standard contracts abjure responsibility for outages and never, ever promise anything beyond best efforts to restore availability as soon as possible. And your negotiation won\u2019t change that. I remember seeing one presentation, where, after spending over an hour on negotiating SLAs, the speaker took a question: \u201cHow flexible are cloud providers on SLAs?\u201d His response: \u201cIt depends. The larger providers refuse to make any changes and the smaller providers will sign anything to get the business.\u201d In other words, all your negotiating prowess will be fruitless, in the end.\nIn any event, the penalties associated with SLAs won\u2019t make you whole. They offer a refund of fees due the provider for the outage period. Not what you lost because your website wasn\u2019t available. If you want to be compensated for that, they\u2019ll steer you to an insurance company for continuity insurance. And guess what? That\u2019s expensive and not easy to obtain. So thinking that there\u2019s an easy legal solution for availability is just plain wrong.\nSLAs Are Distracting\nThe biggest problem with a focus on SLA is that it frames the issue incorrectly. It addresses a problem -- infrastructure failure -- with the wrong solution -- legal. Now, don\u2019t expect your legal or finance people to tell you this. As the Sage of Omaha, Warren Buffet says, \u201cNever ask a barber if you need a haircut.\u201d If you ask your lawyer if you should spend time on the SLA, he or she will -- of course -- tell you yes. That\u2019s their haircut.\nIt also has the inevitable effect of directing you toward providers willing to be responsive to SLA discussions, instead of directing you toward providers with more important characteristics: large capacity, a broad ecosystem and a rich set of services with which to build innovative applications.\nYour world is changing -- dramatically. This is an IT-forward economy, and failing to arm yourself with the right tools puts you at an enormous handicap. Spending time seeking a legal solution means time not spent on creating innovation, and every day you lose is a day you\u2019ll never recover.\nThe Right Way to Address Infrastructure Failure\nSo if the SLA is the wrong solution, what\u2019s the right one? In a word, technical. You have to engineer your applications to provide availability and recognize what characteristics your solutions need:\n\nRedundancy. It used to be the application paradigm was \u201creliable hardware, unreliable software.\u201d Because applications weren\u2019t reliable, everything was focused on making them simple and putting them onto rock-solid infrastructure. The only problem with that is that it severely limited application functionality, which is no longer tenable in an IT-infused world -- and those new applications are inevitably going to be more complex. The new mantra is \u201creliable applications, unreliable infrastructure.\u201d This has two implications. First, your infrastructure is liable to fail, so you can\u2019t design assuming a stable environment. Second, some part of your application very likely will fail. Both of these mean you have to avoid SPOF -- single point of failure -- which, in turn, means you have to implement a redundant application topology. So plan on redundancy from the very start of designing your application.\nPartitioning. The old model of simple application architectures means that they\u2019re deployed in huge monolithic stacks. It\u2019s difficult to put out a fix or improvement in the app because any change requires enormous integration and testing, so updates are infrequent. The solution to that is partitioning -- or, as the new buzzword puts it, microservices. Breaking the application down into self-contained, separately operating components communicating via RESTful interfaces allows easier updates and more rapid improvement. It\u2019s not as easy as it sounds, however. Netflix, the pioneer and exemplar of microservices had an outage last week, so even the best are challenged with this model. Make no mistake, though, this is the path of the future, and the sooner you begin pursuing it, the better.\nElasticity and automation. Another characteristic of the new model of applications is how much their traffic varies, requiring changes to the application topology to add or remove computing components. All of this topology modification means that the application has to be able to gracefully integrate and shed components -- in a word, be elastic. The only way to achieve this is to implement operational management via automation. This carries a set of requirements, including use of standardized components, automated configuration, application monitoring, and using metrics and analytics to understand application behavior.\n\nThe entire concept of an SLA is offloading risk, transferring responsibility to another party. In the new world of applications, unfortunately, that\u2019s not feasible. I believe the next few years will be extremely challenging as practitioners come to grips with designing and operating applications to fit the new paradigm of redundant, partitioned components. Trying to avoid this, or worse, resist it via an insistence upon ever-more stringent vendor SLAs is, at best, misguided, and, at worst, irresponsible.