DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Software Design and Architecture
  3. Cloud Architecture
  4. Why an Application SLA Must Match Your Infrastructure

Why an Application SLA Must Match Your Infrastructure

The cloud != high availability. Sure, you can minimize your risk by leveraging widespread servers, but you still need to invest in your infrastructure.

Eric Wright user avatar by
Eric Wright
·
Apr. 28, 17 · Opinion
Like (1)
Save
Tweet
Share
6.59K Views

Join the DZone community and get the full member experience.

Join For Free

There is no doubt that you’ve seen the use of the mathematical operator <= meaning ‘less than or equal to’ at the other side of the equation. The reason that this is important is that it relates to the assigning of application SLA (Service Level Agreement) metrics to your applications.

In other words, you have to know both the application and the infrastructure side of the equation, and the application side will always be less than or equal to the SLA of the underlying infrastructure.

SLA Turtles All the Way Down

If you have an application that has a 99.99 percent uptime requirement, it has to be on infrastructure that has a 99.99 percent uptime. That SLA will need to be from the top layer of the application, including RPO (Recover Point Objective) and RTO (Recover Time Objective). Making that promise on-premises has already been a challenge that some have faced and learned about the hard way.

Think that AWS is the answer to your SLA? Perhaps we should look back to the recent S3 outage that took the world by storm and left many organizations having to explain why they were hit by service issues despite being on the cloud. Remember that the cloud does not give you automatic resiliency. It does however give you the ability to leverage geographically dispersed infrastructure in a resilient manner. There are still issues which can be localized and cause significant outages.

Amazon Web Services  ✔  @awscloud
The dashboard not changing color is related to S3 issue. See the banner at the top of the dashboard for updates.

That tweet sums it up rather beautifully if you ask me. AWS themselves had their own service status dashboard fail because it was hosted on the very infrastructure that suffered the outage. There is a strange irony in that.

Know Your Underlay

In order to boost your application SLA, you have to architect it on underlying infrastructure that has an SLA which is greater than the SLA you require for the application itself. Even in the cloud you have to think bigger. It could be a matter of cross-region design, or in some cases an even more resilient underlay design that is cross-cloud.

The important thing that you should take away from this is that the SLA of the application can only be higher than the underlying infrastructure at any single layer if the layer above that spans multiple service layers that subsequently gives it a higher SLA. In other words, you can combine lower SLA services at one layer, but span multiple regions/zones/clouds above it and that makes that layer less impactful on the total SLA because we’ve avoided the single point of failure.

Don’t take that as advice to run on spinning disks and think that HA proxy will save you from drive failures. You still have to architect the data to be shared across the boundaries, and the application must be able to recover gracefully when outages and significant slowdowns occur.

This also doesn’t deal with performance in any way. That’s a whole separate issue altogether. The SLA and associated RPO/RTO metrics are about availability and recoverability during significant business and technical disruptions.

Best advice you can get: build it to fail by design. As the SLA approaches 100% availability, the costs and effort rise significantly to get there. It’s like an exponential growth curve where availability is the X-axis and cost is the Y-axis. Once you begin to build a practice of designing for failure, the application designs that come later will win the benefits of learnings and services you’ve created for those first ones.

It may seem expensive to design for failure, but how much does failure cost you? I’m betting on the design strategy myself.

application Infrastructure Amazon Web Services

Published at DZone with permission of Eric Wright, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Kotlin Is More Fun Than Java And This Is a Big Deal
  • Load Balancing Pattern
  • Asynchronous HTTP Requests With RxJava
  • Why You Should Automate Code Reviews

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: