devopsy.kinsta.cloud

Category: DevOps Practice

90% Of Orgs Say Multi-Cloud Helps Achieve Business Goals

Multi-cloud is the new normal. And thankfully, this new normal isn’t just happenstance—it’s driving positive outcomes.

New findings show that most organizations benefit from using multiple cloud providers. Multi-cloud adoptions are helping achieve business goals, such as improving reliability and scalability and increasing overall security and governance. However, nearly all organizations (94%) admitted that they have some avoidable cloud spending and skills shortages continue to hold back a fully-realized multiple-cloud success.

HaschiCorp recently released the 2022 State of Cloud Strategy Survey: Making Multi-Cloud Work. In addition to showcasing the positive outcomes of multi-cloud adoption, the report found a trend toward automation frameworks that help operationalize multi-cloud. Below, I’ll explore the report’s key takeaways to see what CloudOps and platform teams can garner from current multi-cloud trends.

Multi-Cloud is Achieving Business Goals

First off, the use of the public clouds is increasing dramatically—the majority of public cloud workloads will likely double in the next two years. To support this influx, more organizations are moving toward multi-cloud. According to the HashiCorp survey, 60% are already multi-cloud and 21% plan to use multiple clouds within the next year.

The good news is that a multi-cloud strategy appears to be working. A full 90% of respondents said multi-cloud is helping their organizations achieve their business goals. This figure is an impressive jump from HashiCorp’s 2021 survey, in which only 53% of organizations said multi-cloud was helping them achieve their business goals.

So, what exactly are companies extracting from multi-cloud adoption? Well, the topmost business goal driving multi-cloud is reliability, at 46%. This is followed by digital transformation (43%), scalability (42%), security and governance (41%) and cost reduction (39%). As we can see, multi-cloud equally benefits various areas.

Centralized Automation Supports Multi-Cloud

With the rise of multi-cloud, CloudOps is becoming its own discipline. As such, it’s common for an organization to build a dedicated Cloud Center of Excellence (CCoE) or strategy team to manage cloud operations—86% said they relied on a cloud platform team. Such a team is often in charge of standardizing cloud services, developing cloud best practices, creating operational policies and related duties.

To aid cloud platform teams, cloud automation is becoming increasingly important. The survey found that 99% see automation as important for operationalizing multi-cloud infrastructure. Multi-cloud automation could help solve inconsistencies across varying cloud workflows. Respondents also found it can be applied to deliver more flexible infrastructure, improve security and governance and better utilize cloud resources. Improving security is especially important here, as 89% said security is a key driver of cloud success.

So how are these automations built? Well, folks are rarely developing cloud automation tools from scratch—only 27% do so. It’s far more common to either use open source or commercial tools for cloud automation. It’s pretty equal across the board whether these tools are run ‘as-a-service’ or are self-hosted.

Regardless of the tooling type, companies are experiencing a broad set of benefits from using middleware to manage their multi-cloud operation strategy. 49% rank scalability as a benefit. This is followed by infrastructure provisioning (42%), cost optimizations (40%) and more flexible deployment options (39%).

(Nearly) Everyone is Overspending on Multi-Cloud

Unsurprisingly to some, the study found that 94% of organizations are wasting money in the cloud. The following were the top cited areas that contribute to cloud overspending and waste: Idle or underused resources (66%), overprovisioning resources (59%), a lack of needed skills (47%) and manual containerization (37%).

The cloud overspending dilemma necessitates forethought into optimizations and reduction of idle resources. As I’ve previously covered, some organizations are even tinkering with employing a cloud economist, or Cloud CFO, to keep escalating cloud fees in check. To help this mission, 43% say consistent and automated tooling has or would lead to better utilization of cloud resources.

Although wasteful spending is pervasive, the majority of companies are forecasting their cloud spending correctly. More than half (57%) said that in 2021 their organization’s projected cloud spend aligned with their actual cloud spend.

Getting the Most Out of Multi-Cloud

Multi-cloud is becoming more common across all IT divisions—as is middleware to operationalize and standardize logic between multiple clouds. And, widespread business success with multi-cloud signals increased maturity in this area.

Yet, multi-cloud doesn’t come without its challenges. Skill shortages rank as the highest factor impeding an organization’s ability to operationalize multi-cloud. Businesses must face other challenges, such as siloed teams, compliance and risk management and lack of training in order to fully realize multi-cloud. Standardized operating models, along with shared workflows and policies, are possible ways to combat these roadblocks.

The HashiCorp study surveyed 1,000 technology practitioners and decision-makers from around the world. HashiCorp also partnered with Forrester to provide additional analysis of the findings. To read the results for yourself, check out the full report here.

September 1, 2022
Getting Started With GraphQL APIs

GraphQL, a query language for APIs and a runtime for fulfilling those queries with your existing data, is rapidly growing in popularity. According to the latest State of JavaScript survey report, 44.3% of respondents said they had used GraphQL APIs in 2020 compared to only 5% in 2016. Additionally, many Fortune 500 companies now use GraphQL APIs for their backends in production, while top tech companies like Facebook and GitHub use the API technology to improve their product offerings and boost system performance.

With the ever-changing technology landscape, you might have doubts about adopting GraphQL API for your backend and be unsure how it can improve your current data needs. However, regardless of what language or architecture you are using, GraphQL APIs can help simplify data access, supercharge the product development process, improve application performance and handle complex back-end data scenarios.

One Unified Endpoint For Your Backend

One advantage of GraphQL APIs is that they provide a single unified endpoint for your backend to meet both client and general API use cases. A single GraphQL API can handle all the client’s requests and forward them to the correct backend service.

As companies and their products scale, REST endpoints can become large and incredibly hard to manage. One of the main problems in REST is the N+1 problem, where the client calls the server N+1 times to get N number of resources, mainly because a single REST resource does not provide enough information for the client to operate with.

Brennan Saeta, an infrastructure engineer at Coursera, cited centralizing REST APIs for simple consumption by the client as one of the reasons why GraphQL API appealed to them.

GraphQL API hides the complexity of the underlying backend system by aggregating the required data from different sources and providing a simple interface that clients can communicate with through a single resource.

Improved Application Performance With GraphQL

GraphQL API improves application performance by reducing JSON payload size and network overhead from multiple API calls. By allowing the client to specify its data requirements, GraphQL APIs eliminate the need for unnecessary generic data being passed from the back end and minimize the number of roundtrips required to retrieve back-end data.

As companies scale and iterate their products, the data required by different clients and pages changes. In REST API design, when new requirements arise, developers must decide whether to create a new endpoint and have clients make a new request for that data or add more data to an existing endpoint. The first option leads to more server roundtrips, and the second option increases payload size, which can hinder app performance.

With more applications being accessed over flaky mobile networks and app speed being an important metric for retaining users, minimizing server roundtrips and data transferred over the wire is paramount. Companies like Netflix and Pulley have reported faster page load times and overall app performance after switching to GraphQL APIs.

With GraphQL APIs, clients receive only the data they specify from the backend server in a single trip, saving network bandwidth and resources.

Improved System Reliability

GraphQL API improves system reliability by ensuring that client queries are valid and in sync with the GraphQL schema specification before query execution. GraphQL uses a type system that describes what type of data can be queried from the backend server and in what form it exists. A strongly-typed schema offers enhanced security over REST APIs by preventing breaches like SQL injection and unintentional data leaks, resulting in a more secure and reliable application.

Type-safety ensures that any breaking changes by the backend server would be caught by clients consuming the data, resulting in less downtime. With GraphQL APIs, you can modify and deprecate API fields while still maintaining backward compatibility. It is easier to know which fields in the API are being used by what clients and which ones are not. With GraphQL, API developers can confidently make changes to the existing APIs without breaking the existing functionality.

Swiggy, India’s largest food delivery platform, discussed how adopting GraphQL API for their back end enabled them to make changes to their existing APIs without breaking the consumer application.

GraphQL ensures API consistency, reliability and security, resulting in better system performance.

Better Developer Experience

Adopting GraphQL APIs improves the developer experience for both frontend and backend developers. Backend developers want to build APIs that are intuitive and easy to explore and navigate. GraphQL helps with that by reducing the time spent documenting APIs.

Through a concept known as introspection, GraphQL APIs allow clients to query the schema and discover the resources available on it. With excellent tools and libraries like the GraphiQL IDE, the interactivity for GraphQL API endpoints is much more intuitive for the developer.

API consumers want APIs that are flexible, easy to integrate and support a variety of client use cases (web, iOS and Android). Because of REST’s inflexibility, it is challenging to create a single endpoint that can meet all of the client’s data requirements. Often the same client has to call multiple APIs to get the data it needs from the backend. Additionally, with REST APIs, frontend developers have to rely on the backend for API specifications before building product features, leading to slower development time.

Peter Downs, director of engineering at fintech startup Pipe, said choosing GraphQL APIs early on cut their development time by 90%. With GraphQL APIs, frontend and UI developers can quickly and easily iterate on features by simply specifying the data requirements in the GraphQL API, thereby reducing the dependence on backend developers to make changes.

Getting Started With GraphQL APIs

The best way to learn GraphQL is by getting your hands dirty and building applications with it. Depending on your language of choice, there are GraphQL libraries in many different languages to help you get started.

As with any new technology, adopting GraphQL APIs for your back end and building high-performant GraphQL backends requires experience, which is not peculiar to GraphQL alone.

If your application relies heavily on interconnected data, you aim to develop an API to be used across several clients or are looking for a high-performant API solution for your backend that minimizes bandwidth usage, then GraphQL API is a perfect data layer for your backend.

August 31, 2022
Build Once, Deploy Anywhere

This late in the game, it seems stunning to me that I have to write this, but there are plenty of you who aren’t there yet—so let’s try a different approach.

A huge part of DevOps is reducing redundancy. We have cut the fat until it hurt, then refocused and cut some more. There is a blog here about burnout, but we’ll save that for another day. The point is, we don’t do the same thing over and over unless there is a quantifiable benefit—like rebuilding and testing new iterations or spinning up base images to start a new project.

We insist that our applications run in as standardized an environment as possible, with images from a repository and standardized software installed.

And then we promptly put it into a unique environment where deployment is completely different. Yes, I’m talking about which cloud or which data center; if it’s deployed via a data center, then hardware, virtual machine or container? The work to standardize the important bits and leave the less impactful bits to teams to decide has been astounding on the Dev side of DevOps (for those new here, what I call DevOps), but have been far less effective in DevOps. Even companies that claim to be pure cloud generally have two or more cloud vendors, each of which is doing things differently.

So, with all of that said, I can say what I should not have to say after all of these years:

Make containers standard. I don’t care which flavor and management tool you use, but add in that portability layer. It will protect you from a future where your preferred hosting environment (be it cloud, local or hosted) becomes hostile or overly expensive—or simply ceases to exist. And it will standardize the rest of your DevOps processes. Yes, your preferred cloud vendor offers Kubernetes, and no, that’s not sufficient. Kubernetes offerings today are like Microsoft in the 1990s. Embrace and extend to build the lock-in barrier higher. You do get some great functionality from the cloud vendors I pay attention to, but processes become non-standard. Better to limit platform-specific work to “spin up a server” and have everything else be reusable whereever you are deploying. The benefits here are far-reaching; there will be configuration and security issues that are different when you move from cloud to cloud or cloud to data center or data center to cloud, but the core of DevOps will remain standardized. There are tools to help with baseline cloud security and risk management, so those in addition to using Kubernetes as a portability platform will make current work less onerous, and massively increase portability from deployment location to deployment location.

You’re short of staff. It does not take a rocket scientist to predict that this situation will not change. Adopt the things that will reduce your workload—like DevOps standardization on Kubernetes (or OpenShift or whatever) as a deployment platform—and keep rocking it. You can’t wave your hand and get more staff or hours in the day, but you can implement containers as the sole deployment option to save time. And use those hours to solve other company problems—because that’s what we do, solve problems for the business. And keep smiling, because you’re rocking it. If you weren’t, they’d find someone who could.

August 31, 2022
TidalScale Enables Hot-Swapping of Failed Servers

TidalScale has updated its namesake software for automating server management to include the ability to detect and prevent impending failures and enable IT teams to hot-swap another server.

Version 4.1 of TidalScale also adds server wear leveling and preventative health checks that identify servers that should be replaced based on their remaining estimated life span.

TidalScale CEO Gary Smerdon said that capability is especially critical given the high rate of DRAM memory failure that results in a high rate of downtime caused by server failures. The latest update to the company’s software-defined server management software reduces the failure rate in on-premises or cloud computing environments by a factor of 100 to ensure 99.999% uptime, he said.

The company also announced that its software is now available on the Amazon Web Services (AWS) Marketplace.

TidalScale employs machine learning algorithms to aggregate and virtualize CPU cores, memory and I/O across servers to present operating systems with a single software-defined server. That makes it possible to hot-swap individual servers to ensure availability.

The single biggest cause of downtime in IT environments is memory failures; they are now 100 times more likely than they were a decade ago, noted Smerdon. In most cases, the root cause of the issues is the demands of modern applications running on legacy infrastructure that was not intended to support the latency requirements of those applications, he added.

That issue can be especially acute in cloud computing environments where infrastructure is often shared by multiple applications, said Smerdon.

It’s not clear at what rate cloud service providers are replacing legacy server infrastructure, but the ability to determine when to replace infrastructure gives IT teams an added measure of control over servers regardless of where they are deployed. The biggest issue, of course, is not so much replacing a server as it is determining which one actually failed. It often takes longer to identify a failed server than it does to bring a new one online.

TidalScale is made available by both cloud service providers and manufacturers of servers used in on-premises IT environments, but it needs to be configured and deployed by an IT team. The overall goal is to not only increase system availability but also reduce the total cost of IT by managing infrastructure more efficiently across the life span of a server, said Smerdon. Some IT teams routinely replace servers at specified intervals, regardless of actual usage, to avoid downtime. TidalScale enables IT teams to determine which servers to replace based on the actual wear within the context of a self-healing server farm, he noted.

Given all the things that might potentially go wrong in an application environment, not having to worry about server failures should enable DevOps teams to spend more time optimizing application performance.

In theory, of course, modern applications based on microservices should be able to reroute calls to application programming interfaces (APIs) anytime a server becomes unavailable. However, over time it’s not uncommon for single points of failure to emerge as applications are updated. In the meantime, the majority of applications running today are based on legacy monolithic architectures that are much more susceptible to server failures that, unfortunately, are still far too common.

August 30, 2022
The Secret to Secrets Management: Reduce Source Code Vulnerabilities

We are in the cyberattack age. From Microsoft to Crypto.com, no company is completely safe from malicious attackers, and it seems as if a new major cyberattack is announced weekly, if not more frequently. As more companies not only go digital but expand their digital offerings and initiatives, there are more opportunities for cyberattackers. Security teams within IT organizations are hard at work to ensure that their company isn’t next in the headlines. However, as the tech world moves to everything-as-a-service (IaaS, PaaS, SaaS, etc.), the move toward everything-as-code is happening in tandem. As a result, many developers are unknowingly keeping sensitive data (secrets, passwords, certs, keys, etc.) stored in Git source code repositories. This information is often pushed to production which puts sensitive information at greater risk of exposure.

The good news is there is a way to ensure that secrets are locked tight within source code. Let’s explore the complexity and realities of securing source code today and how to take the guesswork out of finding at-risk code that could land your company on the front page of the news tomorrow.

Secrets Management is Challenging and Costly

Sophisticated cyberattackers will stop at nothing to breach valuable data assets. Secrets leaked from source code make it easy for threat actors to access applications using the same credentials intended for legitimate purposes.

At the pace of continuous software development, developers must move quickly to build applications. However, security teams that are expected to prevent breaches are not often well-versed in all facets of the software development life cycle (SDLC). This becomes an issue as the number of lines of code (and the secrets kept within) rise alongside the number of apps developed. According to a recent report from 1Password, “two in three (65%) IT and DevOps employees estimated their company has more than 500 secrets.” And, according to the same report, “the average cost of a secret’s leak is $1.2 million. Poor secrets management can result in organizations losing $8.5 billion annually.” Secrets are vital to building any connected application or process. If hard-coded or left unprotected in source code, the proverbial keys to the kingdom are at risk of exposure—as are your loyal customers.

It’s clear that source code security should be a priority for security teams and DevSecOps professionals. Let’s examine how they can achieve this without sacrificing developer productivity.

How to Reduce Threats Through Secrets Management Best Practices

Manually searching source code repositories for vulnerable secrets can be almost impossible. However, there are some best practices to follow to ensure vulnerabilities are caught early and often:

● Identify and remove secrets in code: You can’t protect what you can’t see. It’s important to have visibility into source code to be able to see where vulnerabilities may exist. There are a few ways of potentially going about shining a light on vulnerabilities. One is through manual scanning of source code, but this takes away valuable time developers could be spending on more innovative tasks. There are also some open source solutions that can help with scanning source code repositories, but as with everything open source, this means developers will have to maintain it (keep it up to date, integrate it, etc.). Instead, security teams should consider looking for a unified toolchain platform to help with source code vulnerability identification and remediation.
● Alert and remediate in code repositories: Provide a fast feedback loop to a developer or DevOps engineer before releasing code into production. Remediation should happen at the time of commit. The idea here is to block secrets from being committed to your source code repositories in the first place.
● Adopt a secrets management tool: Don’t store secrets or binaries within source code—nothing but code should be in your source code repositories. Remove secrets to a secrets manager (i.e. HashiCorp Vault), keys and certificates manager (i.e. Azure Key Vault), etc. Modularize and isolate these managers, but make sure they still communicate with each other so that they don’t expose secrets.

As cyberattacks continue to increase, it is imperative that security teams take a hard look at their source code to ensure that it is locked up tight. Keeping secrets out of source code entirely is recommended in theory but difficult to ensure in practice. Following the above best practices will help reduce the risk of exposure of sensitive data and reduce the risk of losing loyal customers and revenue dollars.

August 30, 2022
The Power of Automation and Distributed Sources of Truth

Enterprise networks are vast, intricate systems with multiple methods for storing configuration and state information. The configurations of those networks are also constantly changing as new applications, services or other updates are added. When you consider the complexity and dynamic nature of an enterprise network, it may be alarming to learn how much data–including most network configurations–is still updated manually, often in the middle of the night. To make that process even less efficient, the people doing the updating are required to manually log those updates on spreadsheets or into a custom-built database.

Relying on manual processes to maintain and manage the state of an enterprise network not only leaves the door open for errors but can also lead to the network spreadsheets or databases being out of sync with the actual current state of the network. Is the network correct? Or is the spreadsheet correct? Should we make the network look like the spreadsheet? Or should we update the spreadsheet to reflect the network? What is the actual source of truth?

The good news is that the reality of modern networking has changed the paradigm. As programmable networks are deployed more broadly, manual CLI interfaces are no longer necessary. Reading and writing network configuration and reading network state can be accomplished quickly and easily with machines and automation.

The Source of Truth

More enterprises are embracing network automation because they recognize the efficiencies it can deliver when managing complex networks and the benefits those efficiencies can add to the bottom line. But if you’re going to automate your infrastructure, your automation solution will need to gather authoritative information about it from somewhere. This source of truth holds the knowledge needed to enable automation to make changes to the network.

Many enterprise networking teams feel they need to rely on a single source of truth to know the true state of the network. They believe that building a single system/server/database that can synchronize with the configuration and state information of all devices across the whole network is a viable solution. But such a solution doesn’t currently exist. Given the multifarious nature of today’s networks, relying on a single source is both impractical and potentially expensive.

Rather than asking “What is the single source of truth?” perhaps the better question is “What will provide better data: Creating a single source of truth that tries to synchronize to the entire network? Or accessing distributed sources of truth needed to accomplish the automation in real-time?”

Instead of relying on a single source of truth, enterprises should focus on accessing multiple sources of truth to conduct proper and meaningful automation.

Cast a Wider Net

If you’re running a service provider network, for instance, your business is your network. If you’ve spent millions, or even a billion dollars on your network assets, it’s worth your time to have a system in place that accurately manages and maintains those assets. A single source of truth won’t provide that.

Also, as the network scales in size and complexity, the time it takes to synchronize a source of truth to the network also grows, limiting how often you can synchronize and leading to a greater time delta between synchronization states.

Finally, the process of trying to create a single source also doesn’t address the real issue, which is that enterprises are still relying on manual processes that will almost always result in the source of truth databases and the actual network status being out of sync at some point. And that can have serious negative effects on a business as well.

The case for accessing multiple sources of truth is a relatively simple one: it allows for greater flexibility and enables enterprises to more easily leverage data to benefit their business.

