{"id":665,"date":"2021-08-31T22:07:00","date_gmt":"2021-08-31T12:07:00","guid":{"rendered":"https:\/\/sysmit.com\/cf22\/?p=665"},"modified":"2023-12-13T15:28:02","modified_gmt":"2023-12-13T05:28:02","slug":"sre-unique-approach-to-work","status":"publish","type":"post","link":"https:\/\/sysmit.com\/cf22\/sre-unique-approach-to-work\/","title":{"rendered":"How SREs are unique in their approach to work"},"content":{"rendered":"\n
Site Reliability Engineers (SREs) are a rare bunch in the software community. But there\u2019s little denying that the approach of Site Reliability Engineering is the future of software operations.<\/p>\n\n\n\n
Here are some things that make SREs a unique breed in software work:<\/p>\n\n\n
Ask any developer what they\u2019re working on and you\u2019ll see a tiny sliver of the whole codebase. That makes sense for the kind of work that is coding.<\/p>\n\n\n\n
Systems, on the other hand, need a holistic view<\/strong> in order to make sure the whole unit works harmoniously.<\/p>\n\n\n Because they have a scope spanning the entirety of a software system, SREs can end up working on various types of problems. Some problems may be well-defined like spooling up infrastructure based on known demand.<\/p>\n\n\n\n Other problems may be more abstract like working out how to cost-effectively autoscale a service that has inconsistent usage patterns and needs high performance.<\/p>\n\n\n Most developers work within some kind of agile framework like Scrum or XP. <\/p>\n\n\n\n Some SREs also do that for planned software build work. That essentially timeboxes their efforts. <\/p>\n\n\n\n That might work for estimable problems but does not always work for production-level work<\/strong>.<\/p>\n\n\n\n Can an SRE stop working on a problem because it does not fit into the mold of a sprint? That could spell disaster for production software. Daniel Wilhite answers the question of\u00a0\u201cCan scrum be used effectively by SRE teams?\u201d<\/a>\u00a0very well.<\/p>\n\n\n\n\n You\u2019d expect SREs to get used to developers throwing the code over the wall, but no. <\/p>\n\n\n\n Many Site Reliability Engineers began their careers as developers<\/strong>, so they will spend a large part of their time coding up solutions for infrastructure and software performance.<\/p>\n\n\n\n Sometimes, they may participate in feature teams as a means of job rotation. This helps them get a better understanding of their developer counterparts\u2019 priorities. <\/p>\n\n\n SREs come in many shapes and sizes. In smaller companies, a single SRE may be the one-stop-shop for all site reliability matters. As a company gets larger, SRE roles may get divided into specialized work<\/strong>.<\/p>\n\n\n\n For example, one SRE may focus on platforms like Kubernetes. <\/p>\n\n\n\n Another SRE may spend their time supporting developers in taking up DevSecOps. <\/p>\n\n\n\n Yet another may have general SRE responsibilities with the addition of Chaos Engineering.<\/p>\n\n\n Both roles are chalk and cheese, so it\u2019s worth considering key differences in how SREs work compared to software developers. <\/p>\n\n\n\n Chances are they will need to collaborate closely to make sure the software works well in production.<\/p>\n\n\n\n I took inspiration from a Google recruiter\u2019s interview of an SRE, Ciara Kamahele (link here<\/a>). <\/p>\n\n\n\n The key differences I uncovered are in table form below:<\/p>\n\n\n\nSREs thrive in ambiguity<\/h2>\n\n\n
SREs work beyond constraints like Scrum<\/h2>\n\n\n
SREs don\u2019t stay in their lane<\/h2>\n\n\n
SREs don\u2019t have a monolith job description<\/h2>\n\n\n
Comparison with software developers<\/h2>\n\n\n