devopsy.kinsta.cloud

Category: Doin’ DevOps

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.

January 10, 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!

January 10, 2023
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

January 9, 2023
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.

January 6, 2023
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…)

January 5, 2023
How Embedded Analytics Can Transform Future Businesses

It’s no secret that big tech companies like Google, Amazon and Netflix are not only leveraging data but also delivering embedded analytics and insights as a standard functionality of their software, services, applications and toolkits. The analytics appear to consumers as recommendations, usage habits and other helpful information. Such insights not only help consumers extract the most value out of the product they are using but also help providers understand how they can provide better services. Businesses that embed analytics to provide a differentiated user experience also have a direct impact on engagement and revenue.

Have you considered how embedded analytics could differentiate your company’s own software and hardware products? Let’s understand how embedded analytics can help transform technology businesses:

1. Analytics are expected and welcomed in your products

By embedding analytics into existing enterprise software and applications, users can drill down into real-time and context-aware data (for example: How busy a location will be at various times of the day) and can benefit from faster data-driven decision-making without worrying about application compatibility. Commonly, software applications provide in-app analytics to delight and serve their customers, while hardware companies can provide helpful stats on a web portal or app.

2. Embedded analytics is easier than ever today

Cloud technology has completely disrupted tech-enabled industries. It’s easier than ever for software, apps and hardware to connect to a data repository to save logs that are a rich source of analytics. The invention of the S3 bucket and object store has made it fairly cheap to keep log data. Finally, the transition to platform-as-a-service (PaaS) and software-as-a-service (SaaS) has fundamentally added an “easy button” to tracking consumption patterns and resource utilization.

3. Embedded analytics helps design better products and services

Embedded analytics can give businesses more insight into application telemetry (how customers use the data, how they engage with the product) and provide insights into the challenges they face from a usability standpoint. Providers can use advanced analytics to quickly iterate, draw patterns and make predictions, troubleshoot customer challenges, discover new avenues to monetize, detect and mitigate security threats or create entirely new features and applications that put customers on a faster path to improved application experience and better decision-making.

4. Embedded analytics increases operational efficiencies

The tech industry is transitioning from traditional monolithic architectures where applications are self-contained to microservices architectures where different components are spun up as needed via API calls. By embedding analytics directly into developer tools, businesses can manage resources without sacrificing availability or performance. Companies can allocate and optimize resources dynamically and understand peaks and valleys in consumption. Businesses must be able to leverage historical and real-time data to build predictive models to proactively identify and mitigate issues with individual components of the application before the customer experiences a problem.

Embedding Analytics in Your Application

Before you start embedding analytics in your application, it’s important to choose the right database foundation, as this will support current needs and future goals. Below are the top capabilities that should be standard features in analytics databases:

1. Handles massive data volumes: The database must scale easily and efficiently with minimal cost using massive parallel processing. Today’s scale might be terabytes, tomorrow it might be petabytes and so on.

2. Enables speedy data analytics: Speed is a key factor in a positive user experience. Users want instant insights because they don’t like waiting for results. The database should be capable of optimizing load and query performance so that analytics is both timely and relevant.

3. Embeds machine learning: Machine learning algorithms are critical for predictive analytics. A platform that can embed ML and iteratively learn from new data can make a big difference and add a whole new level of intelligence.

4. Features native integrations: The more time developers spend figuring out tools and integrations, the less time is spent innovating. The platform must ideally have out-of-the-box integrations with popular applications, data sources (on-premises, cloud, multi-cloud or hybrid), ETL, and visualization tools (e.g., Microstrategy, Looker, Power BI, Qlik, Tableau). It should be flexible enough to support user-defined functions for things that don’t have native integration.

5. Encourages self-service: The database should make it easy for data scientists to leverage tools and programming languages they already know such as R, Java, C/C++, Python and SQL. Data scientists will also appreciate a platform that has built-in functions for a wide range of analytics (such as geospatial, time-series, event-series, real-time, machine learning, text analytics, pattern matching and regression) and delivers the tools to spot trends, uncover anomalies and anticipate the unexpected.

6. Supports highly advanced analytics: Many platforms can analyze single tables or do a simple look-up but few have the power to analyze dozens of tables, hundreds of data types, dimensions and attributes from numerous sources over several years of history.

7. Unified: The database should be able to streamline everything right from data ingestion to exploration to production until delivery. Users should be able to analyze data in its place to always have a single source of truth.

It’s not hard to visualize that the most disruptive companies of the future will be the ones that harness data as a core asset and embed analytics in their products and services. Embedding analytics requires the right database foundation; to get to the right foundation, IT teams need to cut through the noise and study the fine print. With the proper database, the future is yours to create.

January 4, 2023
Best of 2022: The Great DevOps Burnout

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

DevOps needs a mindset shift to save the overworked engineering collective. There’s a considerable discussion right now about the Great Resignation. But if you work in software engineering, you’re probably even more familiar with the Great Burnout.

Everything in the software development realm has sped up over the last few years. Engineers perform at a rapid-fire pace, with perfect accuracy, all day, every day. The demand for new, updated or better apps never slows down. But your DevOps team can only perform so fast.

DevOps is Overworked and Burned Out. No, Really.

A full 83% of software developers feel burnout from their work, while 81% reported an increase in burnout due to the pandemic. The most significant factors contributing to those feelings of burnout include high workload, inefficient processes and poorly-defined project goals and targets.

Overworking, overloading and burning out developers is a recipe for disaster; that’s resulted in job hopping and low productivity. Organizations need to shift their mindset about how we develop apps and nurture developers to make the future of software development sustainable.

The Burden of Uneven Engineering Demands on Your Bottom Line

Software delivery is only as sustainable as the level of workforce happiness. Today, the supply and demand for engineers is entirely lopsided and the chasm between the two continues to widen.

The highest number of SaaS companies worldwide exist in the United States. The vast majority (73%) of all U.S. businesses are planning to switch to SaaS in the near future; the demand to hire great engineers and find balance will continue to escalate for years.

Additionally, software developer employment is projected to grow 21% by 2028, faster than the average 5% projected growth rate for all occupations.

For engineers, this growth is excellent news. But for leadership, the uneven demand for engineers means it’s more important than ever to consider the pain points of your DevOps team and offer solutions to common issues, like overwork.

Infrastructure Needs to Change to Dampen DevOps Burnout

Throwing more money and more people at an already overworked engineering culture will not make the SDLC more sustainable nor help you hit business objectives.

If we take a page out of the “five whys” and dive into the root cause of universal DevOps burnout, there is a common thread in all software engineering approaches. DevOps, Agile, Six Sigma, Lean, Scrum, you name it–these are tried-and-true methodologies that fail if only the symptoms of our infrastructure issues are addressed. We need to reconsider our current tooling choices if we are to appropriately leverage these frameworks for sustainable development.

Organizations can deflect further engineering burnout and rebound by focusing on saving developers time and reducing toil: The labor engineers devote to repetitive, dull or manual tasks.

It’s necessary to advance infrastructure with automation and embrace next-gen tools that focus on developer experience to halt further DevOps burnout.

Let’s Try Something Different: Automate the API

There needs to be a mindset shift to save DevOps from demise. You can do this by taking a bottom-up approach and introducing more intelligent automation into your software development infrastructure.

Automation saves developers from mundane or low-value tasks and instead focuses their time and talents on planning, creating and delivering high-quality apps. By improving the quality of DevOps functions, engineers feel more valued and have more pride in their role in the company.

Automating tasks doesn’t just help the current DevOps team. Embracing automation frees up your existing workforce, requiring lower hiring demand while retaining confidence that their DevOps team is operating at peak efficiency. This approach tackles the root of the problem—too much work, not enough developers—and allows organizations to retain developers long-term by making their work lives more, well, livable!

Let technology do the mundane, so developers can apply their specialized expertise where it matters. Hire less but do more. Automate workflows so that developers can do their real work: Write code. Sidestep the employment demand issue and protect developers.

Of course, this approach doesn’t come without drawbacks. Even a near-perfect product can introduce failures if it requires too much customization by highly specialized developers. Then, costs begin to skyrocket because of the manual labor required for API development for customization and database management.

When done effectively, continuous development is a shining example of improving the infrastructure of DevOps and impacting burnout with automation. Continuous integration and continuous deployment (CI/CD) allow for faster feedback from your customer base, letting you turn around adjustments of features, add or remove things that actually fit and solve problems for your customers faster.

3 Next-Gen Development Tools to Save Your Team From Continued Toil

Tackle developer overload by incorporating the next-gen development tools designed to improve the developer experience. Make the workday more manageable, not more complex, with three emerging categories of development tools to fix DevOps burnout.

1. Automated Code Suggestions
Context-aware code completion tools suggest code to developers during the coding process. Automated code suggestions save developers precious time (and labor) thanks to fewer keystrokes and are designed to increase the speed of the entire coding process.
2. Instant API
With only a few lines of code, instant API connects your data to your app, helping to turn every developer into a backend dev. Whether you need to power a web app or a mobile app, hosting your API and databases in the cloud on one platform allows teams to configure, test and manage APIs without the all-too-familiar manual burden on developers.
3. Neural Networks
A branch of machine learning, artificial neural networks are computational models that extract meaning from complex or messy data to detect trends and patterns. Neural networks, while not perfect, can suggest improvements to coders as they write.

We are doing our engineering workforce a grave disservice by ignoring the Great Burnout and not addressing the shift needed to course-correct DevOps from the ground up. Without the necessary infrastructure automation advancements and adoption of developer-focused tools, teams will continue to battle against velocity demands and churn. It’s time to embrace a new mindset and usher in a new era of DevOps productivity and developer satisfaction.

January 2, 2023
Best of 2022: How DORA Metrics Can Measure and Improve Performance
As we close out 2022, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

A technology company’s most valuable assets are its people and data, especially data about the organization itself. By knowing what data to track over time, engineering leaders can measure how efficiently their DevOps teams are operating and enable them to maximize their value stream to deliver the best possible product to end users.

After years of research, Google’s DevOps Research and Assessment (DORA) team identified four key metrics for evaluating a team’s performance:

Lead time for changes

Deployment frequency

Mean time to recovery

Change failure rate

DORA metrics have now become the standard for gauging the efficacy of software development teams and can provide crucial insights into areas for growth. These metrics are essential for organizations looking to modernize and those looking to gain an edge against competitors. Below, we’ll dive into each metric and discuss what they can reveal about development teams.

Lead Time for Changes

Lead time for changes (LTC) is the time between a commit and production. LTC indicates how agile a team is—it not only tells you how long it takes to implement changes but how responsive the team is to the ever-evolving demands and needs of users. The DORA team identified these benchmarks for performance in their Accelerate State of DevOps 2021 report:

Elite performers: Less than one hour

High performers: One day to one week

Medium performers: One month to six months

Low performers: More than six months

LTC can reveal symptoms of poor DevOps practices: If it takes teams weeks or months to release code into production, there are inefficiencies in their process. One can minimize their LTC through continuous integration and continuous delivery (CI/CD). Encourage testers and developers to work closely together so everyone has a comprehensive understanding of the software. Consider building automated tests to save more time and improve the CI/CD pipeline.

Because there are several phases between the initiation and deployment of a change, it’s wise to define each step of the process and track how long each takes. Examine the cycle time for a thorough picture of how the team functions and further insight into where they can save time.
One should be careful not to let the quality of their software delivery suffer in a quest for faster changes. While a low LTC may indicate that a team is efficient, if they can’t support the changes they’re implementing or they’re moving at an unsustainable pace, they risk sacrificing the user experience. Rather than compare the team’s Lead Time for Changes to other teams’ or organizations’ LTC, one should evaluate this metric over time and consider it an indication of growth (or stagnancy).

Deployment Frequency

Deployment frequency (DF) is how often you ship changes; how consistent your software delivery is. This metric is beneficial when determining whether a team is meeting goals for continuous delivery. According to the DORA team, these are the benchmarks for Deployment Frequency:

Elite performers: Multiple times a day

High performers: Once a week to once a month

Medium performers: Once a month to once every six months

Low performers: Less than once every six months

The best way to enhance DF is to ship a bunch of small changes, which has a few upsides. If deployment frequency is high, it might reveal bottlenecks in the development process or indicate that projects are too complex. Shipping often means the team is constantly perfecting their service and, if there is a problem with the code, it’s easier to find and remedy the issue.

If a team is large, this may not be a feasible option. Instead, one may consider building release trains and shipping at regular intervals. This approach will allow the team to deploy more often without overwhelming your team members.

Mean Time to Recovery

Mean time to recovery (MTTR) is the average amount of time it takes your team to restore service when there’s a disruption like an outage. This metric offers a look into the stability of your software, as well as the agility of your team in the face of a challenge. These are the benchmarks identified in the State of DevOps report:

Elite performers: Less than one hour

High performers: Less than one day

Medium performers: One day to one week

Low performers: Over six months

To minimize the impact of degraded service on your value stream, there should be as little downtime as possible. If it’s taking your team more than a day to restore services, you should consider utilizing feature flags so you can quickly disable a change without causing too much disruption. If you ship in small batches, it should also be easier to discover and resolve problems.

Although mean time to discover (MTTD) is different from mean time to recovery, the amount of time it takes your team to detect an issue will impact your MTTR—the faster your team can spot an issue, the more quickly service can be restored.

As with lead time for changes, you don’t want to implement sudden changes at the expense of a quality solution. Rather than deploy a quick fix, make sure that the change you’re shipping is durable and comprehensive. You should track MTTR over time to see how your team is improving and aim for steady, stable growth.

Change Failure Rate

Change failure rate (CFR) is the percentage of releases that result in downtime, degraded service or rollbacks, which can tell you how effective a team is at implementing changes. As you can see, there is not much distinction between performance benchmarks for CFR:

Elite performers: 0-15%

High, medium and low Performers: 16-30%

Change Failure Rate is a particularly valuable metric because it can prevent a team from being misled by the total number of failures they encounter. Teams who aren’t implementing many changes will see fewer failures, but that doesn’t necessarily mean they’re more successful with the changes they do deploy. Those following CI/CD practices may see a higher number of failures, but if CFR is low, these teams will have an edge because of the speed of their deployments and their overall success rate.

This rate can also have significant implications for the value stream: It can indicate how much time is spent remedying problems instead of developing new projects. Because high, medium and low performers all fall within the same range, it’s best to set goals based on the team and the particular business rather than compare to other organizations.

Putting it All Together With DORA Metrics

As with any data, DORA metrics need context, and one should consider the story that all four of these metrics tell together. Lead time for changes and deployment frequency provide insight into the velocity of a team and how quickly they respond to the ever-changing needs of users. On the other hand, mean time to recovery and change failure rate indicate the stability of a service and how responsive the team is to service outages or failures.

By comparing all four key metrics, one can evaluate how well their organization balances speed and stability. If the LTC is within a week with weekly deployments but the change failure rate is high, then teams may be rushing out changes before they’re ready, or they may not be able to support the changes they’re deploying. If they are deploying once a month, on the other hand, and their MTTR and CFR are high, then the team may be spending more time correcting code than improving the product.

Because DORA metrics provide a high-level view of a team’s performance, they can be beneficial for organizations trying to modernize—DORA metrics can help identify exactly where and how to improve. Over time, teams can measure where they have grown and which areas have stagnated.

Those who fall into the elite categories can leverage DORA metrics to continue improving services and gain an edge over competitors. As the State of DevOps report reveals, the group of elite performers is rapidly growing (from 7% in 2018 to 26% in 2021), so DORA metrics can provide valuable insights for this group.

