devopsy.kinsta.cloud

Category: Features

  • Devs Increasingly Rely on IaC to Manage Multiple Clouds

    Devs Increasingly Rely on IaC to Manage Multiple Clouds

    A survey of more than 300 DevOps professionals conducted by Firefly, a provider of a platform for automating cloud provisioning, found that more than a third of organizations (36%) have allocated the equivalent of two or more full-time engineers per month to writing infrastructure-as-code (IaC) templates.

    A full 82% are also deploying the templates within the context of a DevOps pipeline, with 68% reporting more than half of their cloud instances are now managed using IaC tools, according to the survey. A total of 27% reported they are now managing every aspect of IT as code.

    The challenge is that 61% of respondents also admitted they can’t automatically detect configuration drift over time, with more than a third (35%) spending days or weeks remediating IaC templates. Well over half of respondents (56%) said they are also retrofitting existing cloud instances using IaC tools.

    Cindy Blake, vice president of marketing for Firefly, said this issue is likely to become more challenging to address as the number of clouds in use continues to increase. The survey found 44% of respondents already use multiple cloud providers. Overall, 42% reported having more than 10 cloud accounts.

    The top IaC benefits identified by survey respondents are improved efficiency (75%), increased reliability (55%) and easier compliance (52%) and simpler troubleshooting (49%).

    Not surprisingly, the survey identified knowledge (46%) followed closely by complexity (43%) as the top challenges organizations face when using code to manage cloud infrastructure. Factors increasing complexity included cost and complexity (70%), followed by security (61%).

    In addition, only 14% of respondents reported that all their engineers are IaC literate. More than a third (36%) said they only have one IaC-literate engineer. As a result, many organizations are now attempting to navigate IaC bottleneck issues that could be alleviated if they relied more on automation that can be integrated within a continuous integration/continuous delivery (CI/CD) platform, noted Blake. She added that many organizations are already allocating too much engineering time to manually writing IaC templates.

    Those manual efforts often result in misconfigurations that are easily exploited by cybercriminals, added Blake. Many developers using IaC tools such as Terraform have had little to no cybersecurity training, so the odds they will make a mistake are high.

    At a time when more organizations are focused on the productivity of DevOps teams and ensuring the integrity of software supply chains, there is a clear need to automate processes that increasingly span multiple clouds. More organizations than ever are employing multiple clouds to ensure application availability in the wake of a series of outages over the past few years, Blake said.

    Regardless of the motivation, multi-cloud computing is here to stay. Developers opt for different clouds based on the performance capabilities they can provide for various classes of workloads. There may be one cloud platform that runs the bulk of the workloads, but the number of organizations that have standardized on a single cloud are comparatively few. The issue is finding the best way to manage multiple clouds that doesn’t require as much manual effort so organizations can reduce the total cost of managing IT environments.

  • Broadcom Survey Reveals Spike in VSM Adoption

    Broadcom Survey Reveals Spike in VSM Adoption

    Value stream management (VSM) is gaining traction as organizations look to find ways to engage customers more efficiently via digital business transformation initiatives.

    A survey of 500 executives, IT and business leaders conducted by Dimensional Research on behalf of Broadcom published this week found 39% of respondents implemented a VSM platform with another 16% having some equivalent capability. Another 31% said their organizations is moving in the direction of adopting a VSM platform. A total of 60% of respondents indicated that they will be using VSM to deliver products in 2023, with 95% of organizations that have adopted VSM also engaged in digital transformation.

    Laureen Knudsen, chief transformation officer for Broadcom, said the primary goal is to close the divide that has emerged over the years between software development teams and the rest of the business. More than two-thirds of respondents (68%) reported there are disconnects between the business and software development.

    Overall, the Broadcom survey identified increasing customer value (58%), improving product quality (55%), reducing costs (51%), adding more customers (50%, increasing profits (49%) and increasing speed to market (45%) as the top strategic issues organizations face in 2023.

    The top benefits derived from investing in VSM were increased transparency (42%), improved organizational alignment (39%), faster solutions to customers (38%), data-driven decision-making (37%) and improved access to data (36%).

    VSM traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved and organizations realize how dependent they are on software, there is a growing appreciation for the value of monitoring things such as the impact of missed software development deadlines on the business. At their core, VSM platforms aggregate DevOps metrics and then match them to a set of key performance indicators (KPIs) defined by business leaders. Once those metrics are gathered and correlated, organizations can apply advanced analytics. The goal is to apply algorithms and other forms of predictive analytics that will enable organizations to more easily identify the precise impact software development processes have on the business.

    Knudsen said the survey makes it clear a lack of discipline when it comes to software engineering now needs to be addressed as organizations realize how dependent they are on applications to engage customers. Many organizations have, for example, adopted flawed approaches to agile development that wind up creating chaos across the software development life cycle, she noted.

    Many organizations, for example, are unsure how much time development teams are spending on retiring the technical debt accrued within legacy applications versus actually working on developing new applications, Knudsen added.

    Business conditions tend to change rapidly, so aligning software development with corporate goals is difficult. Nearly three-quarters (72%) of respondents said they are frustrated by the state of the business and constant changes to strategy. Digital business transformation initiatives, however, will require organizations to adopt a more structured approach to software engineering, said Knudsen.

    The issue, of course, is the pace at which businesses are already being digitally transformed. The accelerated pace requires almost immediately re-engineering software development processes for them to succeed.

  • Predict 2023: Stand and Deliver

    Predict 2023: Stand and Deliver

    It’s that time of year again—the New Year’s ritual: Time to predict the big trends in your world for the new year. By now you have probably seen dozens of headlines, articles, videos and interviews telling you what big trends will shape the coming year. Here at Techstrong Group, our Predict virtual event is built around this New Year’s ritual. This year, Predict is January 12, 2023 and, not to blow our own horn, but I think it is our best Predict event yet.

    What sets this event apart? Well, we have a real Techstrong Research team now headed up by Mike Rothman and Mitchell Ashley who are leading this year’s Predict event. We will have four tracks: DevOps, cybersecurity, cloud-native and digital transformation. Each track will kick off with either Mitchell or Mike presenting a Techstrong Research trends report for that market.

    After the trends report, there will be a keynote panel featuring some of the top thought leaders in each of these fields. This will be followed by other sessions that explore what this upcoming year has in store. Many of these sessions will be streamed live on January 12, 2023 and allow for audience questions and input.

    But wait—there’s more! One session I am really looking forward to features John Willis and Damon Edwards live at Techstrong Group Studios giving us their personal predictions for 2023. John and Damon need no introduction to the DevOps community. This should be a great session, so don’t miss it. I am also moderating two great panels; one is with C-level executives from CloudBees, JFrog and GitLab and Kohsuke Kawaguchi (KK), the creator of Jenkins and co-CEO of Launchable. The other panel features my friend Emmet Keefe of Insight Ignite who has his finger on the pulse of the digital transformation market.

    The best part? We’ll have a live chat available so you can interact with the speakers and network with your fellow attendees. And you can register and attend Predict 2023 for free. That’s right—this analyst-led, daylong virtual interactive event is free. Don’t wait! Head over right now and register here.

    Another highlight will be the announcement of our DevOps Dozen winners at the event. This year, the DevOps Dozen broke all of our previous records for both nominations and community votes. It has been quite a tough job selecting the winners from such incredible submissions and nominations.

    I haven’t even mentioned the amazing cybersecurity sessions hosted by Mike Rothman or the sessions covering the cloud-native vision with Mitchell Ashley and digital transformation with Mike Vizard. There is just so much great insight you won’t want to miss.

    A big thank you to all of the sponsors, panelists and speakers who help us make this event a true standout. If you want to get a head start on learning about big trends for 2023 and how they’ll impact cloud-native, cybersecurity, DevOps and digital transformation, check out these articles and register for Predict 2023 on January 12, 2023. We hope to see you there! 

     

  • 5 GraphQL Trends to Watch in 2023

    5 GraphQL Trends to Watch in 2023

    The GraphQL query language had a big year in 2022. We witnessed its increase in production use cases, solving overfetching and underfetching concerns that plagued traditional API integrations. GraphQL can significantly improve usability, aggregate multiple services and optimize how data is ported from system to system.

    Yet, GraphQL is also prone to new security concerns. And as attacks on APIs continue to increase and grow in sophistication, an increased security focus will undoubtedly be required to avoid vulnerabilities. The coming year will likely also see architects grappling with their GraphQL maturity as they consider how best to scale its use across an organization and its various stakeholders.

    Below, we’ll consider where the tides are flowing for GraphQL in 2023. These forecasts are informed by my coverage in 2022 and reports from within the web development community.

    1. Increased Production Use

    A full 62.6% of developers reported relying on APIs more in 2022 than they did in 2021, according to RapidAPI’s State of APIs report. As the number of APIs in use expands, we will undoubtedly see more GraphQL examples. GraphQL is popular due to its usability and flexibility which outweighs traditional integration points. Studies showed it is primarily used for exposing internal data, although partner and public use cases are not uncommon.

    Representational state transfer (REST) remains a dominant style for modern APIs. According to Postman’s 2022 State of the API report, 89% of developers use REST. GraphQL is in fourth place at 38%, superseded by webhooks (35%) and SOAP (34%). Although usage remains small in comparison, it’s steadily gaining traction and will continue to expand.

    2. Unifying Disparate APIs

    GraphQL helps expose fields in an easily consumable manner. But it’s also good for aggregating disparate microservices into a unified schema. As such, it is often used as a meta layer that combines multiple REST services, databases and even GraphQL schemas. For the time being, it appears that REST has staying power. And it’s unnecessary to migrate all REST services to GraphQL. Looking to the future, it is more likely to be adopted as a layer on top of existing REST APIs.

    Combining multiple backend services under the hood and exposing them in a unified schema creates a more usable, localized interface that frontend developers can work from. In the future, GraphQL might become a meta layer for more organizations, increasing the discovery of internal services and helping teams reuse internal microservices.

    3. Supergraphs and Subgraphs

    As mentioned above, GraphQL is used not only to combine legacy REST services but also to combine multiple GraphQL schemas. Some call this a graph of graphs—or a supergraph. A supergraph that combines multiple GraphQL schemas would offer unparalleled developer experience in that engineers can access many services from the same endpoint.

    However, there’s a downside to centralizing with a unified graph. Different internal teams or partners might only need access to a particular set of functions. Giving the entire schema to every person who walks through the door would be TMI, not to mention a potential security risk that breaks the rule of least privilege. So, the idea of a subgraph has gained traction. A subgraph is an Apollo concept, but the theory could certainly be applied in other implementations. In the future, we’ll likely witness more use cases that use subgraphs to help federate a supergraph across an organization, helping segment a graph to specific stakeholders’ needs.

    4. Turning on GraphQL Security Controls

    As of 2022, less than half (43.2%) of GraphQL implementations have disabled query introspection. Disabling field suggestions and introspection are means to reduce the risks of public GraphQL exposures. As GraphQL security best practices become more apparent, these numbers will likely become more commonplace. Other security controls, such as implementing query timeouts, query rate limiting and query cost analysis, can also help curb potential malicious behaviors.

    As we’ve covered before, security by obscurity is not enough to protect GraphQL. Yet, many native GraphQL security and performance directives go unused. Besides turning on these advanced features, new tooling is coming to market that could harden GraphQL. Security vendors continue to add support for GraphQL, making its protection more accessible for non-security engineers.

    5. Managing GraphQL at Scale

    GraphQL has arisen in some large production use cases in recent years, helping developer usability at GitHub, boosting productivity at Netflix and aiding Shopify’s API strategy. These case studies proved its usefulness in large enterprises. But how do we effectively scale GraphQL across a massive organization?

    The concepts of supergraphs and subgraphs are ways to help scale it across a company. But retaining high performance will also be vital to maintaining an effective, scalable footprint. As such, we will likely continue to see companies optimize how GraphQL is used as it matures. This includes optimizing queries and query depth and applying filtering and rate limiting to fit application demands. Taking measurements of GraphQL response times will be necessary to establish benchmarks to improve over time.

    We’re Just Querying the Surface

    Above, we’ve only scratched—or queried—the surface of the exciting developments on the horizon for GraphQL in the coming months. There is much more to be said regarding updates to the query language and improvements within the surrounding tooling landscape. Where do you think GraphQL will go in 2023? Let us know in the comments below!

  • Cloudflare Adds Digital Experience Monitoring to CDN Portfolio

    Cloudflare Adds Digital Experience Monitoring to CDN Portfolio

    At an online CIO Week event, Cloudflare today added a digital experience monitoring capability to a portfolio of services layered on top of its core content delivery network (CDN).

    Corey Mahan, director of product management for Cloudflare, said the Cloudflare Digital Experience Monitoring service extends a Cloudflare Zero Trust platform based on agent software dubbed Cloudflare WARP. The solutions delivers a wide range of software-as-a-service (SaaS) offerings spanning everything from data loss prevention (DLP) to email security.

    He added that the overall goal is to reduce the total cost of IT by delivering SaaS application services more efficiently using a single agent rather than having to deploy multiple agents for each service.

    The Cloudflare Digital Experience Monitoring service, available as a private beta, will enable IT teams to leverage the Cloudflare CDN to measure and analyze controlled data flows to public or private resources by emulating traffic flows using synthetic data. Via integration with the Cloudflare Zero Trust platform, IT teams can also access real-time data visualizations highlighting anomalies in connectivity or performance that might, for example, be indicative of a security breach, noted Mahan.

    While there’s no doubt IT organizations are looking to streamline the number of IT vendors they need to manage, it’s not clear what the center of gravity will be for achieving that goal. Cloudflare is making a case for using the same global CDN that many organizations already rely on for networking services.

    The Cloudflare Digital Experience Monitoring service leverages the company’s CDN to make it simpler to understand, for example, why users in one geography experience sub-optimal application experiences compared to another, said Mahan. That’s especially critical when more organizations than ever have employees working from home across multiple geographies, he added.

    In the longer term, more networking and security functions will be consumed as a service. The challenge then becomes integrating those services into the DevOps workflows that are employed to deploy applications across a highly distributed computing environment. In many cases, what might initially appear to be an application performance issue winds up being a network connectivity problem that is more easily solved.

    One way or another, the management of IT services in the months and years ahead will continue to converge. Organizations of all sizes will need to determine whether it makes economic sense to acquire platforms they need to manage versus consuming a service that is managed on their behalf. Most of the time, a service will be easier to consume and free up resources that can be applied to other IT functions, such as application development.

    Of course, organizations will also need to take care to avoid locking themselves into a specific services provider. Ultimately, however, the question is whether managing a specific IT function provides enough differentiated value to be worth the time and effort when there is so much more to do.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    ZipRecruiter

    Daikin
    Chatsworth, California
    Senior Developer Operations Engineer
    $130,000 to $150,000

    LinkedIn

    SciTech
    Boulder, Colorado
    Information Technology Infrastructure Lead
    $123,000 to $165,000

    SimplyHired

    OBMedia
    Remote
    Senior DevOps Engineer
    $120,000 to $170,000

    Indeed.com

    Brighthouse Financial
    Remote
    Principal DevOps Engineer
    $119,000 to $150,000

    Dice.com

    Hexaware Technologies
    Atlanta, Georgia
    DevOps Track Senior Engineer
    $100,000 to $120,000

  • Survey Sheds Light On Cloud, API Expertise Skills Gap

    Survey Sheds Light On Cloud, API Expertise Skills Gap

    Enterprise IT faces a three-pronged onslaught: Digital transformation, open APIs and security threats. First, most organizations are still navigating ongoing digital transformations and cloud migrations. Second, development teams continue to increase their use of open APIs, leading to sprawl concerns. And third, we’ve witnessed a slew of cybersecurity threats that appear to be growing in sophistication. Tech leaders are attempting to govern this influx of new tools and risks, yet it can be challenging to innovate quickly while ensuring that sensitive data is always protected.

    The Axway 2022 Open Everything Survey shed light on some of the above challenges and attitudes of those invested in API development and API-enabled managed file transfer (MFT). Most notably, the survey found that 86% of respondents feared an expertise gap in the coming years, in which their organization won’t have the skilled software and IT infrastructure talent they needed to innovate. Below, we’ll review other findings from the survey, focusing on the responses from those who indicated they’re invested in API development.

    Cloud Migrations Are Still Underway

    Digital transformations are still underway in the vast majority of organizations. Only 12% reported being wholly digital and leading innovation. The rest were either just beginning transformations, were midway through or were still largely brick-and-mortar. More than one-third (38%) also said their company’s digital makeup is a hybrid of old and new technology.

    The most-adopted computing environment is the public AWS cloud, at 47%. Yet other options trailed close behind, including hybrid (37%), managed cloud services (32%), Azure (28%), private (25%) and Google Cloud Platform (18%). Other reports substantiated how modern IT is becoming increasingly hybrid and multi-cloud. As digital journeys continue to shift and evolve, some organizations are embracing multiple fit-for-purpose clouds.

    Although multi-cloud offers unparalleled flexibility, the primary drawback is security. Just over half (55%) of respondents said that tracking and controlling the flow of personal data into and through the cloud is a key hurdle to a multi-cloud strategy. And 53% reported that dealing with different security requirements for regional instances of cloud infrastructure was a top challenge. This concern is warranted, as companies doing business internationally must carefully navigate many specific regional data regulations.

    Open Data Strategies Abound

    As the Open Everything name indicates, many different sectors are becoming more “open.” The report highlighted the adoption habits of APIs within supply chains, where they are most often used to configure applications, operate and monitor applications and integrate internal data sources. Popular use cases here included payment and tracking systems. APIs also have a significant role to play in the financial world—41% of those working in finance said open banking is an opportunity to discover new business models. But nowhere is the need for more open data more crucial than in health care, which was found to be the area most in need of digital transformation.

    We’d like to think of the API revolution as being driven by API-first startups and SaaS services. While these trends get attention, it’s not the most common use case for APIs. In fact, 44% of the time APIs are used to support IT consulting and system integration requirements. This is followed by providing cloud applications for customers (35%), developing a partner network (35%) and offering cloud services for customers or partners (34%). Although there are certainly business use cases for generating revenue through APIs, they are most often adopted to supplement existing platforms or to glue together internal services and data.

    Most Technology Leaders Fear API Sprawl

    Security is an encompassing concern for all walks of IT, but is especially top-of-mind when opening up data. Respondents said security is the most important concern when creating APIs (30%). This concern is warranted, as attacks on APIs have increased exponentially in recent years. Other top concerns are API adoption or consumption (15%), customer experience (14%), ease of API management (14%) and design and development (11%).

    As APIs and microservices become more abundant within an organization, it’s easier for sprawl to set in. Unbridled technology sprawl can have a deteriorating effect on design standards and lead to unknown shadow APIs that may pose a security vulnerability. As a result, over two-thirds of respondents said the prospect of API sprawl worries them.

    To mitigate sprawl and address other concerns, most companies are investing in tools to help manage the growing number of APIs. The majority (83%) said their budget for API management has either increased or stayed the same over the last two years. For 18%, this budget has risen by over 25%. Operationalizing API life cycle management capabilities can have benefits such as standardizing design style and increasing the discoverability of internal services.

    API Security Must Still Mature

    In a perfect world, we could share data without fear of misuse. But in reality, APIs are a common target for hackers. Publicly exposed endpoints with broken access control or missing object-level authorization can be easily abused for things like privilege escalation and data exfiltration. And although these risks persist, many APIs don’t adopt industry best practices regarding API security.

    Although most APIs use authentication and token schemes, under half (43%) implemented OAuth. Furthermore, only 30% implemented policies with an API gateway. OAuth 2.0 and gateways have become best practices in serving APIs, as there are too many vulnerabilities to rely solely on HTTP Basic Authentication and API keys. As such, we will likely see these adoption rates increase as API security matures.

    As with other cybersecurity endeavors, it’s really about taking a holistic perspective and applying defense-in-depth. Thankfully, most technology professionals understand this point—developing a more holistic approach to security was ranked as the top strategy for protecting personal data. Other strategies, like data encryption, advanced multifactor authentication, data loss prevention tools and highly-secured data transactions will also be necessary to protect cloud-native assets.

    Final Thoughts

    The Axway 2022 Open Everything Survey asked 1,000 IT leaders, architects and developers about their top concerns. Above, we focused on results from technology leaders engrossed in cloud and API development. For more insights and the findings from those using managed file transfer (MFT), readers can pick up a copy behind an email gate here.

  • Southwest Airlines: ‘Shameful’ Technical Debt Bites Back

    Southwest Airlines: ‘Shameful’ Technical Debt Bites Back

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    20 Years of Neglect Led to ‘Meltdown’

    Last month’s débâcle of canceled flights was caused by decades of technical debt. That’s the analysis of Columbia University professor Zeynep Tufekci. (more…)

  • Intel Expands Scope of oneAPI Initiative

    Intel Expands Scope of oneAPI Initiative

    Intel has expanded its effort to drive adoption of a set of open compilers, libraries, analysis and porting tools and frameworks for artificial intelligence (AI) applications, collectively made available via a oneAPI initiative, to include support for its latest generation of processors.

    The oneAPI initiative was launched more than three years ago to create a set of multi-architecture tools for building applications that could be deployed on any CPUs, graphical processor units (GPUs) and field programmable gate arrays (FPGAs). Processors that now support oneAPI include forthcoming 4th Gen Intel Xeon Scalable processors, Intel Xeon CPU Max Series and Intel Data Center GPUs.

    James Reinders, chief evangelist of Intel Software Products, said there is now a clear need for open tools and frameworks that provide equal access to multiple classes of processors. As part of that effort, the latest 2023 version of oneAPI, for example, adds support for plug-ins for Nvidia and AMD GPUs developed by Codeplay, a unit of Intel, to simplify writing SYCL code in a way that makes code portable across additional processor architectures.

    There is also a CUDA-to-SYCL code migration capability that supports more than 100 CUDA application programming interfaces (APIs) using the Intel DPC++ Compatibility Tool based on an open source SYCLomatic project. Intel is also providing tools to identify imbalances at scale using Intel VTune Profiler, and an Intel Advisor tool now provides automated roofline analysis for Intel Data Center GPU Max Series to identify root causes of memory, cache or compute bottlenecks along with insights for optimizing data transfer costs involving CPU-to-GPU offloading.

    As IT continues to evolve, it will become more routine for developers to invoke heterogeneous classes of processors within the same application, but it’s been challenging to convince providers of other types of processors to support the oneAPI initiative, noted Reinders. Processor providers have historically relied on compilers and libraries to lock developers into specific classes of processors.

    However, it’s becoming more common for developers to build applications that invoke multiple types of processors. The Intel oneAPI initiative is intended to simplify access to heterogeneous processors, also known as XPUs. That’s critical, because the pace of processor innovation has accelerated to the point where developers need to be able to invoke additional capabilities without waiting for specific compilers and libraries to be updated by multiple providers. Once oneAPI is more widely adopted, it then becomes possible to significantly lower the cost of application development and deployment, noted Reinders.

    It’s not clear whether the oneAPI initiative will become more widely adopted, either under the auspices of Intel or by some type of industry consortium that provides a neutral venue for building a common set of compilers and libraries. The one thing that is certain is that DevOps teams are vested in trying to standardize compilers and libraries across as many platforms as possible. The challenge, of course, is making sure developers only invoke compilers and libraries that can span multiple classes of processors versus ones that may have been optimized for a specific type of processor architecture.

  • Why SREs Are Critical to DevOps

    Why SREs Are Critical to DevOps

    Although a relatively new concept, site reliability engineers (SREs) have become crucial for DevOps teams, helping to solve an array of operational problems such as network availability and user experience. However, in previous years, some people have questioned the longevity of such a role. 

    This article will discuss several reasons why site reliability engineering roles are here to stay and why they have become critical to DevOps. 

    What Are Site Reliability Engineers (SREs)?

    A site reliability engineer helps connect development teams and IT operations by completing tasks previously assigned to operational roles. SREs use a range of automation tools for troubleshooting purposes, creating software systems that are both scalable and reliable.

    The role revolves around automation and standardization, as cloud systems become increasingly prevalent. SREs also play a vital role in ensuring the user experience of systems is of the highest standard.

    Why Site Reliability Engineering Roles Are Here to Stay

    Let’s take a look at two of the primary reasons SRE roles are here to stay. 

    User Expectations

    The key reason for the rise in popularity and the expected longevity of site reliability engineering roles is user experience. In the modern climate, user expectations are very high and more dedicated roles are required to help deliver a service that is not only acceptable but attempts to exceed user expectations.

    Even back in the 2010s, users were much more patient in terms of website load speeds and how quickly they could access information. Even crashes and load failures were tolerated without the user exiting a website.

    However, that has all changed due to the competitiveness of the market, as well as the growth of remote working, which has increased dependency on online resources. This means that if a service is unavailable for any period, users are unable to do their job. 

    An SRE’s role includes optimizing systems, ensuring they perform at the required level and that resources are always available to those that need them. This makes SREs critical to DevOps teams that may not have the capacity to focus on meeting user expectations sufficiently. 

    The Complexity of Software Architectures

    Another factor that has added a lot of value to the role of an SRE is their ability to provide much-needed support for software environments and architectures that continue to develop in terms of complexity. Kubernetes is one such architecture that requires dedicated attention. 

    Applications that are distributed across systems such as Kubernetes and other cloud-native platforms require specialized personnel that have the necessary knowledge and experience. Machine learning is also becoming more prevalent and requires special focus from a performance perspective. In 2020, just more than 22% of companies had machine learning models in production for one to two years.

    This level of complexity is only expected to grow further over the coming years as cloud-native systems become the norm. This is why new roles must be created that go beyond that of a normal IT engineer. 

    Challenges for SRE Roles

    Like any IT role, the role of a site reliability engineer always faces challenges that have led people to question whether SREs are a long-term solution or whether it is a niche specialization. 

    A Lack Of Opportunity Away From Hyperscale Companies

    The role of an SRE was created by hyperscale companies like Google that manage extremely large IT systems. For companies that do not have such a wide and varied IT infrastructure on a global scale, there are questions about whether such a role is necessary. 

    However, as previously mentioned, the growth of cloud-native technology shows no sign of slowing and, with this growth, opportunities for SREs at smaller organizations may arise. 

    The Role of an SRE is Considered Obscure

    The ambiguity of an SRE role can be considered a downfall in some cases, with many businesses unsure of what these professionals offer when compared to a traditional systems engineer. In many cases, SREs are deemed to be a hybrid of a software engineer and an IT operations role. 

    Fortunately, DevOps has realized the potential of SREs and their ability to provide an important bridge between developers and engineers, helping to achieve dedicated tasks to a high standard. 

    SREs Vs. DevOps

    Although both roles are connected and share some similarities, there are some clear differences.

    • Processes – DevOps has full visibility into the development environment which allows them to make changes from the initial development stages through to production. SREs, on the other hand, only have visibility into the production process, allowing them to make suggestions to ensure performance levels are maintained.
    • Implementation – The task of implementing new features on a system falls on the DevOps team. Meanwhile, SREs are tasked with ensuring the new features do not cause any system failures or impact performance during the production stage.
    • Key Focus – The primary focus of a site reliability engineer is to ensure the system’s reliability, availability and scalability. DevOps focuses on how quickly product development is completed, as well as its continuity.
    • Structure – The structure of an SRE team and a DevOps team have obvious differences. SRE teams are made up of individuals who have similar skill sets relating to development and operations. Whereas DevOps teams consist of professionals who have specific roles related to individual aspects of the project. These roles can include the team leader, product owner, cloud architect, software developer, QA engineer, system administrator, release manager and more.
    • Tools – DevOps teams often use tools such as integrated development environments (IDEs) when developing a product. These can include Jenkins (continuous integration and continuous development), JIRA (change management), Splunk (log monitoring) and GitHub (distributed version control). SREs commonly use tools such as Prometheus and Grafana (collection and visualization of metrics, such as CPU usage and available disk space), OP5 and PagerDuty (incident alerts), Ansible and Kubernetes (container orchestration) as well as a range of cloud platforms.
    • Bug Reporting – DevOps debug code whenever a bug is reported in the end product. SREs are not involved with debugging from a development perspective and are only required to perform such tasks if there is a production outage, there are infrastructure issues or perhaps if they are dealing with common AWS misconfigurations.
    • Measuring Performance – The typical metrics that DevOps uses to measure performance are deployment frequency and deployment failure rate. SREs measure service level objectives (SLOs), service level indicators (SLIs), service level agreements (SLAs) and error budgets.
    • Incident Handling – In the case of incident handling, DevOps teams work to mitigate an issue based on the feedback provided. SREs then analyze the issues post-incident, including the root cause of the issue. This is then documented and provided to the developers to fix. 

    Why SRE Roles Are Critical to DevOps – Conclusion

    As you can see, the two roles differ significantly but SREs can play a critical role in ensuring the DevOps team delivers a product that offers maximum performance. 

    The core benefits of employing professionals in a site reliability engineer capacity are high levels of product performance and reliability to meet user expectations while helping to manage complex IT architecture. 

    In the future, organizations that manage a large amount of cloud-based IT assets may struggle to deliver efficient products without such professionals. As such, demand for SRE roles is likely to grow.