devopsy.kinsta.cloud

Category: DevOps Practice

  • Why GraphQL Will Reign King

    Why GraphQL Will Reign King

    After years of development, GraphQL is set to reign as the go-to API for data fetching. But what is GraphQL? Simply put, it’s a query language that allows you to fetch data from any server, and it’s a noteworthy alternative to the likes of other web service development styles like representational state transfer (REST) and simple object access protocol (SOAP). There are a few reasons why GraphQL will dominate the DevOps world, including its overall efficiency, ability to work with any server and overall ease of use.

    Understanding GraphQL

    GraphQL is a query language for APIs and a runtime for fulfilling queries with existing data. GraphQL provides a complete and digestible description of the data in an API, gives clients the power to ask for exactly what they need, makes it easier to evolve APIs over time and enables powerful developer tools.

    Top Benefits of GraphQL

    GraphQL addresses many pain points that often slow down developers, who prioritize adaptability and working quickly and efficiently when building applications.

    For one, it is much more flexible than other data query languages, allowing users to specify exactly what data they want and in which format. Other data query languages require users to retrieve all data in a specific format, regardless of whether they actually need the data. That excess, unnecessary intake can cause delays and confusion.

    GraphQL’s ease of use is also invaluable, thanks to its simple and intuitive syntax. The language is strongly typed, which means developers can catch errors early on in the development process before code goes into production. This can save much-needed time and money in the long run.

    Another benefit is that it can be used to fetch data from multiple sources because it uses a schema that defines the different types of data available. This means if a developer has a field in a schema that could potentially return data from multiple sources, they can specify which source to fetch the data from. Developers don’t get this benefit from other data query languages, which often allow data fetching from only a single source.

    Advantages for DevOps Teams Over Other Data Query Languages

    As the world of software development continues maturing, so do the tools and technologies DevOps teams use to build and operate their applications.

    REST and SOAP are popular web service technologies, but they come with some major drawbacks. Notably, both REST and SOAP rely heavily on URL structures and verbose XML payloads, which makes it difficult to evolve the API without breaking existing clients. And because each endpoint is a unique URL, providing a consistent experience across different parts of the API can be challenging. REST and SOAP are also quite chatty and can make it hard to optimize performance.

    In contrast to REST, GraphQL provides a single endpoint for all data requests and is much faster than making many HTTP requests. GraphQL’s declarative query language specifies precisely the data needed – no more, no less – increasing bandwidth and improving performance. Applications can run faster and use fewer resources, which is especially important for mobile apps that need to be lightweight and fast.

    Understanding the data is crucial for DevOps teams, and GraphQL allows developers to visualize data in a graph. Teams can see the relationships between different points more easily, leading to better-informed decisions about the best ways to manipulate the data.

    The increased efficiency when conducting API calls is also a plus with GraphQL, which helps teams retrieve all information they need with a single API call. Traditional REST APIs often require multiple API calls, mainly because each resource in a REST API is represented by its own unique URL, along with its own set of permissions and data that needs to be retrieved. GraphQL can eliminate this bottleneck.

    Overall, dealing with complexity is significantly reduced when developers use GraphQL. When using traditional REST APIs, writing a lot of code to handle different edge cases and error conditions is the norm. But GraphQL streamlines this – much of the complexity can be handled by the server itself, making way for simpler and more maintainable codebases. DevOps teams are also able to decouple their front-end and back-end development efforts by using a schema-based approach. GraphQL enables frontend and backend components to be developed separately without worrying about breaking changes, which means faster development cycles and fewer errors.

    The amount of data that organizations need to understand, organize and query will only increase in the coming years. DevOps teams can get ahead of the ongoing data and information onslaught by taking advantage of GraphQL and its unmatched ability to provide an efficient, powerful and flexible API for data fetching and manipulation.

  • 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!

  • No-Code Automated Software Solves a Host of Problems

    No-Code Automated Software Solves a Host of Problems

    There’s a huge disconnect in corporate America, and it’s costing companies big time. The disconnect involves software testing, or, more precisely, the lack of it. More than nine out of 10 CEOs are confident that their company’s software is tested regularly, yet roughly eight out of 10 product testers reported that up to 40% of their software goes out the door with insufficient testing. This dichotomy came to light in the latest Leapwork survey of 500 CEOs and software testers.

    The consequences of untested software are potentially dire and far from hypothetical. Flawed software that delayed the launch of new car models contributed to the dismissal of Volkswagen CEO Herbert Diess, while Facebook saw its market cap value plummet by billions in 2021 when a software glitch came to light. 

    It’s not as if anyone is unaware of such risks: A whopping 95% of CEOs surveyed admitted they’re concerned about losing their jobs if a software failure occurs, while 76% of testers shared that concern. Those feelings are certainly valid, as more than three out of four CEOs reported that software failures damaged their companies’ reputations during the past five years.  

    Despite these realizations, CEOs seem willing to gamble. A full 85% said they considered it acceptable to release software that wasn’t adequately tested, as long as it can be patched later. That attitude has made patching standard operating procedure. More than half the testers said their teams spend five to 10 days a year patching software. 

    Why are organizations willing to take unnecessary risks by releasing software that’s potentially not ready for prime time? There are several common reasons—and a solution that many are overlooking. 

    The Problem with Manual Testing

    One of the major problems is the continued reliance on manual testing, which requires time and resources companies can’t afford. Only 43% of testers said they use automation to some extent in their testing, proving that the majority of testing is still a manual process.  

    That significantly slows product development, an issue for businesses anxious to get their products to market before the competition. Nearly 40% of CEOs said the time-consuming nature of manual testing is one of the primary reasons they release programs that haven’t been properly vetted. Testers clearly feel the crunch, with about one in three saying faster development cycles don’t allow enough time for testing. 

    Given the choice between rushing through testing or delaying a release, companies often roll the dice and opt for the former.  

    Two recent pandemic-related trends have made the situation even more difficult. More organizations are embracing digital platforms to cope with the effects of COVID-19 on their businesses, increasing the need for IT talent. At the same time, upheaval in the labor market has resulted in widespread resignations and job hopping, contributing to a serious shortage of skilled IT personnel. 

    The Coding Conundrum

    Even in this chaotic business climate, experienced software developers remain a hot commodity, with many career options at their fingertips. The competition for talent has left many IT teams scrambling and understaffed, making it difficult to produce high-quality software at a breakneck pace.  

    Eliminating the need for manual testing could relieve the pressure to a great extent. By automating testing, organizations can reduce the burden on staff and minimize the risk of errors caused by deadline pressures. That would allow more testing of more software in less time, which would help move product out the door and into the hands of customers. 

    But automated testing isn’t without its challenges, as many organizations have discovered. Many solutions that are billed as “low code” still demand coding skills beyond the capability of typical business users and testers. That need for coding is an obstacle that can drag down the pace of testing and make it difficult for business users to participate in the process.    

    That challenge grows as the need for ongoing maintenance expands. The test engineers who came on board to set up an automation solution can find themselves bogged down in maintaining code. As a result, speed to market continues to suffer. 

    Democratizing the Test Process

    There is a solution: true no-code test platforms. This type of solution allows both testers and business users to design, run and maintain tests without the need for coding. Business users who understand how the software deliverables are supposed to grow business can be intimately involved in testing, which enhances the quality and functionality of the product and the satisfaction of customers. 

    It also promotes speed. When testing is largely automated and more people are involved, it’s possible to test more software in less time. This eliminates bottlenecks and addresses the issue of scale. The use of automation on a no-code platform has been shown to speed time to market by a factor of 10—an improvement that largely eliminates the need to rush potentially flawed software to market without adequate testing.   

    Organizations can position themselves to meet the growing demand for digital solutions by revamping the way they test software. By eliminating manual testing and adopting an automated platform that doesn’t require coding skills, they can afford to test all their products thoroughly. The end result: They can minimize the risk of bugs that could undermine their success and threaten job security.  

  • The Time for Automated Testing is Now

    The Time for Automated Testing is Now

    Skilled software testers continue to be in high demand, and it appears that trend won’t change any time soon. The current labor shortage and a looming recession is giving software development leaders good cause to think about how to attract and keep qualified personnel and, more importantly, enable them to work as efficiently as possible. Added to this scenario is a trend in the software development cycle toward shift left testing, which has put increased pressure on developers to take on testing responsibilities that often require taking on new perspectives and using new tools. Automated testing solves these problems by making it easier to learn how to build a consistent, reliable testing program in less time, requiring less maintenance.

    Add to this the future promise of artificial intelligence or AI-augmented testing platforms and current machine learning (ML) capabilities, such as self-repairing of test scripts, and you have a platform that both levels the learning curve and accelerates efficiency. The sooner organizations can transition from manual to automated testing, the better they can withstand internal and external market fluctuations.

    A Developer and a Tester Walk Into a Bar …

    Traditional software testing is a manual process in which testers are employed to replicate users and are expected to bring that perspective to their work. As such, software testers have a very different mindset than software developers. Where developers are protective of their creative output, software testers are driven by a curiosity to probe the limitations of a system. It stands to reason that the qualities that make someone excel at either of these roles is, likewise, not the same. And yet, with the trend toward shift left testing and continuous integration/continuous development (CI/CD), the industry has blurred the distinction between coder and tester to the dismay of both sides.

    Automated testing removes much of the monotonous work associated with repetitious test plans. It allows testers to focus on writing better scripts, extending the scope of their testing plans and scheduling more powerful load tests. From the organization’s perspective, once you have established a library of reusable test scripts, your testing program will be protected from future turbulence in the employment market, including recession and attrition.

    Low-Code/No-Code

    Regardless of the tool you use, code will be created if you are creating software — even test scripts. Ideally, however, a low-code/no-code tool can hide some of the complexity and promote best practices. Using a low-code/no-code tool can relieve a tester from creating test scripts from scratch by recording manual interactions and offering suggestions. In the case of shift left testing, a low-code tool can eliminate the need to learn entire testing frameworks while still enabling a developer to access code when desired. Automating testing also eliminates the human error inherent in repetitive manual tests. In short, test automation does not diminish the value of skilled software testers and developers; it increases it.

    Placed in the hands of skilled testers, automated testing will only become more powerful, more effective and more critical to your development cycle. It elevates the skills of testers and makes them more productive, accurate and thorough. Test automation also makes for a smoother transition to shift left testing, allowing developers to spend less time testing their software and more time doing the creative work that makes them thrive. In a market where attracting and keeping top talent is only going to get more difficult, anything you can do to lighten the burden on your employees and make them more productive will be a big win for your business. So, the question is not whether you should transition from manual to automated testing but when.

  • 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

  • How DevOps Helps Banks Optimize Their Services

    How DevOps Helps Banks Optimize Their Services

    A world-renowned bank’s CEO was recently quoted as saying that while there are thousands of manual banks now, the future will see only a handful of digital banks. Along with the rest of the world’s critical business sectors, an overwhelming number of banks are also shifting to virtual platforms. This migration is being orchestrated by some of the best DevOps resources that the global FinTech sector has to offer.

    The convenience of personalized services that are always on-demand has incentivized the banking sector’s reliance on DevOps workflows. When the COVID-19 pandemic struck and limited physical banking services, the migration of enterprise banking systems onto the cloud had been in full swing. Most bank employees had to shift to a work-from-home setup, accelerating the use of virtual service delivery.

    As per an estimate by the IBM Institute for Business Value, about 59% of the companies surveyed are in various phases of their digital migration and the banking sector is naturally following suit. DevOps teams are tasked with writing software extensions for connecting digital banking services to the end customer in an agile manner.

    This article explores why DevOps is slowly becoming an essential foundation for any successful banking institution. We will also discuss how traditional institutions cope with these changes and what benefits they can look forward to once they make the leap to DevOps.

    Agile Processes Facilitate Digital Transformation

    Most banks these days have been adopting agile processes to stay ahead of the competitive curve. The main motive behind this is to keep up with frequent business requirements that come with efforts to improve clients’ banking experiences. Fine-tuning the project planning and execution processes that drive this improvement are what the DevOps teams would be mainly doing.

    Under the Agile methodology, banking applications would be created in small, controllable steps known as sprints. Each step is tested meticulously before it can be considered executable or complete. Before continuing to build on the delivered component, proper channels are followed for real-time feedback and course correction. The end goal is that the customer must get a product that is of value in a much shorter timeframe than is possible through any other development process.

    More than even the process and the rules governing it, the DevOps teams involved and their collaboration is a top priority as well as the eventual outcomes. Agile projects behind the most optimal banking services and products must involve continuous planning, testing and integration of finished components.

    Faster Success for DevOps Teams in Banking

    To successfully drive new digital banking services, large banks need billions in assets and need to gain millions of new customers along the way. It all boils down to shifting their processes to a more granular process and continuously improving upon it.

    In situations like these where DevOps practices need to be adopted proactively, the client’s line of business (LOB) teams move to Agile planning strategies fairly quickly. They use a variety of tools to implement Agile and DevOps practices to tackle growing customer demands for their improved digital banking services.

    But for this to work seamlessly, the developer experience for both the LOB and IT teams needs to be streamlined. The LOB and IT teams’ efforts can be integrated if the DevOps platform is automated with built-in Agile capabilities and bi-directional integration. This ensures seamless collaboration, faster DevOps implementation and the speedy delivery of banking services and products.

    Focused Insights and Better Predictability

    Large banks can standardize the internal IT development team on an engineering life cycle management platform, simultaneously providing support to the LOB team via the Agile issue tracking dashboard. Agile life cycle management tools extend an integrated solution for banks. Using these tools, the DevOps teams can be provided with full transparency and traceability of developer data.

    Developer-specific capabilities such as source code management, build automation, continuous integration and delivery and Agile planning are more accessible this way. The IT developer community considers Agile workflow management platforms as the benchmark for efficient and continuous business flow. Workflow management platforms and issue tracking portals are the places where most of the Agile planning takes place.

    Agile life cycle integration adaptors then link the LOB-defined Agile stories with specific developer tasks in easy-to-manage packets. The developer changes to the application code are tracked within the workforce management tool to draw useful and quantifiable insights from the data. The speed of application delivery is accelerated further because of the connections established between the projects, teams and tools.

    Minimizing Service Delivery Mishaps

    Using workflow management tools, the team can provide continuous build and integration functionalities. They can deploy automated integration builds on dedicated cloud or on-premises environments which minimizes errors in service delivery. A software bill of materials (SBOM) is generated for each build in the final audit trail which lets developers resolve errors retroactively as well.

    A broad picture is created of which new tasks and pieces of code went into the build and what software assets were created. DevOps implementation ensures continuous delivery of the banking application across test and production environments. Errors are reduced throughout the production life cycles of each banking service or product. This reduces the time taken from development to production. A fully automated and auditable delivery pipeline is created to make future deployments even faster.

    Reduce Banking Product Release Cycles

    DevOps provides a very robust and reiterable foundational environment for the bank’s business to thrive while reducing release cycle time with every iteration. This means every time a new banking service is delivered, the development life cycle is improved bit by bit. In some cases, the release cycle can be reduced by more than half the original time taken.

    While service delivery is improved, this also frees up release engineers for urgent tasks crucial to the deployment window. More deployments occur while still keeping the bank or financial institution in accordance with regulatory guidelines.

  • 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. 

  • DevOps Must Embrace Automation in 2023

    DevOps Must Embrace Automation in 2023

    A survey of 500 engineering and software development professionals in the U.S. suggests more DevOps teams than ever need to resolve to embrace automation at a deeper level in the new year.

    The survey, sponsored by Chronosphere, a provider of an observability platform, found engineers spend, on average, more than 10 hours per week attempting to triage and understand incidents. That equates to a quarter of a 40-hour workweek.

    Overall, 96% of respondents said they spend most of their time resolving low-level issues, with 88% reporting that amount of time negatively impacts them and their careers because so much time is spent troubleshooting IT issues.

    Over a third (33%) said those issues disrupted their personal life with 39% of respondents admitting they are frequently stressed out. Just under a quarter (22%) said they want to quit.

    Chronosphere CEO Martin Mao said much of the stress DevOps teams encounter results from reliance on DevOps platforms that organizations built themselves. Platforms built and supported by a vendor today typically provide higher levels of automation that reduce overall stress levels, he added.

    The survey found that 40% of respondents frequently get alerts from their observability solution without enough context to triage the incident. A total of 59% said half of the incident alerts they receive from their current observability solution aren’t actually helpful or usable, with 49% reporting they struggled with inconsistent performance using their current approach to observability. Nearly half (45%) said their current observability solution requires a lot of manual time and labor.

    Overall, 42% of those using a vendor solution said they experienced high-severity incidents quarterly or more compared to 61% relying on a platform they built. Among organizations not using a vendor solution, the majority said they would consider doing so to enhance team productivity (61%) or improve reliability (54%).

    Stress levels are likely to increase as organizations deploy emerging cloud-native applications. A full 87% of respondents said cloud-native architectures had increased the complexity of discovering and troubleshooting incidents.

    During challenging economic times, it’s more critical for DevOps leaders to understand the total cost of building and maintaining platforms, said Mao. Many organizations decided to build their own platform at a time when there was no other viable option. The manual processes required to support those platforms result in a higher cost of labor that impedes the ability to scale workflows cost-effectively, he noted.

    It’s not clear how big an appetite for change any organization that has built their own DevOps platforms may have in 2023. The challenge is that the initial cost of swapping in a commercial platform may appear high given the fact that the legacy platform is already deployed. However, the cost of the acquisition of a new platform needs to be weighed against the total cost of ongoing operations. A lot of soft costs show up in, for example, higher turnover rates for DevOps professionals that are likely to find a more rewarding job elsewhere that is less tedious. One way or another, at the start of 2023, it’s apparent there are more hard DevOps questions than ever that need to be asked and answered.