But remember that data will only get you so far. To get the most out of DORA metrics, engineering leads must know their organization and teams and harness that knowledge to guide their goals and determine how to effectively invest their resources.
December 30, 2022
Best of 2022: We Must Kill ‘Dinosaur’ JavaScript | Microsoft Open Sources 3D Emoji

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

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.

This week: JavaScript is a bloated barrier to progress, and Microsoft’s emoji are on GitHub. (more…)

December 30, 2022
Best of 2022: Environments-as-a-Service: Free Your Devs

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

Environments are the bane of a DevOps engineer’s existence and have been since the invention of the server. They can create giant bottlenecks that hamper productivity and suck the life and motivation out of developers. But they’re also completely necessary.

DevOps teams spend a ton of time building and maintaining their development environments. They are critical to testing new websites, apps, products and updates; making sure everything works the way it is supposed to. And not having enough environments can slow down workflows as developers wait their turn to use an environment.

There is a new push in the software industry to provide environments-as-a-service (EaaS), removing the annoying yet necessary work of building and maintaining environments and giving DevOps engineers more freedom to tackle more challenging, revenue-generating projects.

EaaS enables companies to use a third-party service to create a new development environment on-demand, including data, infrastructure and code—all the things necessary to build and run an app. Environments-as-a-service bring major improvements to businesses, saving money and time while increasing the velocity, delivery and deployment speed.

EaaS offers automation and codification of all the things that would otherwise waste DevOps and infrastructure folks’ time. They should be focused on higher-value tasks, like creating and refining what makes the company or product unique.

Removing Bottlenecks

When prepping for a new product or service, teams have to test all associated code to make sure it is functional, secure and that there are no hiccups. Multiple environments are crucial to this process. However, in many cases, teams work within a single, shared staging environment.

This setup means developers have to wait in line to test their part of the product. These bottlenecks are among the biggest causes of delayed releases.

Time is money, and in this case, lost time costs money. We estimated the total cost of managing environments exceeded $45 billion annually, and release delays cost organizations millions of dollars every year.

Organizations can layer EaaS on top of their infrastructure-as-code (IaC) frameworks, agile workflows and other important software. By doing this, developers can create a new environment with a single click.

That means developers can make a new environment for every feature branch pull request. EaaS also unlocks customization capabilities, as well. For example, testing requires larger and faster environments that integrate with other key services, while more scaled-down environments work well for processes like demos.

Now, developers are free to test and develop software, without waiting or stepping on anyone else’s toes. Plus, on-demand environments can also be destroyed when they are no longer needed. That’s capacity planning in real-time.

Save Time and Money

Capacity knowledge and better capacity planning mean money saved. Knowing how many environments are needed, and what types, helps organizations avoid over- or under-spending on cloud infrastructure.

Building out environments can take more than a year for even sizable DevOps teams and cost hundreds of thousands of dollars, not to mention the challenges of ongoing management, integration of new tech and management of cloud resources and costs. A third-party EaaS provider takes care of all of that, freeing DevOps engineers to work on hard problems, rather than maintenance and repeating work that has already been done as technology advances.

Is Your Organization EaaS Ready?

Any time a company automates something as important as staging and testing environments, though, it’s important to have all their ducks in a row. Luckily, the best ways to do that match up pretty well with best practices for building out any infrastructure platform:

● Using infrastructure-as-code automates the provisioning of infrastructure instead of doing it manually.

● Containerizing custom code makes it easier to quickly reproduce it for new environments.

● Finally, carefully think about how your environments will behave when they are created dynamically. Simple things like creating environment variables for hostnames and trying not to hardcode variables that are environment-specific are a must.

Organizations that have followed these steps are EaaS-ready. By automating these painstaking tasks, companies can unleash their DevOps teams to be superheroes for the organization, solving the biggest problems and letting tech take care of the rest.

December 23, 2022