With the advent of programmable networks–machines talking to machines–the most current automation solutions can access multiple distributed sources of truth–different APIs and databases that are responsible for being the source of truth for different parts of the network – and federate and sync data from these systems in real-time, providing a truer window into the status of the network and more accurate, actionable data that delivers business value back to the enterprise.

Automation Hesitation

So why are some enterprises still hesitant to commit to a full network automation project? There are various reasons for this, but clearly, there’s concern that not having a single source of truth for network data – or data that may not be 100% accurate – will compromise the automation process. It’s a classic “fear, uncertainty and doubt” thought process: “What if the data is only 70% accurate? If we try to automate with bad data, we’re going to break the network 30% of the time.”

Some network teams may believe they can’t automate anything until they can combine their five or six sources of truth into one huge database. At the same time, leadership may be pushing those network teams to move forward with automation to get more value from the network. By choosing to wait until they finally have a “pristine” database, they could lose months or even years of time, to the benefit of no one.

The solution is to take an incremental approach. Look at all the various network assets–programmable, cloud, legacy, etc.–and start the automation process in the areas where good data exists and where a source of truth doesn’t need to be built. In parallel, you can be cleaning up the other data and add automation when that data is ready.

Being able to utilize multiple sources of truth is better than worrying about having a “perfect” source of truth and holding back on an automation initiative. In the long run, it will be beneficial to both the network team and the business.

Just as important as committing to an automation solution that can integrate with multiple sources of truth to make decisions, is deploying the right automation solution. The most effective automation solution will embrace:

● API-first–The only way to integrate multiple sources of truth into a unified one is through an API-first approach, allowing systems to talk to each other.
● Data federation and transformation–Having unified sources of truth is only impactful when teams can fully integrate the data together while ensuring it speaks the same language.
● Unified view–An abstracted and federated view of the data, processes and logic from integrated systems enables a single pane of glass across an entire network, as well as management tools for simplifying automation across the organization.

Multiple Sources Equal More Actionable Data

With today’s modern, programmable networks–and the absolute necessity for enterprises to have access to accurate, real-time network data–relying on a single source of truth is based on a flawed assumption that we can always have a synchronized database, and therefore is not a viable strategy.

By adopting network automation, organizations can adopt a distributed source of truth solution by enabling the multiple systems of record, and their collective data, to act as the source of truth, mitigating data quality issues and manual errors.

As an enterprise implements its automation strategy, having multiple sources of truth within the network will result in more accurate, timely and actionable data for automation to succeed, which will increase efficiency and drive the business forward.

August 29, 2022
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:

SimplyHired

Kyndryl
Remote
DevOps Engineer
$95,700 – $265,200

Monster.com

Randstad
Remote
Senior Cloud SRE
$130,000 – $150,000

Dice.com

Staples
Framingham, Mass.
Senior Software Engineer I- CICD/DevOps
$135,000

Indeed

Odyssey Information Systems
Remote
Senior DevOps Engineer
$117,798 – $156,338

ZipRecruiter

Synthego
Redwood City, CA
Senior DevOps Engineer
$113,000 to $165,000

August 29, 2022
Understanding the Importance of Developer Experience

If you’re creating a developer tool, you’re bound to run into this dilemma—you know the inner workings of it really well, but others don’t. And without solid documentation and samples to follow, it can be challenging for another person to get started. Friction with the tools we use can contribute to burnout, inhibit creativity and slow down innovation.

Developer experience (DX) is becoming integral for any software company to consider. I recently met with Christine Spang, CTO and co-founder of Nylas, to consider the benefits of investing in developer experience. Below, we’ll take a look at what exactly DX is and consider some best practices for implementing it.

What is Developer Experience?

Developer experience (DX) is similar to user experience but for developer-facing tools. DX considers the developer’s journey while developing with a certain framework, language or platform. “Developer experience is the amount of friction a developer experiences between having clarity on what they want to implement and getting to the point where you have created that thing,” said Spang.

For example, consider integrating with an API to solve a common use case like payments integration. There are many steps involved here, from reading the reference documentation to getting an API key, testing calls and understanding how the service responds. After developers initially integrate the API into their application, they may also have to make continual updates as the service versions. Throughout this journey, DX can be thought of as “how hard it is to figure out how to translate from idea to output,” said Spang.

