Author: JP Cheung

  • Best of 2022: SRE Vs. Platform Engineering: What’s the Difference?

    Best of 2022: SRE Vs. Platform Engineering: What’s the Difference?

    As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    Site reliability engineering (SRE) teams and platform engineering teams share similar goals—like maximizing automation and reducing toil—and similar methodologies. But they have different priorities, and use somewhat different tools to achieve them.

    What are SREs? What are platform engineers? How is each role similar and different? This article will answer all your questions.

    Responsibilities of SREs and Platform Engineers

    The main responsibility of site reliability engineers is ensuring that IT systems are reliable, which means that the systems meet performance requirements. Part of their job includes working with developers and IT operations teams to maximize the reliability of applications as they move down the software delivery pipeline.

    Meanwhile, platform engineers focus on managing and optimizing the software delivery process. You could think of this role as one that translates DevOps principles into practice by finding ways to implement continuous delivery, continuous improvement and other DevOps priorities.

    Thus, both SREs and platform engineers play a role in managing the software delivery process and finding ways to make it as smooth and efficient as possible. They also share a common enemy—toil—in the sense that both groups seek to avoid manual, inefficient processes by automating as much as possible. SREs automate complex incident response operations using tools, for example, while platform engineers might deploy methods like GitOps to automate some aspects of software delivery.

    Differences Between SRE and Platform Engineering

    That said, SRE and platform engineering are distinct roles. The key differences boil down to:

    • Goals: The main job of SREs is maximizing reliability, which is different from optimizing the speed and efficiency of software delivery operations. Theoretically, you could have a highly reliable system even if your software delivery chain is manual and slow.
    • Scope of role: Software delivery operations are the main focus of platform engineers. SREs care about software delivery, too, because the way applications are created plays a role in reliability and fixing issues. But SREs also have many other responsibilities, like incident response and helping to manage infrastructure, which fall beyond the scope of software delivery.
    • Tools: SREs rely on tools that help them discover and solve various types of reliability issues. In contrast, platform engineers leverage tools like source code managers and continuous integration (CI) servers to help automate software delivery.

    So, although SREs and platform engineers may use similar methodologies and possess similar skills, their day-to-day operations tend to look quite different.

    Should You Pursue an SRE or Platform Engineer Career?

    Given the skills overlap between SRE and platform engineering, some engineers are a good fit for either role. But which one is better, from a career perspective?

    Salary-wise, there’s not a whole lot of difference. Glassdoor pegs the average salary of platform engineers at about $115,000 compared to $127,000 for SREs. SREs may earn a little more (and it’s worth noting that SRE salaries can vary widely), but the difference in pay is not as great as that between, say, IT operations engineers (who make a mere $77,000, according to Glassdoor) and SREs.

    The roles are also similar in terms of demand. Unlike software engineering or even DevOps engineering, SRE and platform engineering are both roles that have begun to become popular only in recent years. SRE as a concept has been around for a while—it originated at Google in the early 2000s—but it wasn’t until recently that most companies began seeking SREs for their teams. Likewise, platform engineering didn’t become a thing until the advent of microservices and cloud-native everything pushed companies to devote more engineering resources to manage their increasingly complex software delivery processes.

    What this means is that, at least for now, it’s easy to find jobs in SRE and platform engineering as long as you have the right skills. Many companies are eager to hire for both types of roles.

    Choosing the role that is right for you, then, depends mostly on your preferences and how you like to work. The life of a platform engineer is likely to be somewhat more predictable than that of an SRE because platform engineers don’t have to take the lead in managing incidents when something breaks at 2:00 a.m. On the other hand, SREs enjoy a more diverse set of responsibilities, which can make the job more exciting—especially if software delivery tools like Git or Jenkins don’t make you excited to get out of bed in the morning.

    Conclusion

    Platform engineers and SREs play central roles in automating complex processes and eliminating toil. But they tackle these issues from different angles and they use different tools. The right role for you depends on what you enjoy doing most.

  • The Rogers Outage of 2022: Takeaways for SREs

    The Rogers Outage of 2022: Takeaways for SREs

    When, eight years from now, folks are creating lists of the top IT incidents of the 2020s, there’s a good chance that they’ll include the Rogers outage of 2022. The failure, which made internet and cellular network service unavailable for more than 12 million users across Canada, was one of the most significant outages in memory, in terms of both the number of affected accounts and the level of service disruption.

    For site reliability engineers, there’s a lot to learn from this incident, from both a technical and a crisis-management perspective. Here’s a look at our main takeaways.

    The Rogers Outage: What Happened?

    Before diving into lessons for SREs, let’s go over what happened during the Rogers outage and what we know about the cause of the incident.

    Rogers is a major telecommunications provider that serves around 12 million customers in Canada. Early on July 8, 2022, it suffered an incident with its infrastructure that made internet and wireless phone service unavailable for most or all of its customers. The outage was so complete that users couldn’t even make 911 calls or withdraw money from ATMs–which means the failure brought down not just ordinary services, but also what you might consider resources that are essential for normal daily life.

    Connectivity was restored for most users within about 15 hours. However, some customers reported continuing disruptions for several days after the beginning of the outage.

    What Caused the Rogers Failure?

    At first, Rogers did not reveal much technical detail about what triggered the incident. A statement attributed to the company’s CEO the day after the outage said that a “maintenance update in our core network … caused some of our routers to malfunction.” But that didn’t explain specifically which type of maintenance update the company was trying to apply, why the update didn’t go as planned or which types of routers were affected.

    It wasn’t until several weeks later, when Rogers submitted a response to questions from the Canadian Radio-Television and Telecommunications Commission, that more technical detail came to light. Rogers explained to the CRTC that, during an update process, the company ran code that deleted a routing filter. It’s still unclear exactly how the bad code made its way into the update routine.

    Lessons for SREs

    For SREs, the Rogers outage is an example of a worst-case scenario. It was an extremely disruptive incident that took a relatively long time to mitigate, at least when you consider how severe the outage was. That’s why SREs should use Rogers’ experience to assess what SRE teams can do to avoid issues like this–and manage them more effectively when they do happen.

    Test Your Updates

    From a technical perspective, one of the biggest takeaways from the Rogers outage for SREs is that you should test updates thoroughly before applying them. If engineers had tested their update routine more carefully, they would presumably have detected the bad code that deleted the routing filter before the deletion actually took place.

    To be fair, Rogers is hardly the first company to experience a major outage due to a bad update. Atlassian, for instance, had a similar issue earlier this year, when a buggy migration process caused a long-lasting outage.

    If you’re an SRE, you don’t want your company to be the next to make headlines when something that should be a simple change, like an update, triggers a massive outage. Test, test and test again before bringing your changes into production.

    Build in Redundancy

    It also seems reasonable to conclude that Rogers didn’t have redundancy built into its infrastructure in the form of backup routers that could take over when the primary routers crashed due to the bad update.

    This is another reminder to SREs about why it’s so critical to avoid putting all of your eggs in one basket or creating single points of failure. Redundancy may cost more, and it may not totally prevent disruptions. But it can make them less severe and easier to recover from. It’s not hard to imagine the Rogers incident being a lot less severe if even just 20% or 30% of its traffic could have been automatically redirected to backup routers. That might have been enough to keep critical services operational, at least.

    Have an External Crisis Communications Plan

    Rogers has received more than a little criticism for not communicating well with its customers during the outage. The company waited hours before releasing an initial statement about the failure. It was not very responsive to media queries early on, and, as noted above, it took several weeks before Rogers finally released technical details about what went wrong (and even then, the details emerged only because of a government inquiry into the incident).

    The lack of rapid, transparent communication probably wasn’t deliberate. We have to believe that Rogers didn’t want to leave customers in the dark. Instead, the slow communication likely reflects the absence of a pre-planned strategy for external incident communication in a situation where Rogers’ own networks were non-operational. Without a communications plan, Rogers presumably struggled to decide which information to share, or how to share it, in the midst of a major crisis.

    If Rogers had a playbook in place for communicating with the public and media about this type of issue before its network went down, it probably would have been able to share information more effectively–and it may not have faced as much of a backlash from customers and regulators.

    Internal communications, at least, presumably were smoother. The company did manage to get service back up for most customers within about fifteen hours, which probably would not have happened if its engineers lacked a means of communicating with each other as they worked to resolve the incident.

    Conclusion

    For SREs, the Rogers outage of 2022 is a lesson in the importance of testing, designing redundant infrastructure and preparing for transparent communications before crisis strikes. While more careful planning in these respects may not have totally prevented the incident, it would likely have at least reduced its severity and mitigated the backlash that Rogers now faces from angry customers and regulators.

  • Analyzing SRE Job Postings

    Analyzing SRE Job Postings

    You can find plenty of high-level definitions out on the internet about what site reliability engineering means and what site reliability engineers do.

    But if you want to understand what it’s actually like to work as a site reliability engineer, there is perhaps no better source than job descriptions. SRE job ads explain what real companies are looking for and what they expect on a day-to-day basis.

    To provide insight on what SRE looks like in practice, we’ll look at some job ads from several leading companies. As we’ll see, each company has a slightly different take on what the site reliability engineer role entails, but it’s possible to identify some core themes that underline what businesses expect.

    To understand the content of SRE job descriptions, let’s examine examples from four leading companies.

    GitLab’s Job Ad

    GitLab’s SRE job description contains most of what you would expect from a typical site reliability engineer job ad. It highlights the importance of having a mix of technical skills and collaboration skills. It also emphasizes expertise in areas like Unix/Linux, infrastructure-as-code and Kubernetes.

    What may be slightly surprising, however, is the emphasis that GitLab’s job description places on programming skills. GitLab expects SREs to know how to code in specific languages, like Ruby and Go. The takeaway is that SREs need to know more than just how to use code to solve IT operations problems. They must also be able to develop applications or contribute code to application platforms (the job description mentions “contributing to code in GitLab” as a required SRE technical skill).

    Also interesting is the fact that GitLab expects site reliability engineers to be able to write blog posts. Blogging may not be one of the first skills that come to mind when you think of a site reliability engineer’s responsibilities, but at GitLab, at least, it’s part of the job.

    LinkedIn’s Job Ad Template

    LinkedIn provides an SRE job ad template that businesses can use when posting their own SRE jobs on the site.

    LinkedIn’s ad is pretty high-level (which is unsurprising, given that it’s a template rather than an ad for a particular job). For the most part, it doesn’t mention specific tools—although the main exception is programming languages, where it says SREs should know how to code in languages like C, Python, JavaScript and Ruby. Like GitLab, then, LinkedIn clearly sees development as a core SRE job responsibility.

    The LinkedIn job description also places a heavy emphasis on the ability to “gather and analyze metrics.” It doesn’t use the word “observability,” but that seems to be what LinkedIn is getting at.

    An SRE Job at Microsoft

    Continuing the theme of development-centric SRE work, a recent job ad for a specific SRE opening at Microsoft reads a lot like a DevOps engineer job description. The ability to “design, write and deliver software” is the top responsibility listed in the ad, which also mentions familiarity with CI/CD tools.

    The Microsoft job description also mentions the importance of written and verbal communication skills. Unlike GitLab’s ad, this one doesn’t say SREs will need to write blog posts; still, it’s clear that companies expect people in this role to be creative communicators in addition to technical experts.

    It’s worth noting, too, that Microsoft wants site reliability engineers who know both Windows and Unix. If you need further proof that Unix skills are absolutely central to SRE work, look no further than this job ad from the company that created Windows.

    Amazon’s Site Reliability Engineer Ad

    Even Amazon—a company that is more of a platform provider than a software vendor—places major emphasis on the ability of SREs to code in one of its recent SRE job ads.

    Interestingly, the Amazon job also highlights networking skills as a major qualification. That’s understandable given the complexity of networking in the AWS cloud. But it’s a bit surprising because most other site reliability engineer job ads don’t call out networking expertise as a key skill—despite the fact that network engineering is critical to SRE work.

    The Amazon job description mentions the importance of an applicant’s willingness to be on-call, too. We suspect that’s critical in virtually any SRE job, but at least Amazon is upfront about the fact that, at time, you’ll be woken up at 4 a.m. to manage incidents.

    Conclusion: Takeaways

    There are a few key takeaways from these various SRE job descriptions.

    • Development skills are absolutely critical in order to be an SRE. Scripting for administration or IT Ops purposes is not enough on its own.
    • The ability to communicate clearly—including both verbally and in writing—is more important to SRE work than you may realize.
    • Network engineering skills, too, are a crucial part of SRE jobs, at least at some companies.
    • In practice, SRE job descriptions sound more similar to DevOps job ads than you might expect.

    This is not to say that all SRE roles are identical or that all companies expect the same things from their SREs, of course. But the jobs ads or templates we’ve surveyed do highlight how the high-level understanding of SRE translates to on-the-ground reality at actual companies.