devopsy.kinsta.cloud

Category: DevOps Culture

  • mabl Makes Move to Automate Accessibility Testing

    mabl Makes Move to Automate Accessibility Testing

    mabl today made available in beta an automated accessibility testing capability that it added to its software-as-a-service (SaaS) platform for testing applications.

    Dan Belcher, mabl co-founder, said given the increased accessibility requirements included in various compliance mandates, there is a greater need to address these issues as early as possible in the application development life cycle. Otherwise, organizations could find they are liable for failing to comply with accessibility requirements outlined in, for example, versions 2.0 and 2.1 of the Web Content Accessibility Guidelines (WCAG).

    At the same time, providers of applications that don’t address accessibility are also likely to find themselves called out on public social media forums, noted Belcher. The damage to brand reputation can be considerable, he added.

    The SaaS platform mabl created makes it possible to create reusable tests using a low-code engine dubbed axe-core. Those tests can then be inserted, as appropriate, into a DevOps workflow. That approach allows a dedicated testing team to create tests in a way that doesn’t need to occur on a DevOps platform, said Belcher.

    Regardless of regulatory requirements, Belcher said there is a clear need to include end users with disabilities within a digital universe that continues to rapidly expand. Unfortunately, as a whole, the software industry is only just starting to make accessibility a first-class concern, he added.

    The goal should be to enable fast feedback via accessibility regression tests that address, for example, contrast check, said Belcher. However, it’s not likely those tests are going to eliminate the need for periodic audits by accessibility subject matter experts as an application continues to evolve, he noted. Those reviews would address everything from the user interface to the overall performance impact, noted Belcher. It may possible, however, to one day address 50% of the accessibility issues identified in the WCAG guidelines via automation, he noted. Scanning code as it is being developed will prevent a backlog and a buildup of accessibility debt that would be much more costly to address after an application is deployed, added Belcher.

    In general, Belcher said, it’s not likely automation is ever going to entirely eliminate the need for dedicated testing teams. Testing platforms such as mabl are designed to enable a finite testing resource to keep pace with an accelerated rate of application development, he added.

    Accessibility is, for all intents and purposes, a subset of any comprehensive software quality review. The sooner development teams realize that fact the less likely they will find themselves apologizing in the future for not coming to that realization earlier.

  • What Should Elon Musk Do? | Passwordless Future: Tense | WebKit iOS Monopoly Ends?

    What Should Elon Musk Do? | Passwordless Future: Tense | WebKit iOS Monopoly Ends?

    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: Everyone has Twitter advice for Elon, passwordless vision is vacuous, and Apple prevented from forcing Safari. (more…)

  • Defining the Next Cycle of Technology

    Defining the Next Cycle of Technology

    We’re in the middle of what we at ScyllaDB dubbed The Next Tech Cycle. Not “The World of Tomorrow” nor “The Shape of Things to Come” nor “The Wave of the Future”—because it’s already here today. We’re right in the middle of it. It’s a wave that’s carrying us forward, but it began with trends that got their start earlier this century.

    Everything is co-evolving, simultaneously, from the hardware you run on to the languages and operating systems you work with to the operating methodologies you use day-to-day. All of those familiar technologies and business models are themselves undergoing revolutionary change.

    This Next Tech Cycle Goes far Beyond “Big Data”

    We’re talking about huge data. Welcome to the Zettabyte Era. This era, depending on who is defining it and what it is measuring, either started in 2010 (if you’re measuring total data stored on earth) or in 2016 (if you’re measuring total internet protocol traffic in a year).

    Right now, individual data-intensive corporations are generating information at the rate of petabytes per day and storing exabytes in total. There are some prognosticators who believe we’ll see humanity, our computing systems and our IoT-enabled machinery generating half a zettabyte of data per day by 2025.

    Yet, conversely, we’re also seeing the importance of small data. Look at the genomics revolution.

    Because the RNA gene sequence of, say, COVID-19 is actually not that big, data-wise—you can store it in less than 100kb; less than an ancient floppy. But it is increasingly important to understand every single byte of that information because vaccinating against this global pandemic requires understanding every change of that rapidly-evolving pathogen.

    So, this next tech cycle has to scale everything from huge data and small data systems. And the database you will use and the data analytics you perform need to align with the volume, variety and velocity of the data you have under management.

    “Great! Now Make it All Multi-Cloud!”

    Also, this next tech cycle is not just the “cloud computing cycle.” AWS launched in 2006. Google Cloud was launched in 2008. And Microsoft Azure was formally launched in 2010. So, we’re already well over a decade past the dawn of the public cloud. Yet this next tech cycle definitely builds on the ecosystems, methodologies and technologies these hyperscalers provide.

    The database you use also has to align with where you need to deploy it. Does it only work in the cloud, or can it be deployed on-premises far behind your firewall? Does it just work with one cloud vendor or is it deployable to any of them? Or all of them simultaneously? These are important questions.

    Just as we do not want to be locked into old ways of thinking and doing, the industry does not want to be locked into any one technology provider.

    If you’ve just been mastering the art of running stateful distributed databases on a single cloud using Kubernetes, that’s not good enough. Now you’re being asked to do it all over again; this time in a hybrid or multi-cloud environment using Anthos, OpenShift, Tanzu, EKS Anywhere or Azure Arc.

    Computing Beyond Moore’s Law

    It’s also not the basic broadband or wireless internet revolutions. We’re a full two decades into both of those. Yet the advent of gigabit broadband and the new diverse range of 5G services—also capable of scaling to a gigabit—enable incredible new opportunities in real-time data streaming services, IoT and more.

    So how does your database work when you need to connect to systems far and near? How important are the limitations of the speed of light to your latencies? How well do you deal with data ingested from hundreds of millions of endpoints at gigabit-per-second scale?

    And finally, underpinning all of this are the raw capabilities of silicon, summed up by the transistor and core counts of current generation CPUs. We’ve already reached 64-core CPUs. The next generation(s) will double that, to the point where a single CPU will have more than 100 processors. Fill a rack-based high-performance computer with those and you can easily get into thousands of cores per server.

    And all of this is just traditional CPU-based computing. You also have GPU advancements that are powering the world of distributed ledger technologies like blockchain. Plus, all of this is happening concurrently as IBM plans to deliver a 1,000 qubit quantum computer in 2023 and Google plans to deliver a computer with one million qubits by 2029.

    This next tech cycle is powered by all of these fundamentally revolutionary capabilities. It’s what’s enabling real-time full streaming data from anyone to anywhere. And this is just the infrastructure.

    If you dive deeper into that infrastructure, you know that each of the hardware architecture bottleneck points is undergoing its own revolution.

    We’ve already seen CPU densities growing. Yet vanilla standalone CPUs themselves are also giving way to full systems on a chip (or SoCs).

    And while they’ve been used in high-performance computing in the past, expect to see commonly-available server systems with greater than 1,000 CPUs. These will be the workhorses —or, more specifically, the warhorses—of this next generation: Huge beasts capable of carrying mighty workloads.

    Memory, another classic bottleneck, is getting a huge boost from DDR5 today and DDR6 in just a few years. Densities are going up, so you can expect to see warhorse systems with a full terabyte of RAM. These and larger scales are going to be increasingly common—and, for businesses, increasingly affordable.

    Storage is also seeing its own revolution with the recently-approved NVMe base and transport specifications, which will enable much easier implementation of NVMe over fabrics.

    Now, software will have to play catch-up to these capabilities. Just as it took time for kernels and then applications inside of a vertically scaled box to be made async everywhere, shared-nothing, sharded-per-core, and NUMA-aware, this next tech cycle is going to require systems to adapt to whole new methodologies of getting the most from these new hardware capabilities. We will need to reconsider many foundational software assumptions.

    Evolving Methodologies: Agile and Beyond

    Speaking of methodologies, just look at these from the dawn of the millennium and onward. As an industry, we’ve moved from batch operations and monolithic upgrades performed with multi-hour windows of downtime on the weekend to a world of streaming data and continuous software delivery performed 24 × 7 × 365 with zero downtime ever.

    And by migrating to the cloud (and this always-on world) we’ve exposed ourselves and our organizations to a world of random chaos and security threats. We now have to operate fleets of servers autonomously and orchestrate them across on-premises, edge and multiple public cloud vendor environments.

    While Scrum has been around since the 1980s, and continuous integration since 1991, in this century, the twelve principles of the Agile Manifesto in 2001 altered the very philosophy—never mind the methodologies—underlying the way software is developed.

    The Agile Manifesto’s very first line talks about the highest priority being “to satisfy the customer through early and continuous delivery of valuable software.”

    However, the specific term continuous delivery (CD), as we know it today, didn’t take hold until 2009. It was then joined to continuous integration and coincided with the birth of what we now know as DevOps.

    With that, you had a framework for defining change-oriented processes and software life cycles through a responsive developer culture that now, a decade or two into this revolution, everyone takes as a given.

    This graph shows how continuous integration (CI) and continuous delivery (CD) evolved independently. They were eventually conjoined by the term CI/CD, whose popularity as a search term only began to rise around 2016 and did not displace the two separate terms until early in 2020. It is now increasingly rare to refer to CI or CD separately, according to Google Trends.

    Onto that baseline were built tools and systems and philosophies that extended those fundamental principles. The Chaos Monkeys of the world, as well as the pentesters, want to break your system—or break into them—to uncover flaws and defects long before something stochastic and catastrophic or someone maliciously does it for you.

    Cloud-native technologies like Kubernetes and single-source-of-truth for infrastructure methodologies like GitOps were created out of sheer necessity to scale systems to the hundreds of thousands of production software deployments under management.

    DevSecOps

    And that’s still not enough. We’ve already seen software supply chain attacks like SolarWinds, low-level system attacks like Spectre, Meltdown and Zombieload, or human-factor threats like viral deep fakes and millions of fictitious social media accounts using profile images generated by generative adversarial networks, never mind millions of IoT-enabled devices being nefariously harnessed for distributed denial-of-service (DDoS) botnet attacks. Just recently, news broke of the Log4j vulnerability—our best wishes to anyone who was patching code this past holiday season.

    These are all just the bowshocks of what’s still to come.

    So now, your AI-powered security systems are locked in combat every day in real-time against the threat actors attempting to undermine your normal operations. We know this because a growing number of intrusion prevention and malware analysis systems are built at terabyte-and-beyond scale using distributed databases as their underlying storage engines.

    Hence, these days, rather than just DevOps, increasingly we talk about DevSecOps—because security cannot be an afterthought. Not even for your MVP. Not in 2022.

    And these methodologies are continuing to evolve.

    Summary

    This next tech cycle is already upon us. We’re in the thick of it. You can feel it in the same way you’d yearn for major life or career change. Maybe it’s a programming language rebase. Is it time to rewrite some of your core code as Rust? Or maybe it’s in the way you are considering repatriating certain cloud workloads or extending your favorite cloud services on-premises such as through an AWS Outpost. Or maybe you’re actually looking to move data to the edge? Planning for a massive fan-out? Whatever this sea change means to you, you’ll need rock-solid infrastructure that’s available today to take workloads into production right now, but flexible enough to keep growing with your emerging, evolving requirements.

  • How to Avoid Crappy Culture and Keep Engineers Happy

    How to Avoid Crappy Culture and Keep Engineers Happy

    Software engineers know how much they are worth—everyone wants them and there aren’t enough of them to fill that demand. While the need for tech talent is greater than ever, the pandemic has shifted priorities for many engineers. And they’re not alone. It’s a reality shared with millions of others in a variety of fields around the world.

    If the so-called Great Resignation has taught us anything, it’s that everyone is tired of crappy workplace culture. People are beginning to question why they’d stick around at a place where they don’t feel valued and supported. And for those companies not investing time and energy into their culture, good luck holding on to software engineers. They know their value!

    In this uber-competitive environment, the best way to keep software engineers happy and make the company a desirable place to join may seem counterintuitive, but hear me out: Just back off. Trust engineers to do their jobs well.

    Put in place the building blocks for a supportive environment where people feel comfortable taking risks and voicing their ideas—even contradictory ones—in positive ways. Then, get out of the way. Leaders have a responsibility to make these values stick and to hire people who fit them, even if that means not always picking the most qualified person available.

    Don’t Be Afraid of “Dumb Ideas”

    I’ll be the first to say it—I have a lot of dumb ideas. I’m thankful to have worked in places that encouraged me to share those ideas. It taught me to focus on building a company culture that values openness to new thought processes. Because you never know when something that might seem like a dumb idea could actually become the next big thing. 

    No one wants to feel shamed for speaking their mind. Encouraging people to share their ideas, even those that aren’t fully developed, fosters a sense of trust in the team and can lead to greater creativity and innovation. It also makes the company stronger by reducing stress on employees and avoiding negative outcomes like burnout and other health concerns that may ultimately lead to turnover.

    Getting to this point of psychological safety in the workplace is not an easy process. It has to be highly intentional given the standards that are often at play in the professional world. For too long, people have been thought of as replaceable cogs in an organizational structure, not as humans with unique and valuable skills, talent and shortcomings.

    It’s about recognizing that people are human and often want to feel authentic in how they work. That’s why it’s valuable to talk about new ideas to improve the company and its products, as well as talking about how you talk; set a defined standard for how important topics are discussed as a team. 

    Fostering a supportive culture doesn’t mean there aren’t disagreements. But there are ways to offer contrary opinions without being a jerk about it. This mutual respect between engineers allows people to look at things with a critical eye without hurting anyone’s feelings.

    At CodeSee, we do a weekly product review. And this often leads to statements like “the product does this, but I wish it did this.” This isn’t a criticism of anyone, and everyone knows that. It’s everyone helping each other in the pursuit of making things better.

    Don’t Hire Assholes

    Instilling these values in a company is a rewarding experience that allows engineers to flourish. But none of that matters if they don’t also show up in the hiring process. The same things we place importance on in our day-to-day operations are top priorities in hiring: Humility, trust and self-reflection.

    We’d rather have a decent engineer that fits our culture and embodies these values than a great engineer that isn’t supportive of others. We don’t subscribe to the idea that it’s OK to treat people like dirt just because you’re a genius.

    These ethos show up in the questions asked to prospective employees. Two of our go-tos are fairly simple. We often ask interviewees to define three strengths and weaknesses. It’s a number that requires some real introspection and helps us see if a person knows where they could stand to improve and have identified personal growth strategies. We’ll also ask, “When we call previous managers, what will they have to say about you?”

    These questions are meant to tease out some self-reflection, naturally. If they can put themselves in the shoes of their past managers, that shows a high level of self-awareness and empathy.

    Surprisingly, these questions have gotten under the skin of more than a few applicants. I’ve actually had people yell at me, the person doing the interview, because they’ve been made to feel uncomfortable. Obviously, that kind of response told us everything we need to know.

    Tools for Success

    Institutional knowledge is an asset to any team. However, it puts additional strain on senior engineers, who are already stretched thin, to hold that information in their head and teach/explain it to less-experienced colleagues. 

    This is something that needs to change to free up senior engineers to focus more on the big picture. We can solve that with tools to visualize code and by investing in models that provide these models to engineers to improve training. 

    Today, many engineers spend 60% of their time reading code. What if we could reduce that to 40%? Or 20% or even 10%?  If all our engineering talent spent 40% of their time doing other stuff, think about where we could be?

    However, productivity tools can be a double-edged sword. Instead of giving more freedom and trust to software engineers, some companies are using technology to wring every last ounce of productivity out of the workforce, efforts that are surely doomed to fail by encouraging talented engineers to start planning their exit.

    The bottom line is that everyone needs engineers. Losing at least some is inevitable. But if you are thoughtful about creating a supportive, innovative culture—and maintaining it—then it’s a lot easier to compete.  

    But it’s no simple task. Every decision you make—from who you hire to the products you build to the way you talk to each other in meetings—plays a role in shaping culture. Engineers will be compensated everywhere they go, so the best chance to get ahead is to build the best, least-crappy culture possible. 

  • Wi-Fi 7 Chips Ahoy | Google ‘Gone Downhill Fast’ | Real-World ‘Severance’

    Wi-Fi 7 Chips Ahoy | Google ‘Gone Downhill Fast’ | Real-World ‘Severance’

    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: The first silicon for Wi-Fi 7, Google’s search quality “is” failing, and what Severance tells us about The Great Resignation. (more…)

  • The Pros and Cons of Embedded SREs

    The Pros and Cons of Embedded SREs

    To embed or not to embed: That is the question.

    At least, that’s one of the questions that companies have to answer as they decide how to implement site reliability engineering. They can either embed SREs into existing teams, or they can build a new, separate team.

    Both approaches have their pros and cons. The right strategy for your company or team depends, of course, on your needs and priorities.

    What is an Embedded SRE?

    An embedded SRE works as part of a non-SRE team. They might join development or IT operations teams, for example—although they could also be part of quality assurance teams, security teams or any other unit within the organization that can benefit from their expertise.

    Embedded SREs are the opposite of creating a dedicated, general-purpose SRE team. In the latter approach, an organization hires talent that collaborates with non-SRE teams but who aren’t integrated directly into them.

    There are several other organizational models that fall somewhere between these two poles. But typically, the two main types of structures are embedded or dedicated teams.

    Advantages of Embedded SREs

    Embedding SREs into other teams offers several benefits.

    Arguably the most important advantage is that embedded SREs ensure the highest level of collaboration between site reliability engineers and other stakeholders. When they work directly alongside other engineers on a continuous basis, it’s a pretty safe bet that their perspective will inform every decision that the other engineers make. Separate teams will still generally collaborate with other teams, but not necessarily with the same level of dedication as embedded SREs.

    Embedded SREs are also beneficial for organizations where the site reliability engineering concept remains new, and where stakeholders still need to learn what SREs do and the value they can bring. It may be a bit challenging to get buy-in when you propose creating an entirely separate team; indeed, developers or IT engineers may even perceive such a team as a threat to their own jobs (even though in reality, of course, they complement other teams instead of competing with them). But when you add SREs to larger teams, it’s likely to be easier to get everyone on board with the concept and for other types of engineers to appreciate how SREs make their jobs easier.

    Finally, embedded SREs work well for organizations that are on the small side and don’t need an entire team. If you have just several dozen engineers on staff instead of several hundred, hiring a few SREs to embed into your existing teams probably makes more sense than investing in a brand-new team.

    The Challenges of Embedded SRE

    The embedded model has its drawbacks, too.

    One major risk is that the SRE’s influence within a larger team may not be strong enough to have a major impact on how that team operates. A single SRE working alongside a dozen developers or IT engineers, for example, may struggle to integrate site reliability engineering techniques and tools into the existing team’s workflow—especially if it’s a team that already has strong opinions about how it should operate.

    Along similar lines, a single SRE working within a team using the embedded model could end up being stretched too thin to do his or her job well. That’s especially true if other team members expect them to “own” functions that should really be a collective, team responsibility—like responding to incidents or using chaos engineering to test reliability. The latter processes may be led by SREs, but they shouldn’t be their responsibility alone, and the function can start to break down when other team members think of them as the person on whom they can simply “dump” all of their reliability-related tasks.

    Finally, the embedded model can be difficult to scale, which is one reason why it doesn’t work as well at large organizations. If you have dozens of different engineering teams, embedding an SRE into each one requires a lot of management effort. It also deprives the various SREs within your organization of the ability to work closely with each other. In that type of scenario, it probably makes more sense to create a dedicated team and have those SREs interface with other teams as needed, rather than trying to distribute site reliability engineers across the business by embedding them directly into other teams.

    Conclusion

    In general, then, embedded SREs make most sense for companies that have relatively small engineering organizations, and in which the concept of the function has not yet received complete buy-in. For large businesses that have numerous engineering teams, it will likely be easier to manage SREs by creating a separate team just for them.

    That said, your mileage may vary from the norm, and it may be worth experimenting a bit to determine which model—embedded or not—makes the most sense for your company. Keep in mind that you can also use a hybrid approach wherein you embed SREs into some teams, while simultaneously maintaining a dedicated team that leads site reliability initiatives for the organization as a whole.

    After all, site reliability engineering is all about thinking creatively and coming up with innovative solutions to challenges—even the challenge of figuring out how to structure the SREs within your organization.

  • How Engineers Can Contribute to API Security

    How Engineers Can Contribute to API Security

    I’m an engineer, not a security professional. I’ve worked at several startups over the years and have discovered ways to shift my engineering mindset to include a security focus and to incorporate security into my coding practice. 

    I’ve found that when you work with others, an engineering organization can significantly contribute to API security. But how we think about software makes it difficult to get started. There is an alternative perspective—a road not taken—that must be considered when it comes to securing endpoints from threat actors. 

    The Road Not Taken

    Engineers create and optimize applications to solve problems for real users. Engineering time is often in short supply, so we optimize the speed at which we can write those applications. To speed up our processes, we simplify problems and find reusable patterns or techniques. Add a bit of glue, and you have software.

    This perspective is constructive. Thoughts come first and software comes next. And when refactoring existing code for software, we need to think this way. But this utility comes at a cost: If the software works, we only see what it should do. The real story behind the scenes can be much more complex.

    A few years ago, I worked with an engineer on new endpoints for an authorization API. We were working out an issue in the implementation where I could call the endpoints out of order and bypass a challenge. We worked through the example, and he said, “But they are supposed to be called in 1-2-3 order.”

    Attackers don’t share this perspective. Instead, they want to manipulate the software to act in their own interests. They ask, “What is possible?” instead of “What is it supposed to do?” and find ways in which the system fails. To an attacker, the glue is more interesting than the design.

    While probing, an attacker may be thinking some of the following questions: 

    “The password reset endpoint is on v2? Is v1 still running?” 

    “What happens if I skip the verify endpoint?” 

    “What happens when I pass null in the challenge? Empty string? SQL injection?”

    As creators, we’ve converged on this constructive perspective. To build secure software, we need to consider the road not taken and incorporate greater security into our applications.

    Playing Defense

    When you are defending software, your limited time is a disadvantage. There are many engineers—and some have been writing software for many years—which means that you have a lot of code to defend. Each application depends on hundreds or thousands of open source projects, from libraries to deployment tools to server operating systems. 

    Security tools can help you think from both perspectives, especially those that automatically discover endpoints and track response statistics. You can use this data to understand how code maps to your public API surface. 

    In addition to tools, here are several suggestions for on the ground techniques that you could try out.

    Read the Code

    Pick an application, find out where the authentication and authorization code is and read it. Even if you aren’t a strong coder, you can learn something interesting. Better yet, try and take the attacker’s perspective and look for ways you can exploit the code and make it work for you. For instance, you may see the following:

    “SQL injection might be possible in this area. I might be able to extract information about other accounts.”

    “Authorization is complex and confusing in this area. I might be able to use my standard user account to execute actions on other accounts.”

    “Logging is very weak in this sensitive area. I might be able to hammer this endpoint without being noticed.”

    “Code or comments indicate the developer assumes the application is secure for a particular reason. Can I break those assumptions with an external request?”

    The knowledge gained in performing an exercise like this is priceless. You can use it to guide the rest of your API/AppSec work (pentesting, scan remediation, etc.). Further, you’ll often find logical vulnerabilities that scans couldn’t detect.

    Read Code Reviews

    Engineers make decisions in pull requests (PRs). Content in past PRs and review comments have tons of context and can be used to help inform your decision-making. Look through the history, then think through some security-focused review questions:

    “If the code tries to enforce security constraints, can I think of a way around them?”

    “Are there obvious security mechanisms that should be part of this change but are missing?”

    “Would unusual attacker behavior appear in logs?”

    Examining these reviews and understanding the broader context can provide you with valuable information. You might find a sensitive action without any authorization logic, ways a user account can access data owned by other users, or a path through the password reset flow without a valid challenge token.

    Work With Engineers

    If your engineers are working on security-relevant code, ask for some time to talk. Find out what they are working on (and why). Help them think like an attacker, and explain some of the techniques an attacker might use to break their app. And remember to take the road not taken while you work to ensure the security of your applications. 

  • Not Totally Buying Web3? You’re Not Alone

    Not Totally Buying Web3? You’re Not Alone

    The interest in Web3 is heating up. We’ve seen major excitement around blockchain and new Web3 protocols that are poised to reinvent the web as we know it. But it’s hard to hide the skepticism and the suspicion that there are ulterior motives behind large cryptocurrency coin fundraisers. There’s no doubt that there are benefits to the Web3 movement — the decentralized nature of Web3 brings innovative forms of shared ownership. Yet, both the marketing hype and investment fervor could get in the way of actual progress in the industry.

    I recently met with Netlify CEO Matt Biilmann to discuss the missing piece of Web3. For those who don’t know, Netlify has been a big proponent of the JAMstack movement, a design style incorporating JavaScript, APIs and Markdown (hence, JAM). The headless approach decouples the frontend and backend, enabling easier multi-platform support and other benefits.

    According to Biilmann, the theory behind Web3 is exciting and sound and it fits into the headless movement quite well. Yet, in practice, Web3 will require more emphasis on interoperability and open standards, said Biilmann. Without inter-chain portability and better data control, the trend will likely fall victim to the same walled gardens and centralization that underpins the current web. There are some other concerns to keep in mind about Web3 and blockchain, which we’ll explore below.

    Back to The Open Web

    First off, what exactly is Web3? Well, Web3 is a broad term with loosely-related phenomena, but it can be summed up as a new web designed with decentralized technology and built on blockchains with distributed ownership. “There’s a general sense behind the Web3 movement that goes back to roots of the web as a non-centralized entity,” explained Biilmann.

    Whereas in Web2 users were participating in someone else’s walled garden, the concept behind Web3 is that it’s fundamentally open. But how do we make more pieces of the stack a collaborative standard with no single owner? According to Biilmann, this is the aspect that the industry should expand upon.

    Issues With Web3

    There’s a lot of speculation. One big issue Biilmann foresees with Web3 is the rampant speculation. The long-term success of new Web3 projects founded on a blockchain is muddled by the fact that the creators wanted people to buy in so tokens rise in value. “How much of the underpinnings of Web3 are actually solving real problems and how much is pure speculative investment?” he asks. It’s not always apparent whether, behind their flashy, chic facades, blockchain solutions solve real problems.

    A lack of inter-chain interoperability. A lack of interoperability between the many emerging flavors of blockchain could also pose a risk to this fledgling space. “To what degree are they actually building things around standards with the possibility to move from one player to the other?” asked Biilmann. “We need open standards where you can migrate from one to the other.”

    Centralization still exists. No matter what the copy around decentralization said, there will still be players who hold more control and power in a capitalist economy. According to Biilmann, it will be important to make platforms fundamentally open and extendable to avoid creating more walled gardens. He admitted that having strong central providers is not a huge problem as long as these open platforms provided interoperability.

    A lack of identity portability. When a person owns a web domain, they can move content around freely from server to server. In a similar vein, Biilmam believes that comparable freedom is necessary for identity within Web3. The ideal is to increase ownership and portability of one’s digital identity. Yet, Biilmann questioned whether blockchain is the best vehicle for that goal, especially as competing blockchain protocols could interfere with portability.

    Blockchain will still hinge on the authority of an external source. Another issue is how blockchain will interface with reality. Often, a smart contract will point to a URL for an off-chain context without a strict guarantee of what’s happening outside of the chain. If blockchain must depend on the authority of an external source, this is somewhat counter to the ideals of an interdependent network. “Most of the time, you have to trust a provider between what happens in blockchain and what happens in the outside world,” explained Biilmann. In this scenario, the integrity of the blockchain could end up revolving around a single entity.

    Connecting blockchain to the outside world is hard. On that note, the exact process for interfacing with off-chain constructs is still being developed. This usually relies on a third-party oracle model, although some headway has been made to eliminate the oracle concept in favor of a more modern standard for integrating off-chain computations.

    Every operation incurs high processing costs. Blockchain requires excessive processing power to accomplish simple tasks, which can be wasteful at scale both in monetary and resource terms.

    The benefits of NFTs are greatly exaggerated. NFTs won’t likely help the majority of creators. As Kimberly Parker explained, NFT platform sales data showed “an acutely minuscule number of artists making a vast amount of wealth off a small number of sales while the majority of artists are being sold a dream of immense profit that is horrifically exaggerated.”

    NFT scams are common, and since minting an NFT requires exorbitant platform fees, the likelihood of an artist recouping their upfront investment is minimal. “I think that people who stand to gain the most are people like the Winklevoss twins, who are already mega-rich and own an NFT platform,” Cat Graffam said on Time.com. “The biggest losers are the vast majority of unestablished artists that are attempting to break into NFT sales.”

    Keeping Alternative Options On The Table

    “Let’s not jump to the conclusion that cryptocurrencies and blockchain are the solutions,” said Biilmann. As he noted, people have been tinkering with ways to open up identity and data for decades now. These thinkers may also have relevant insights and alternative solutions that shouldn’t be dismissed or ignored.

    For example, Tim Berners-Lee, inventor of the World Wide Web and the HTML programming language, has been spearheading a new initiative called Solid. Solid is a “proposed set of conventions and tools for building decentralized social applications based on linked data.” The project’s goal is to enable true data ownership and better privacy. “If we’re after the goal of an open web, we should be just as curious to know what they’ve been studying for years,” said Biilmann.

    We may be seeing Web3 projects excel simply due to the underlying speculative interest in cryptocurrency, Biilmann said, not that they’re technically the best solution or have the best open ownership model. Other solutions include IPFS for high-volume distributed storage. Or, take DNS, the decentralized naming system at the core of the web—”that part of the existing web is already very open and user-owned,” said Biilmann.

    Goal: Plant Gardens Without Walls

    “I’m excited about this—personally, I hold no grudge about the tech,” Biillmann clarified. “Making identity and underlying data fundamentally more open is awesome.”

    But, at the same time, the space is too speculative and too far removed from building useful things for users, said Biilmann. There is also a pressing need for interoperability and portability in the blockchain industry. And with so much noise driven by the interest in tokens, it could be more beneficial for society to trust a more neutral party in architecting the fabric of our digital lives.

    “It’d be a shame if people forget what we can build already,” said Biilmann, pointing to pre-existing technologies like IPFS and DNS. Although these open standards won’t make early stakeholders rich in the short term, they could help get us to that open state even faster.

    Web3 is still in an early space. And if we separate currency from this ambition, it could deliver tremendous outcomes. “Let’s figure out how we make identity and data open and not tied to specific walled gardens,” said Biilmann. “That’s something we, as an industry, should work toward.”

  • Nurturing a Developer-Centric Culture

    Nurturing a Developer-Centric Culture

    The tech world is constantly, rapidly changing and many tech companies are growing up. They are adding to their product portfolios, increasing the number of employees, servicing more users, expanding global reach and more. Typically, when an organization grows up, it doesn’t happen overnight. It takes a lot of hard work, onboarding new talent and a collaborative culture to bring business ideas to fruition. This growth often involves integrating new roles, methodologies and cultures to help a business succeed. One of these new cultures to emerge was DevOps.

    DevOps evolved from the need to take a new approach to how developers work. As technology advanced, developers sought new ways to approach their strategies and DevOps emerged as a way to explain this process. It stems from the concept of shortening the systems development life cycle and focusing on continuous delivery with high software quality. This approach empowers developers to perform end-to-end tasks—from development through testing to deployment and operations in production. Many now recognize that DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) and what eventually evolved is a culture that supports developers in the ability to fulfill the jobs at hand. 

    Built on the foundation of engineering culture and dedicated to empowering engineers, the DevOps culture is intertwined with the concept of continuous delivery and gives developers the responsibility and ability to deploy their products end-to-end. This means developers can move fast and work independently. While DevOps usually refers to the operational aspects of a software development life cycle, it can be beneficial to take it a step further. In a truly developer-centric culture, the engineer is involved in the entire life cycle of software from inception, product, QA all the way to operating it in production. For example, an engineer who is working on their product can progress quickly because they can operate as though they are within their own startup. Engineers can release a feature in a few minutes once they develop it. However, to thrive, this culture needs an entire organization’s support. 

    Being involved does not necessarily mean being fully responsible. Product managers, for example, are responsible for the product, but it’s essential that the engineers are involved in the product definition. This goes for all aspects of the product development life cycle, where engineers need to be involved in everything.

    There are effective ways leadership can support a developer-centric culture. The more this culture is embraced, the more successful a company’s and the industry’s engineers will be. There are a number of ways organizations can effectively support DevOps and build and sustain a developer-centric culture.

    1. Understand developer-centric. Without understanding what DevOps is, it’s hard to nurture its growth. It’s important to keep in mind that it’s a concept of empowering developers to seamlessly work through the SDLC. Many view DevOps as a role or a job description with a specific set of responsibilities, but it’s much bigger than that. It’s a culture. 
    2. Set guidelines, not rules. Developer-centric cannot and will not fit into a box. Most companies create checklists of to-do’s for processes but those ultimately fail. Instead, companies should focus on creating guidelines to encourage creativity and critical thinking so engineers can effectively plan, assess and reflect on every portion of their contribution to the final product and the process. It’s key to have engineers that are proud of their work and proud of what they’re working towards.
    3. Nurture engineers to take ownership and responsibility. Involve engineers at every step of the product life cycle, starting from product inception. C-level leadership and other managers need to trust the team to think proactively and execute effectively. The team was hired with a purpose; don’t micromanage and accept that some developers might do things differently than others—there’s not necessarily only one “right way.”
    4. Foster a collaborative environment. Collaboration between engineers—as well as between engineers and other departments—can spark creativity and solutions to problems or create new products entirely. Furthermore, hearing and respecting different viewpoints can inspire positive change throughout the entire organization. 
    5. Embrace mistakes and encourage continuous improvement. There’s no right or wrong way to do things, so it’s important to empower engineers to be creative and have the flexibility to make mistakes. Their mistakes can lead to insights and knowledge that might not have been discovered otherwise. Pain equals growth. Making mistakes and taking risks make individuals, departments and an organization better.
    6. Empower engineers both inside and outside the organization. As companies grow, their responsibility to the tech community grows, too. The term “empowering engineers” should be seen as a responsibility both inside and outside an organization. The stronger and more empowered engineers are, the stronger and more successful the industry will be as a whole.

    In conclusion, as companies grow up, it’s important to be fluid with the roles and cultures that morph to accomplish goals and objectives. Developer-centric is an example of when culture evolves to accommodate and tackle a new demand within a business. If you think of a process of software development at an assembly line, we take the assembly line and make it a circle so that developers that write the software are responsible for the whole life cycle from writing it to operating it. It’s a dev-centric culture. Now that dev-centric is here, it needs to be nurtured and supported by leadership, both inside and outside the company to thrive.

  • How DevSecOps Teams Can Level Up

    How DevSecOps Teams Can Level Up

    In 2019, I wrote a post detailing the traits of DevSecOps—the practice can be defined as the process of security automation in which IT and security are more de-siloed. DevSecOps introduces a more intentional culture wherein security-by-design principles are baked into the software development process early on. All in all, the aim is to have security enable development, not stall IT and slow down the SDLC.

    So, years later, how is DevSecOps doing? Has it achieved this ideal? Well, I recently met with Jeff Williams, CTO and co-founder of Contrast Security, for insights into the state of modern DevSecOps. According to Williams, most large companies still have real problems with application security and software dependency providence is constantly in question. We’ve recently seen this reality rear its ugly head amid exploits in frameworks like Log4j and Spring4Shell.

    Large organizations are likely carrying tens of thousands of vulnerabilities in their backlog. Yet, as consumers, we happily trust software for our critical applications without knowing what lurks behind it. “The industry has a real transparency problem,” said Williams. And as applications are getting more interconnected, they are getting more complicated and they’re getting more critical, Williams added. “These three Cs—connected, complicated and critical—make security harder.” These conditions are culminating in what he called “a perfect storm.”

    6 Ways DevSecOps Teams Should Respond

    So, how should DevSecOps teams respond to the seemingly endless barrage of new vulnerabilities and attacks? Williams shared some general ways teams can increase their security posture.

    1. Practice Security in Sunshine

    It’s easy to point fingers when something goes wrong, especially if it’s a serious vulnerability or attack. Instead, Williams encouraged teams to practice what he calls “security in sunshine.” This is an attitude that gives more transparency to security issues internally. Embracing a culture of blameless retrospectives can ensure employees are comfortable bringing up issues within their team.

    Security in sunshine can be adopted in an external-facing way as well. Williams likened it to how, in product manufacturing, it’s standard practice to share a bill of materials (BOM) with trade partners. We may see similar labeling standards emerge for software in the form of software bills of materials (SBOMs) so that external consumers are better aware of dependencies and potential threats, Williams suggested.

    Cybersecurity awareness certainly takes a communal effort that requires transparent communication. We see this realized daily in bug bounty programs, CVE reports and fixes to open source software. Bringing potential threats into the light of day is necessary to squash vulnerabilities before they are exploited.

    2. Translate High-level Requirements

    Security guidelines issued by bodies such as NIST and ISO are essential to keep in mind. Implementing the concepts these guidelines recommend, such as the principle of least privilege, multifactor authentication and zero-trust architecture, are considered best practices by most security professionals. However, these high-level requirements don’t often translate down to the developer on the ground floor. “The developer needs those requirements translated down four levels to specific technologies they’re working with,” said Williams.

    A programmer needs more realistic advice on how these guidelines affect, say, Spring Boot applications or how they should configure permissions in AWS. According to Williams, teams must interpret these abstract recommendations with more concrete annotations that meet the nuances of the technology stack they’re working in. The same process is required to help developers create projects compliant with data regulations, as it’s difficult to take this high-level advice into practice. Translating these requirements into more readable terms is an excellent way to de-silo security and development teams.

    3. Shift Smart

    In recent years, there’s been a lot of talk about shift left. The idea is that to reduce security threats later on, organizations need a tighter grasp on security earlier in the software development life cycle. Shifting security left is often enabled with tools that hold code accountable for potential threats using automated analysis.

    However, Williams sees this as an area where organizations need to be careful. Not all security tools are developer-friendly and might introduce inefficiencies at scale. Instead of shifting left, he advocates for “shifting smart” to introduce security at junctures where it’s most efficient. “You don’t want to shift all security left—you want to shift right too,” explained Williams. “Spread it out over the whole life cycle.”

    4. Avoid Added Steps

    There’s more than one way to bake a cake. Similarly, there’s more than one way to cook up a great software application. As such, most organizations are dealing with multiple tools, making it harder to apply security consistently across all stacks.

    Security should be catered to the specific tooling and processes being used, Williams explained. But that requires answer certain questions like where is a software development team in their journey? Are they waterfall or Agile? How does each CI/CD pipeline behave?

    Obviously, there are many unique factors to consider. Ideally, tooling should be flexible enough to attach itself to existing infrastructure, Williams said, instead of adding additional steps to an already sprawling tooling ecosystem.

    5. Take Security Seriously

    And, of course, there’s the cultural element. “It’s 2022, and companies still don’t take security seriously—they need to change,” said Williams. “It doesn’t matter how they get there—that they get there matters most.”

    Admittedly, cultural change is a slow evolution and the best way to advance will be to add practices and technologies progressively over time. Thus, Williams recommended iteratively inserting pieces, measuring outcomes and proving value along each step of the journey.

    6. Update Outdated Tools

    WhiteHat Security found the average time it took to fix critical vulnerabilities in the spring of 2021 was 205 days. But such a long timeline is at odds with the pace of new threats and the need to patch them quickly.

    The industry is changing the way they do AppSec, said Williams. Traditional DevSecOps security tools, he said, such as static analysis tools, dynamic analysis tools and web application firewalls, are outdated and less accurate compared to newer technologies like interactive application security testing (IAST) and runtime application self protection (RASP). Accuracy, speed and scalability will be important characteristics for security automation tools that don’t require additional human intervention or produce too many false positives.

    DevSecOps Is Still Maturing

    A healthier DevSecOps practice aims to decrease the “vulnerability escape rate,” as Williams called it. Hopefully, by providing instant feedback on designs, engineers will learn not to repeat the same mistakes, thus decreasing the number of vulnerabilities they introduce.

    In summary, DevSecOps is still maturing. Looking to the future, a stronger DevSecOps approach will require a more open attitude to mitigate threats. It also requires practical guidance as not all top-down guidelines translate well into the active development environment. Applications will require proper code hygiene, and the software supply chain itself must be protected, too, in addition to conducting active monitoring of production environments.