It’s also important to note that DX isn’t only relegated to public-facing platforms. Having a quality developer experience is just as crucial for internal software. The urgency to improve internal developer experience is increasing with the surge of APIs being developed, especially since the majority of them (58%) are private APIs, according to Postman’s 2022 State of API Report. Depending on the size of a company, internal DX can encompass many areas.

Best Practices for Investing in Developer Experience

So, what are some methods to improve developer experience across the board? Well, having up-to-date documentation, code samples, better examples and standardized documentation rank high as positive developer experience traits. Spang also shared some helpful best practices to improve DX:

Provide scaffolding for the most common cases. Measure patterns around the kind of things people are building with the platform and offer scaffolding to support the common use cases. This might equate to a getting started guide for a common scenario.

Offer sample code libraries. It’s a lot easier to edit code than write it from scratch. With that in mind, create pre-baked environments where developers can play around. Offering working apps, use case templates and glue code can be a practical means to help developers get going more seamlessly.

Start with the reference manual. Walkthroughs and sample code should never replace a complete reference manual. It’s essential to have up-to-date documentation to cater to advanced users from the get-go. From here, you can generate Postman Collections or interactive sandboxes built around the reference specification.

Measure DX success and iterate. One way to monitor developer experience metrics is to record the onboarding flow and measure conversion rates. Where APIs are concerned, this can be tracked by asking how many people get through to making calls? What is the mean time it takes to make the first call? Knowing such metrics can inform how effective your tool’s self-service features are.

One point that’s important for DX is walking the fine line between too much custom work and focusing on the core project. On that note, Spang recommended “making sure whatever you’re building maps to the overall vision of the company.” In essence, if you’re not a consulting shop but a product company, you should stay true to that objective.

“You want to make the path for what people commonly want to do very easy,” said Spang. “Yet, you don’t want advanced users to feel constrained by the platform.”

Examples of Quality Developer Experiences

For those creating developer-facing services, it’s helpful to have a framework to model. So, what are some examples of quality developer experiences?

Well, top public APIs are great examples of where the bar is set for developer expectations these days, said Spang—services like Twilio or Stripe demonstrate relatively seamless developer journeys. Spang also pointed to companies with a strong DevOps and CI/CD background, like Etsy, who have for years invested in usable backend infrastructure that accelerates internal development.

For other sources of quality developer experience, consider the high-ranking developer-favorite technologies from the latest 2022 Stack Overflow survey. Engineers love working with technologies such as PostgreSQL, AWS, Phoneix and Docker. The newer, trending languages tend to be increasingly usable, too. For example, 86% of developers said they love working with Rust while 76.65% dread working with Objective-C.

The Overall Benefits of DX

An investment into developer experience can help improve agility and developer satisfaction, said Spang. For one, an easier path for development increases the velocity in how you ship and evolve projects over time. Secondly, developer experience equates to less burnout and less turnover, both of which can have real business impacts.

The software development industry is growing like wildfire, bringing in waves of entry-level developers each year. Interestingly, the average experience level is decreasing, increasing the need for more abstracted tools and toolkits, said Spang. In this environment, developer experience undoubtedly shines as a competitive advantage.

So, if you’re creating developer-facing tools, consider the experience others will have when using them. Increasing developer experience may just be a defining factor in the project’s success and the long-term happiness of your developer community.

August 25, 2022
NewOps? AIOps? NoOps? Just Don’t Call Me Late for Dinner

Once again, we are seeing an uptick in the use of the term NoOps. I always felt that NoOps was a misleading and, in fact, empty phrase. I don’t care what magic you think you have; you are never going to eliminate the need to operate your software, applications and infrastructure.

I first heard the term NoOps early in the maturation curve of DevOps. Back then, the idea seemed to be that Dev was going to absorb Ops. Between that and the cloud, there really wasn’t a role for traditional Ops to deploy. Managing apps would be easy with the cloud and automation. At least, that was the pie-in-the-sky thinking—but I never bought that.

There were other terms that popped up, like NewOps and AIOps, though that became something else entirely. But really, I think the rise of the systems reliability engineer (SRE) role put the NoOps movement in its grave (where it probably belonged). SRE became the shiny new identity of the Ops crowd and SRE continues to be one of the most popular topics here on DevOps.com.

