{"id":45134,"date":"2021-08-31T12:18:54","date_gmt":"2021-08-31T16:18:54","guid":{"rendered":"https:\/\/sdtimes.com\/?p=45134"},"modified":"2021-08-31T15:45:40","modified_gmt":"2021-08-31T19:45:40","slug":"slos-the-heart-of-reliability-practices","status":"publish","type":"post","link":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/","title":{"rendered":"SLOs: The heart of reliability practices"},"content":{"rendered":"

The most challenging principle of Agile is \u201csimplicity \u2014 the art of maximizing the amount of work not done.\u201d<\/span><\/p>\n

Developers waste immense cycles trying to avoid software failure. Rather than defining \u201cgood enough\u201d reliability and stopping there, teams go way beyond the point of diminishing returns, building what is jokingly referred to as \u201cgold plated\u201d reliability infrastructure around their software. Fear of failure has instilled an all-or-nothing mindset to software reliability that is the opposite of Agile simplicity.<\/span><\/p>\n

The reason developers overbuild for reliability \u2014 and there are many ways you can over-engineer for performance, uptime, high availability, even security \u2014 is that they never really had a way to define \u201cgood enough\u201d reliability in the first place. Without a clear picture of success or a clear finish line, developers can’t readily communicate with the organization. The big boss wants 100% reliability, and that leads to eye rolls from engineers.<\/span><\/p>\n

Eureka! SLOs Forever Changed What I Thought I Knew About Reliability<\/b><\/h5>\n

After Google acquired a company I co-founded, we had to re-platform the entire solution to run on Google Cloud Platform. We got a crash course in the site reliability engineering (SRE) practices that run some of the world\u2019s most popular web services at Google. Once you experience Service Level Objectives (SLOs) as I did, you will never be the same.<\/span><\/p>\n

SLOs are the heart of Google\u2019s reliability engineering practice. SLOs are a math-based discipline of setting goals that model the reliability of cloud services. SLOs are an evolution of SLAs (\u201cservice level agreements\u201d) but more fine-grained and designed for consistent slight overachievement over time that yields happy customers (as opposed to SLAs, whose violation represents a total disaster). Google uses SLOs to make better decisions in managing software and cloud services.<\/span><\/p>\n

SLOs give developers a way to take the expected behavior of applications out of their brains and codify these outcomes so that product teams can track them.<\/span><\/p>\n

To be more precise, <\/span>SLOs<\/span><\/i> take software events and set a mathematical proportion of \u201cvalid events\u201d as a percentage of total events. SLOs are mapped to crucial application and system intervals and are representations of user success that you can modify over time. For example, a developer might set an SLO that an HTTP GET request for an API takes less than two milliseconds, 99.99% of the time. Or a developer might set an SLO for a specific user outcome to define success in a multi-part transaction (what\u2019s a \u201cgood\u201d success rate for a shopping cart checkout in an e-commerce transaction?).\u00a0<\/span><\/p>\n

Error Budgets<\/span><\/i> are a conceptual model for understanding acceptable risk in your services. The idea is that your team plans for (or \u201cbudgets\u201d) some small amount of error that customers won\u2019t notice much and \u201cspend\u201d that budget to make the service better. Error rates rise and fall throughout the day or month, affecting your tolerance for the additional risk. The error budget vividly expresses how to balance many competing priorities across a large-scale software organization. And you can use error budgets to trigger automation and on-call staff proactively as the foundation of your observability stack.<\/span><\/p>\n

SLOs Fill the White Spaces Between Dev and Ops for Agile Teams<\/b><\/h5>\n

Sometimes it seems like developers and operators speak two different languages. Devs are interested in pushing code, making apps work for users, and quickly getting new ideas to life. The limit of their interest in reliability is whether they are getting woken up when their app breaks. In contrast, operators need to look at the core infrastructure and think about resource utilization, noisy neighbors, broadly applicable services for various apps, and how the overall system orchestrates to deliver constant, consistent, reliable value to customers.<\/span><\/p>\n

The work not done by the developer creates a need for gold-plated infrastructure from the operators. The conversation not had between dev and ops leads to a disconnect in designing the services (for customers to be happy) and the engineering system (for engineers to be productive).\u00a0<\/span><\/p>\n

The main benefit of SLOs is that you know you can focus resources on your most critical services because you understand what degree of <\/span>un<\/span><\/i>-reliability is OK for the lower impact areas. Counterintuitively, by lowering reliability goals where it matters less (basically any time the user is likely to blame their internet connection), you can focus on what matters. The work not done by the service in less critical areas allows for increased resiliency — from engineering and cloud capacity — in the essential purpose of our customers, as defined by SLOs.<\/span><\/p>\n

SLOs are the language for this conversation that\u2019s been missing, and these are the decision points that allows developers and operations to navigate around software reliability:<\/span><\/p>\n

New Features Versus Technical Debt<\/strong><\/h5>\n

Agile teams face a constant decision-point on new features versus settling technical debt that may be causing customers pain. When is the right time to go spend months refactoring code that is not optimized? How do you know you aren’t spending cycles on a problem that currently isn’t even giving users pain? If you have modeled an SLO, you have a clear compass for making that decision.<\/span><\/p>\n

Complex Workflows Without a Definition of ‘Success’<\/strong><\/h5>\n

Many user journeys today traverse multiple APIs and multiple steps within your applications. Password reset is the canonical example that the SLO community calls out to describe why these are problematic to model success in any “five nines” type of way. A password reset is contingent on the user entering their email correctly, the reset email not getting caught in a spam filter, the transactional email systems working correctly, and the user completing the process. You may find that for your \u201cforgot password\u201d system, 70 percent is the general expected success rate. And there are countless examples of this type of complicated workflow where you can’t just look at the metrics of the individual systems; you have to look at the totality of the user experience and define success rates that describe user happiness. SLOs allow you to codify the expected outcome and to adjust that outcome success rate upwards or downwards based on the data you are getting.<\/span><\/p>\n

Guardrails for What You Can’t Test\u00a0<\/strong><\/h5>\n

Testing is great, and testing isn’t going away. Unit testing, end-to-end testing, and integration testing all have their place in the software development lifecycle. But the reality today is that you simply cannot test every scenario in dev or staging in a way that will cover all the unforeseen ways that things break in production. SLOs give you another guardrail around your systems in production that lets you see through all the beeps and pages from APM and logging tools to get to the essence of whether your software is behaving in expected ways.<\/span><\/p>\n

Dependencies Between Teams<\/strong><\/h5>\n

A really popular target for SLOs is APIs. SLOs allows you to define the latency or other performance vectors of the APIs you create. If the quota you set is 10ML of latency for your API, but something changes in a system that brings that up to 50ML of latency, SLOs give you a method of seeing which team violates the Error Budget for that SLO. This tradeoff makes SLOs an excellent fit for the “self-organizing teams” principle of Agile, where teams need ways to move independently while also understanding how their work is impacting other groups.<\/span><\/p>\n

The Work Not Done is Getting Started<\/b><\/h5>\n

I\u2019ve talked with countless organizations frustrated with over-building reliability, but they can\u2019t get out of that mindset because they feel so inundated with critical issues. They\u2019ve got so much technical debt that they can\u2019t stop digging.\u00a0<\/span><\/p>\n

If there\u2019s one thing I recommend to everyone, it\u2019s to start thinking about how to benchmark your users\u2019 expectations based on how your service works today and figure out what truly matters to them. Having wrong SLOs and iterating is infinitely better than having no goals and waiting to decide what is most critical. Better to get ahead of making your service work for users before they vote with their feet.\u00a0<\/span><\/p>\n

Don\u2019t put your customers and engineers in the gilded cage of the reliability work not done or even started.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

The most challenging principle of Agile is \u201csimplicity \u2014 the art of maximizing the amount of work not done.\u201d Developers waste immense cycles trying to avoid software failure. Rather than defining \u201cgood enough\u201d reliability and stopping there, teams go way beyond the point of diminishing returns, building what is jokingly referred to as \u201cgold plated\u201d … continue reading<\/a><\/p>\n","protected":false},"author":1040,"featured_media":45135,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"om_disable_all_campaigns":false,"cybocfi_hide_featured_image":"","footnotes":"","_links_to":"","_links_to_target":""},"categories":[1],"tags":[132,254,15856],"coauthors":[15855],"acf":[],"yoast_head":"\nSLOs: The heart of reliability practices - SD Times<\/title>\n<meta name=\"description\" content=\"Service level objectives (SLOs) give developers a way to take the expected behavior of applications out of their brains.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"SLOs: The heart of reliability practices - SD Times\" \/>\n<meta property=\"og:description\" content=\"Service level objectives (SLOs) give developers a way to take the expected behavior of applications out of their brains.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/\" \/>\n<meta property=\"og:site_name\" content=\"SD Times\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/SDTimesD2\" \/>\n<meta property=\"article:published_time\" content=\"2021-08-31T16:18:54+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2021-08-31T19:45:40+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/sdtimes.com\/wp-content\/uploads\/2021\/08\/rope-1468951_640.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"640\" \/>\n\t<meta property=\"og:image:height\" content=\"423\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Brian Singer\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@sdtimes\" \/>\n<meta name=\"twitter:site\" content=\"@sdtimes\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Brian Singer\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/\"},\"author\":{\"name\":\"Brian Singer\",\"@id\":\"https:\/\/sdtimes.com\/#\/schema\/person\/384292b057401b607be5960e5570c646\"},\"headline\":\"SLOs: The heart of reliability practices\",\"datePublished\":\"2021-08-31T16:18:54+00:00\",\"dateModified\":\"2021-08-31T19:45:40+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/\"},\"wordCount\":1359,\"publisher\":{\"@id\":\"https:\/\/sdtimes.com\/#organization\"},\"image\":{\"@id\":\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/sdtimes.com\/wp-content\/uploads\/2021\/08\/rope-1468951_640.jpg\",\"keywords\":[\"agile\",\"DevOps\",\"SLOs\"],\"articleSection\":[\"Latest News\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/\",\"url\":\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/\",\"name\":\"SLOs: The heart of reliability practices - SD Times\",\"isPartOf\":{\"@id\":\"https:\/\/sdtimes.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/sdtimes.com\/wp-content\/uploads\/2021\/08\/rope-1468951_640.jpg\",\"datePublished\":\"2021-08-31T16:18:54+00:00\",\"dateModified\":\"2021-08-31T19:45:40+00:00\",\"description\":\"Service level objectives (SLOs) give developers a way to take the expected behavior of applications out of their brains.\",\"breadcrumb\":{\"@id\":\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#primaryimage\",\"url\":\"https:\/\/sdtimes.com\/wp-content\/uploads\/2021\/08\/rope-1468951_640.jpg\",\"contentUrl\":\"https:\/\/sdtimes.com\/wp-content\/uploads\/2021\/08\/rope-1468951_640.jpg\",\"width\":640,\"height\":423},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/sdtimes.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"SLOs: The heart of reliability practices\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/sdtimes.com\/#website\",\"url\":\"https:\/\/sdtimes.com\/\",\"name\":\"SD Times\",\"description\":\"Software Development News\",\"publisher\":{\"@id\":\"https:\/\/sdtimes.com\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/sdtimes.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/sdtimes.com\/#organization\",\"name\":\"SD Times\",\"url\":\"https:\/\/sdtimes.com\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/sdtimes.com\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/sdtimes.com\/wp-content\/uploads\/2014\/05\/deafaultlogo.png\",\"contentUrl\":\"https:\/\/sdtimes.com\/wp-content\/uploads\/2014\/05\/deafaultlogo.png\",\"width\":225,\"height\":90,\"caption\":\"SD Times\"},\"image\":{\"@id\":\"https:\/\/sdtimes.com\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/SDTimesD2\",\"https:\/\/x.com\/sdtimes\",\"https:\/\/www.linkedin.com\/company\/sdtimes\/\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/sdtimes.com\/#\/schema\/person\/384292b057401b607be5960e5570c646\",\"name\":\"Brian Singer\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/sdtimes.com\/#\/schema\/person\/image\/524d623b522473e8ef577f51319ba1ad\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/5c0b0a940dc327eb0ab3193455e257eb?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/5c0b0a940dc327eb0ab3193455e257eb?s=96&d=mm&r=g\",\"caption\":\"Brian Singer\"},\"description\":\"Brian Singer is chief product officer at Nobl9.\",\"url\":\"https:\/\/sdtimes.com\/author\/brian-singer\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"SLOs: The heart of reliability practices - SD Times","description":"Service level objectives (SLOs) give developers a way to take the expected behavior of applications out of their brains.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/","og_locale":"en_US","og_type":"article","og_title":"SLOs: The heart of reliability practices - SD Times","og_description":"Service level objectives (SLOs) give developers a way to take the expected behavior of applications out of their brains.","og_url":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/","og_site_name":"SD Times","article_publisher":"https:\/\/www.facebook.com\/SDTimesD2","article_published_time":"2021-08-31T16:18:54+00:00","article_modified_time":"2021-08-31T19:45:40+00:00","og_image":[{"width":640,"height":423,"url":"https:\/\/sdtimes.com\/wp-content\/uploads\/2021\/08\/rope-1468951_640.jpg","type":"image\/jpeg"}],"author":"Brian Singer","twitter_card":"summary_large_image","twitter_creator":"@sdtimes","twitter_site":"@sdtimes","twitter_misc":{"Written by":"Brian Singer","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#article","isPartOf":{"@id":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/"},"author":{"name":"Brian Singer","@id":"https:\/\/sdtimes.com\/#\/schema\/person\/384292b057401b607be5960e5570c646"},"headline":"SLOs: The heart of reliability practices","datePublished":"2021-08-31T16:18:54+00:00","dateModified":"2021-08-31T19:45:40+00:00","mainEntityOfPage":{"@id":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/"},"wordCount":1359,"publisher":{"@id":"https:\/\/sdtimes.com\/#organization"},"image":{"@id":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#primaryimage"},"thumbnailUrl":"https:\/\/sdtimes.com\/wp-content\/uploads\/2021\/08\/rope-1468951_640.jpg","keywords":["agile","DevOps","SLOs"],"articleSection":["Latest News"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/","url":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/","name":"SLOs: The heart of reliability practices - SD Times","isPartOf":{"@id":"https:\/\/sdtimes.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#primaryimage"},"image":{"@id":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#primaryimage"},"thumbnailUrl":"https:\/\/sdtimes.com\/wp-content\/uploads\/2021\/08\/rope-1468951_640.jpg","datePublished":"2021-08-31T16:18:54+00:00","dateModified":"2021-08-31T19:45:40+00:00","description":"Service level objectives (SLOs) give developers a way to take the expected behavior of applications out of their brains.","breadcrumb":{"@id":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#primaryimage","url":"https:\/\/sdtimes.com\/wp-content\/uploads\/2021\/08\/rope-1468951_640.jpg","contentUrl":"https:\/\/sdtimes.com\/wp-content\/uploads\/2021\/08\/rope-1468951_640.jpg","width":640,"height":423},{"@type":"BreadcrumbList","@id":"https:\/\/sdtimes.com\/agile\/slos-the-heart-of-reliability-practices\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/sdtimes.com\/"},{"@type":"ListItem","position":2,"name":"SLOs: The heart of reliability practices"}]},{"@type":"WebSite","@id":"https:\/\/sdtimes.com\/#website","url":"https:\/\/sdtimes.com\/","name":"SD Times","description":"Software Development News","publisher":{"@id":"https:\/\/sdtimes.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/sdtimes.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/sdtimes.com\/#organization","name":"SD Times","url":"https:\/\/sdtimes.com\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/sdtimes.com\/#\/schema\/logo\/image\/","url":"https:\/\/sdtimes.com\/wp-content\/uploads\/2014\/05\/deafaultlogo.png","contentUrl":"https:\/\/sdtimes.com\/wp-content\/uploads\/2014\/05\/deafaultlogo.png","width":225,"height":90,"caption":"SD Times"},"image":{"@id":"https:\/\/sdtimes.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/SDTimesD2","https:\/\/x.com\/sdtimes","https:\/\/www.linkedin.com\/company\/sdtimes\/"]},{"@type":"Person","@id":"https:\/\/sdtimes.com\/#\/schema\/person\/384292b057401b607be5960e5570c646","name":"Brian Singer","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/sdtimes.com\/#\/schema\/person\/image\/524d623b522473e8ef577f51319ba1ad","url":"https:\/\/secure.gravatar.com\/avatar\/5c0b0a940dc327eb0ab3193455e257eb?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/5c0b0a940dc327eb0ab3193455e257eb?s=96&d=mm&r=g","caption":"Brian Singer"},"description":"Brian Singer is chief product officer at Nobl9.","url":"https:\/\/sdtimes.com\/author\/brian-singer\/"}]}},"_links":{"self":[{"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/posts\/45134"}],"collection":[{"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/users\/1040"}],"replies":[{"embeddable":true,"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/comments?post=45134"}],"version-history":[{"count":2,"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/posts\/45134\/revisions"}],"predecessor-version":[{"id":45140,"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/posts\/45134\/revisions\/45140"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/media\/45135"}],"wp:attachment":[{"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/media?parent=45134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/categories?post=45134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/tags?post=45134"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/sdtimes.com\/wp-json\/wp\/v2\/coauthors?post=45134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}