This latest incarnation of NoOps seems to be a little different. From what I have seen, it is not really NoOps; instead, it is more of a “not your Ops to worry about” movement. It is shifting who is responsible for Ops from the company developing and using the apps to a service provider (or SaaS provider) who is responsible for Ops. It is more a “MyOps” not “YourOps” movement, but there is still most certainly an Ops there.

In my neighborhood growing up, we used to have a saying, “I don’t care what you call me, just don’t call me late for dinner.” Originally, to me, NoOps was very much like that. We changed the name of something, but it didn’t go away or fundamentally change the thing itself.

Now, we still have Ops, it is just a question of who is doing it. That is not NoOps to me. It is “somebody is doing MyOps for me.”

We saw a similar pattern in security. The idea of outsourcing security was never called “NoSec,” because the idea of no security is, frankly, downright scary. Instead, it just meant relying on a cloud vendor or an MSSP to handle your security for you; it was outsourcing your security. An important lesson learned from that was that you can outsource your security ops, but you can’t escape your security responsibility. That is to say, when your customers’ information is breached, saying “We had someone doing this for us!” did not absolve you of responsibility.

The same thing holds true for this new “OutsourceOps.” The outsourcer may do a better job than you at Ops. They may give you SLAs and SLOs that give you reasonable expectations of performance and remedies if those SLAs and SLOs are not met. But it is still your company’s name and reputation on the line.

So is what we seeing as NoOps really NoOps? No, it is Outsourced Ops. But as we said in the old neighborhood, I don’t care what you call it, just don’t call it late for dinner.

August 25, 2022
Everything is DevOps

It’s funny how we in IT tend to be absolutists, shoving everything into the current bucket. XML was going to eliminate programming—even though it wasn’t even particularly good at data representation. NoCode was going to eliminate programming (yeah, that’s a theme, I’ll skip the other 50 or so ‘going to end programming’ cycles we’ve been through), AI will eliminate IT, you must have a mobile app, even if no one will ever use it, my OS/browser/language is better than yours and will win—you get the idea.

We’re currently coming to the end of the “Everything is DevOps” phase. DevOps is a great methodology that helped solve several intractable IT problems but, like everything, marketing and a ton of smart people that want to be “right” have taken it too far. Or have they?

The thing with DevOps is that contrary to what those who try to make a separate market out of DevSecOps or SRE try to tell you, it was designed to literally encompass all of human IT activity. We can excuse the DevSecOps crowd, since DevOps’ roots had a definite “Security is an unimportant bottleneck” feel to it. The SRE crowd, on the other hand, appears to be another case of “my silo is special”. Or, better yet, a stompy marketer saying “We’re late to the DevOps game! Let’s invent something just like it, claim we do it more broadly and give it our own name!”

Let’s look at what each does, for those of you who are skeptical. 1) break down silos. Check. 2) Monitor everything. Check. 3) Use monitoring results to improve product performance and stability. Check. 4) Design and implement products and product features. Check. There’s more, but you get the idea.

Do you know what all of this ignores? You.

One of the issues that our absolutism brings about is that marketers get to dictate what is important. Sometimes that is what enterprise IT needs. Far too often it is what the marketer is paid to dictate.

I don’t care if you call it DevOps or SRE, I care that your organization feels like it is getting its money’s worth out of IT—something, I might add, that most organizations did not feel prior to DevOps. At least most of the ones I dealt with. I even had a job where they created a whole new department and hired me to run it to “get around those people in IT.” I spent as much time educating business leaders about not duplicating entire groups like storage services and InfoSec as I did building and deploying new products. So avoiding that kind of issue is near and dear to my heart. And we’re more ‘there’ than we have ever been.

I do care about whether you call it DevSecOps or not. It should not be different. Shifting security left is the appropriate solution to the double-edged sword of security staffing shortages and increased adversary capabilities. So if your developers are getting secure coding feedback in their IDE or each time a build is kicked off, great! But call it DevOps. Say it is part of the DevOps process. Same with configuration reviews like cloud configuration management—it’s just part of the DevOps process, not a security step to be thought of differently.

I could go on, but hopefully I’ve spurred your imagination a bit and don’t need to.

You rock. Streamline your thinking to streamline your processes, ignore absolutism and call it macaroni for all it matters. Just keep doing what needs doing—at the most convenient place to do it. And keep developing, deploying and monitoring the systems that keep the company running.

August 24, 2022