devopsy.kinsta.cloud

Category: DevOps Practice

  • Best of 2021 – Seven Reasons You Shouldn’t Hire a DevOps Engineer

    Best of 2021 – Seven Reasons You Shouldn’t Hire a DevOps Engineer

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

    DevOps is a culture, not a title. Therefore, companies should follow DevOps principles, rather than hiring one savant to fix an entire organization’s delivery model.

    I recently spoke with Uri Zaidenwerg, DevOps lead at Replix, to understand the current state of DevOps. As more robust DevOps tools emerge and practices proliferate across organizations, developers are now better equipped to own their applications end to end, including deployment, security and even cloud costs.

    Extracting DevOps from the development cycle could defeat the purpose of de-siloing development and operations. Below, we’ll outline some reasons why you should focus on building a holistic culture instead of filling a DevOps engineer role.

    1. DevOps Is a Culture, Not a Role

    The first reason is also the most encompassing — DevOps is not a title; it is a culture. DevOps functions best as a mindset adopted across IT. Instead of hiring a dedicated role, all “developers should be doing operations,” said Zaidenwerg.

    This means giving developers better visibility into DevOps KPIs, such as deployment frequency, deployment time, change failure rate, time to detection and availability, which we’ll explain in detail below.

    2. Developers Know Their Application Code Best

    Developers know their code better than anyone else. Diagnosing errors in an unfamiliar environment is tricky, and only programmers truly comprehend the ins and outs of their own code. If armed with DevOps skills, they could address problems much more efficiently than external eyes.

    Zaidenwerg worked as a DevOps systems administrator, and described “what it’s like to have to monitor availability of an application that you did not code or build.” It’s difficult; simultaneously diagnosing multiple applications that you don’t know intimately is also quite challenging, he explained.

    If you are unable to link errors to application processes quickly, it could hurt availability and SLAs. Instead, encouraging developers to diagnose issues could reduce time to remediation because they have more context, noted Zaidenwerg.

    3. Developers See the Surrounding Environment

    In addition to understanding how individual applications function, developers also have unique perspective into the surrounding environment — they realize the intricate network of dependencies and interconnections that make up a microservices system.

    To see what’s going on, you really need to know how to code. “DevOps engineers need to be software developers,” said Zaidenwerg. Handing off DevOps tasks to an administrator who doesn’t have coding knowledge can severely limit their ability. They will not be able to dig into the code to address real issues or make pull requests confidently.

    4. Separating Roles Keeps Ops in a Silo

    Relegating DevOps responsibilities to a centralized team goes against a fundamental principle: de-siloing departments. “DevOps was invented to make that gap smaller,” said Zaidenwerg. Having a separate role would thus appear to contradict one of the fundamental tenets of the methodology.

    “The point of a DevOps practice is that developer teams are empowered to control their own operations, not that you have specialists who know how to script operations,” said Tom Marsh, principal developer at Novartis, on Quora.

    5. One DevOps Engineer Can’t Fight a Flood

    As it stands, there are aren’t enough DevOps engineers to go around. According to answers on Quora, the ratio of DevOps engineers to developers tends to stand between 1:10 to 1:12. Zaidenwerg said he’s seen worse — from 5:50 to 6:120. Instead, he said, “Zero to zero is the optimal number.”

    One DevOps engineer against a tidal wave of requests and application deployment pipelines is just not sustainable. “Can you imagine the amount of features and code that has been written?” asked Zaidenwerg. “The amount of fires they need to put out is huge.” And what happens when that single DevOps engineer goes on vacation? To avoid delays, he encourages developers to own their CI/CD process from end to end.

    6. What Happens When DevOps Engineers Automate Their Job Away?

    Another creed of DevOps and SRE practices is to introduce automation – with the ultimate goal being to automate their job away. But, if this were actually to occur, what happens to the DevOps engineer? Do they sit back and rake in the dividends of some upfront work for years afterward? It would make more sense to have programmers introduce automation into their workflows.

    7. K8s + Other DevOps Tooling Empowers Developers

    Powerful DevOps tools like Kubernetes, ELK stack and cloud infrastructure solutions now make it far more realistic to delegate more responsibility to the programmer themself. Democratizing “as-a-service” solutions for monitoring, load balancing or storage enables everyone to “share the burden of the DevOps work,” said Zaidenwerg.

    Many organizations have begun to treat Kubernetes as a source of truth. Zaidenwerg wholeheartedly encourages this practice. “Everything should be managed on K8s, from K8s,” he said. “Try and think of K8s as your lowest layer.” Standardizing microservices around K8s helps retain platform-agnosticism for multi-cloud, he added.

    How to Get There? Track DevOps KPIs

    So, if we aren’t delegating DevOps tasks to a DevOps engineer, how can we encourage developers to embrace DevOps principles? To Zaidenwerg, the answer boils down to how we define success. Instead of gauging success using traditional development output metrics such as productivity, scrum or number of tasks completed, we need a culture that measures developer work using DevOps key performance indicators (KPIs).

    There are many DevOps KPIs to consider. Some could be:

    • Deployment frequency: How often do you commit?
    • Deployment time: How long does it take from committing to the live environment?
    • Automation: How automated is the build process?
    • Availability: Is the program globally available and highly performant? What is the latency and uptime?
    • Monitoring: Are you proactively monitoring and fixing issues in live environments?
    • Optimizations: Is the application cost-effective? Can it be more efficient? Are there idle resources running?
    • Policy as code: Are security policies automated as code? “Security needs to be written in code … if it’s done manually, you’re f**ked,” Zaidenberg said, bluntly.
    • DRP: Is the application resilient? What is the disaster recovery plan (DRP)?

    Of the above KPIs, optimization stands out, as rising cloud costs are an ever-present hurdle these days. Zaidenwerg encouraged developers to track cloud environment expenses. When you have a daily graph of spending, you can use this visibility to “create supporting systems to automatically take idle resources down,” he said. Others have described this as BizDevSecOps.

    Encouraging DevOps Culture

    Our cheeky headline is not meant to devalue those with DevOps in their title — on the contrary — hiring someone with this rare experience could greatly assist organizations in introducing DevOps principles. They could act as a model to help cultivate this culture.

    In addition to tracking KPIs, Zaidenwerg recommended a top-down approach to spread DevOps principles. The methodology must be sanctioned and led by the CTO, architect or tech lead, depending on the company’s size. A DevOps culture is especially paramount for SaaS or IaaS companies, whose architecture must be more than error-proof —  “It must succeed every single time,” Zaidenwerg stated.

    Disseminating modern cloud best practices is also critical for building a DevOps culture. When you transition from hardware to the cloud, you often encounter similar tech (load balancers, firewalls, availability zones, etc.), yet with different names and implementation processes for each function, complicated by nuances between cloud service providers (CSPs). All this will require “translating on-premises best practices to cloud best practices,” described Zaidenwerg.

    Another significant issue arises from the fact that DevOps isn’t really taught in college-level computer science courses. Looking to the future, Zaidenwerg (and myself) hope to see more emphasis within the education system. Instilling a DevOps mindset early on would better prepare developers for more real-world settings encompassing deployment, availability and security-as-code.

    Whose House Is It?

    Zaidenwerg likens a software application to someone’s house. The homeowner knows every detail — where the utensils are, how to work the shower nozzle, what day trash is picked up, etc. Invite a stranger into a new house, and they will be at a loss.

    Similarly, inviting external Ops to manage a foreign infrastructure will put them at a loss. “If you let someone else deal with infrastructure, then you have two parties and no one is fully aware,” Zaidenwerg said.

    To summarize — DevOps is a culture, not a role. Treating DevOps as a role, instead of as a practice, could defeat the purpose and cause siloed, slower-moving teams. Instead, tracking KPIs and empowering developers with DevOps tools could help them keep their house in order.

    Of course, this is an evolving practice, and each organization will have its own understanding of what it means to implement DevOps. Now, do you still think it warrants the title? Please let us know in the comments below!

  • Rails 7 FTW | WFH is SOP | 586M Passwords Dumped

    Rails 7 FTW | WFH is SOP | 586M Passwords Dumped

    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: Ruby on Rails 7.0 is go, working from home is still de rigueur, and HIBP gets far, far bigger.

    DHH is Excited

    First up this week: Ruby on Rails version 7.0 is now in production. It promises less bloat, better security and even more developer efficiency.

    Analysis: Last chance for greatness

    Talk to devs about Ruby on Rails and you’ll hear a wide range of opinion—all the way from “obsolete memory hog” to “productivity secret weapon.” But its important promise seems to be to encourage devs to use better design patterns.

    Paul Krill: Ruby on Rails 7 rejiggers JavaScript support

    Ruby on Rails 7, the latest version of the web application framework, is now available as a production release. … It gives developers a “no-Node” approach to front-end development while still providing access to NPM packages and modern JavaScript.
    …
    Most Rails applications will not require Node.js, given the new defaults. … Other improvements:
    …
    Encrypted attributes have been added to Active Record, enabling applications to offer at-work encryption in addition to traditional at-rest and in-transit. … With asynchronous query loading, two unrelated queries can be run concurrently. … The Spring application preloader is no longer on by default, as faster computers have made it unnecessary.


    Let’s hear from Rails creator David Heinemeier Hansson—AKA DHH:

    Seven is … the culmination of years of progress on five different fronts at once. … The part that really excites me … is how much closer it brings us to the ideal of The One Person Framework. A toolkit so powerful that it allows a single individual to create modern applications upon which [to] build a competitive business.
    …
    It’s been well over twenty years for me now, and a big release like this still makes me giddy. … What a glorious time to be working in web development.


    What a whatnow? Here’s bb_matt:

    I don’t pretend … it’s a “glorious time to be working in web development,” except for one important aspect: … Experienced programmers coming over from software development and starting to make amends [with] strong typing, robust CI/CD, a focus on TDD, a focus on domain modeling.
    …
    99% is still total **** though—but then again, so is most software.

    Home Working Ain’t Gone Away

    A month ago, my long-suffering editor permitted me to write, “WTH? We Wanna WFH.” And survey after survey says tech workers work better at home. After the last 21 months, there’s simply no denying it.

    Analysis: Genie out of bottle—no going back

    If you’re under the misapprehension that DevOps is somehow “special” and your workers will be glad to return—think again. Find a way to make it work, or work will stop—and your business will die.

    Steven J. Vaughan-Nichols: How to lure employees back to the office? You can’t. Not now. Not ever.

    Months have gone by, and the great resignation keeps rolling along. … People don’t want to catch COVID-19 [but] bosses still think they can force skilled workers to return to offices. … That’s not going to happen.
    …
    The problem? Many executives and owners haven’t gotten the clue yet. [But] any doubts you may have about people not doing a good job unless you’re looking over their shoulders should have vanished by now. … The monthly academic WFH research.com survey has found almost six out of 10 workers reported being more productive working from home. … In the Dice State of Remote Work report … 53% of technologists listed greater productivity as one of the main benefits.
    …
    It’s simple: It works better for them and for your company. … Anyone who’s been paying attention … must agree. You can either go along with the flow, or you can fight it and first lose your staffers and then your company


    So what do DevOps managers think? One of them is kozikow:

    100% remote is not great either. … When there was a long period of 100% remote during Covid, there were some issues. … We developed a policy that Mondays are required, Wednesday are encouraged, rest is work from home. … It was shared decision of the team.
    …
    I think that most people who are strongly against hybrid work just have to live in a miserable place like SF. … It’s unfortunate that so many software companies are in the Bay Area.


    But you couldn’t pay some people enough to go back—people such as this Anonymous Coward:

    No way in hell they’d ever be willing to pay me … to come back into an office. … No having to go out in ****ed up weather, no fighting traffic and … dangerous drivers, plus I get all that commuting time back.
    …
    And I don’t have to put up with Linda cooking fish in the microwave.

    Have I Been Pwned? There’s a 38% Higher Chance

    This week saw a huge bump in the size of Troy Hunt’s already-massive database of stolen credentials. In case you’ve not seen it, HaveIBeenPwned.com is an amazing free service that lets apps securely check a user’s password isn’t already used elsewhere on a compromised site.

    Analysis: Build the API into your auth flow ASAP

    The UK’s equivalent to the FBI has donated a huge trove of credentials—after deduping, it’s added more than 225 million new passwords to the database. Frankly, if you still allow your users to rely on any of the 847 million passwords in HIBP, it would be negligent.

    Simon Sharwood: National Crime Agency finds 225 million previously unexposed passwords

    Troy Hunt, of Have I Been Pwned (HIBP) fame, yesterday announced … the NCA shared 585,570,857 [creds] with HIBP, and Hunt said 225,665,425 … he hasn’t seen before in the 613 million credentials HIBP already stored. [HIBP] lets anyone conduct a secure search of stolen passwords to check if their credentials have been exposed.
    …
    The NCA’s statement to Hunt did not reveal the source of the password trove [but said they] “were able to identify a huge amount of … passwords in a compromised cloud storage facility. … It became clear that these credentials were an accumulation of breached datasets known and unknown.”
    …
    [The] release brings the total Pwned Passwords count to 847,223,402, a 38 percent increase.


    How’s this relevant to DevOps? Troy Hunt explains:

    In the last month, there were 1,260,000,000 occasions where a service somewhere checked a password against … HIBP’s Pwned Password API. … There are all sorts of amazing Pwned Passwords use cases out there. For example … checking their customers’ passwords on every registration, login or password change to see if it’s previously been breached.
    …
    The UK’s National Crime Agency has done some wonderful work over the years to combat cybercrime. … Today’s release is about turning on the firehose of new passwords and making them immediately available to everyone for free. Having this open to the community, owned by the community and supported by the FBI and NCA is an enormously pleasing result.


    Time for a metaphorical thought experiment. LenKagetsu obliges:

    You were told by a reliable source that an unknown person … posted a high-res image of … your house key … on the internet. Would you change the locks?

    The Moral of the Story: Never switch horses in midstream


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: David Emrich (via Unsplash)

  • Best of 2021 – 7 Popular Open Source CI/CD Tools

    Best of 2021 – 7 Popular Open Source CI/CD Tools

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

    DevOps is a software development strategy that incorporates agile practices for fast, efficient product creation and release. It focuses on integration of development and operations teams, continuous integration/continuous delivery (CI/CD) and automation of tasks and processes.

    Typically, DevOps teams use pipelines to streamline and standardize processes. DevOps pipelines are toolchains that teams can use to automate tasks and provide visibility into the software development life cycle. In this article, we’ll cover seven popular open source CI/CD tools.

    How DevOps Will Change in the Near Future

    Although DevOps has been around for just over a decade, it has continued to evolve. New DevOps technologies and changing infrastructure have caused teams to adapt and technology advancements that will continue to drive change. Below are a few of the ways you can expect DevOps to evolve in 2021 and beyond.

    AI and Data Science

    Artificial intelligence (AI) and machine learning have significant potential to improve current DevOps processes. Teams can use AI to identify inefficiencies in pipelines, optimize testing or evaluate user needs. Increasing amounts of data about environments, customers, markets and individual habits can all be applied to increase productivity and, ultimately, revenues.

    Serverless Architectures

    Serverless platforms, such as the AWS serverless ecosystem, including AWS Lambda and Fargate and the Azure serverless platform, including Azure Functions and Azure App Service, are becoming increasingly popular. These platforms enable DevOps teams to focus on just their code and eliminate many other variables, such as concern for host operating systems. These architectures provide scalability, deployment speeds, and user experiences that are difficult to match. This value will further secure FaaS in the coming years.

    Cloud-Native

    The growth of cloud-native applications has both driven and been driven by widespread adoption of cloud services. The containers and microservices that make up many cloud applications are used in many pipeline deployments and environments. Efficiently developing cloud-native applications require agility and automation that are difficult to meet without DevOps strategies.

    For the above reasons, DevOps has become almost synonymous with cloud-native. As cloud-native technologies change, tooling and processes adapt, as well. Additionally, since cloud growth isn’t slowing down, you can expect that DevOps will continue to focus on and refine cloud-native development.

    DevSecOps

    When developing applications in an automated CI/CD pipeline, security cannot be an afterthought. Especially in complex microservices architectures, security must be built in from the planning and development stages. Everyone must be aware of security requirements – developers, DevOps engineers and infrastructure teams.

    Transitioning to a DevSecOps paradigm requires a culture change, but also a new technology stack. Shifting security left requires tight integration of application security tooling into the development life cycle, and implementation of cloud security solutions that can help gain visibility, and apply automated security controls, to complex cloud environments.

    Which CI/CD Tools will You Use in 2021 and Beyond?

    As technologies change, so does tooling. While you can continue to use the same tools you started with, you should at least consider if other tools can increase your efficiency. Below are a few popular, open source tools you might want to integrate.

    Argo CD

    Argo CD is a CI/CD tool for Kubernetes development. It is an open source project which is currently in the incubation status at the Cloud Native Computing Foundation (CNCF). It uses Git repositories to store the state of Kubernetes applications, monitors applications and can resync clusters to the desired state, as represented in the git configuration.

    This innovative approach also allows you to store multiple desired states of a Kubernetes application, using branches, tags, or by pinning manifest versions using a Git commit. This provides a flexible environment for managing Kubernetes configurations during the development process.

    CircleCI

    CircleCI is an open source CI/CD tool. It includes features for job orchestration, resource configuration, caching, debugging, security and dashboard reports. CircleCI integrates with a variety of tools, including GitHub, Heroku, Slack and Docker.

    CircleCI is available in three tiers, one of which is free. You can use it in the cloud or on-premises with Linux, Mac or Windows machines.

    GitHub Actions

    GitHub Actions are a recently released open source tooling feature you can use to automate workflows. It enables you to build, test and deploy code directly from GitHub. You can base your automation on any GitHub events, including push or issue creation.

    GitHub actions include features for matrix workflows, hosted runners for all major operating systems, built-in secrets storage and live log reviews. It supports all common programming languages.

    GitHub actions includes hosted runtime environments that are free to use for the first 2000 minutes of use per month. If you need more time for testing, you can purchase time by the minute or in bulk. You can use GitHub actions by including them in your YAML files.

    GoCD

    GoCD is an open source build tool that lets you build CI/CD development pipelines. At its core, it is a continuous integration (CI) server, which lets you work with complex release workflows. It goes beyond classic CI to let you construct a full continuous delivery (CD) pipeline, all the way from automated and secure deployment to production.

    GoCD defines pipelines using code checked into source control – this infrastructure-as-code (IaC) approach lets you test, manage and reuse pipelines across multiple projects. Pipelines can be represented by JSON or YAML templates.

    Another feature of GoCD is the ability to run pipelines both sequentially and in parallel, with configurable dependencies. You can view entire workflows from development to production and track a feature from initial commit to production deployment, using value stream mapping.

    GoCD is extremely flexible, providing an ecosystem of plugins and the tool also allows you to develop and contribute your own.

    Gradle

    Gradle is an open source build automation tool that has been around for about a decade. It continues to be well-adopted and supported. Although it is not a new tool, it can be a good alternative if you’re looking to replace Maven as your build management solution. Gradle is more extensible and faster than Maven, and can be used for native development of C/C++ applications.

    Gradle includes features for incremental builds, build caching and parallel execution. It supports a variety of languages and platforms, including Java, Scala, Android and C/C++. You can integrate Gradle with a range of tools, including Eclipse, IntelliJ and Jenkins.

    You can use Gradle on-premises or with a virtual machine in the cloud. Gradle is free to use; however, if you want enterprise support or training, you need to pay an additional fee.

    Helm

    Helm is an open source Kubernetes package manager. You can use it to define, install and upgrade Kubernetes-orchestrated applications. Helm includes a wide range of pre-built charts (sets of distributable Kubernetes resources) that you can use to deploy services faster and more easily. You can use Helm on Linux, Mac and Windows devices.

    Jenkins X

    Jenkins X is an updated version of the well-known Jenkins. It builds on the existing features of Jenkins with capabilities tailored to Kubernetes and Docker workflows. It includes features for pre-built pipelines, integrated GitOps support, automatically generated preview environments and feedback integration.

    Jenkins X integrates with Tekton, Prow, Helm, Knative and Skaffold. You can use it on Linux, Mac or Windows machines.

    CI/CD and Automation Go Hand-in-Hand

    Agile teams need automation tooling, especially when creating and working with CI/CD pipelines. DevOps environments are dynamic, built for fluid workflows and constant change. Automation helps DevOps teams maintain a high level of visibility and reduce time spent on repetitive tasks. When adding AI and data science into the mix, DevOps teams gain the ability to make data-driven decisions, in addition to automated alerts and response.

  • Best of 2021 – Programming Languages: Choose Wisely?

    Best of 2021 – Programming Languages: Choose Wisely?

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

    We’ve got decades of experience in programming and language adoption under our belt at this point, and there are a few things we can say definitively that developers in general (and DevOps engineers specifically) should be aware of.

    First, it doesn’t matter as much as you think. It really doesn’t. Most developers don’t choose programming languages based on important things like optimization or general applicability. They choose a language based on ease of use, availability of third-party libraries and simplification of things like UI. Open source version availability helps, but only insofar as it spawns more third-party libraries. So, use the language that works best for the project, and don’t get too hung up on whether or not it’s the newest shiny one.

    Second, the changes in use and adoption that matter–the top five to 10 languages that make up the vast majority of all professional programming activity–don’t happen overnight. Both JavaScript and Python are considered “rapid ascent” in terms of uptake when they took off … but both were around for years before that spike in adoption occurred. So, learning any of the top few languages is a far better long-term investment than learning the hottest new language.

    Third, those top languages actually don’t change much. They were written to fulfill a need, and that doesn’t change much over time. Indeed, the only language I can think of that has fundamentally changed in its lifetime is C++, which seems to want to keep up with the times rather than keep serving its original niche. Python? Java? Still pretty much the same as when they became popular back in the day. And that’s a good thing. But that means if you want to try something new and engaging, you need to look to up-and-coming languages. At the time of this writing, specialist languages like R and Kafka are having their day, and that’s a good thing. After all, we know that different applications have different needs and different platforms have different needs–and have been trying to address that second one forever, currently with languages like Flutter. All of these will offer new ways of doing things, which is good exposure.

    Fourth, (though we briefly toyed with eliminating this one) organizations do determine the pool of available languages. Frankly, allowing each team to build a separate architecture was never a good idea from a long-term maintenance point of view … but a fairly large number of organizations played with the idea and learned the lessons about technical debt all over again. Now we’re back to “We use these languages, pick one,” which is better than “We’re an X shop,” and offers maintainability over time without burning a ton of man-hours.

    And finally, you can do anything with those languages your organization makes available. I’ve seen object-oriented assembler, I’ve seen entire websites served in C; the list goes on. The language you choose makes certain things easier or harder, but if you need to get it done, you’ll either get an exception to the language list, or you’ll figure out how to get it done with what’s available. But you can … But as my father used to love to say, “Just because you can, doesn’t mean you should.” He had nothing to do with programming and as little as possible to do with computers, but his logic still applies perfectly.

    So, grab an approved language, and crank out solutions. Just keep driving it home; you’re rocking it. Don’t stop, and don’t worry too much about which language you’re using, just focus on the language and do what needs doing–like you’ve done all along.  And spin us up even more cool apps.

     

  • Red Hat Adds Service to Customize RHEL Images

    Red Hat Adds Service to Customize RHEL Images

    Red Hat this week announced a public beta of an Image Builder service that streamlines the process of building customized instances of the Red Hat Enterprise Linux (RHEL) operating system.

    Scott Herold, director of product management for RHEL at Red Hat, said the Image Builder service enables an IT team to define a “gold” template for each target deployment environment that only contains the RHEL code required. Initially, Image Builder is configured to default to build a minimal, recommended RHEL server image for Amazon EC2, Microsoft Azure and Google Cloud Platform (GCP) cloud services.

    Future updates to the service will add support for VMware vSphere platforms as well as downloadable images and installation media for physical servers, customized filesystem layouts and versions 9.0, 8.5, 8.4 and 7.9 of RHEL. The service itself is accessed via the Red Hat Hybrid Cloud Console that is currently being made available in beta.

    Herold said building or installing operating systems is often a slow, tedious and error-prone process that needs to be manually performed in a slightly different way for each platform. Each physical server or edge computing platform requires different configurations and workflows. As a result, the chances mistakes will be made is high; Image Builder can greatly reduce the possibility of mistakes because there is no guesswork required, noted Herold.

    IT teams can also opt to include additional content from Red Hat in those builds to further streamline deployment processes, noted Herold. Those images can then be automatically registered with Red Hat to ensure future updates are received.

    The ability to customize those images also serves to reduce the overall size of the codebase that needs to be secured, added Herold. At a time when there is increased focus on software supply chains in the wake of a series of high-profile security breaches, many IT teams are revisiting their software deployment processes, he noted.

    Ultimately, Herold said Red Hat is moving toward providing IT teams with a more cloud-like experience regardless of where they deploy Red Hat’s curated open source software. The goal is to reduce as much friction as possible so that IT teams can more easily manage infrastructure at scale, he added.

    One way or another, the entiree software deployment process is becoming more automated. Much of the drudgery that has historically made it challenging to deploy and manage IT platforms at scale can be traced back to manual processes created when organizations ran a much smaller number of applications in on-premises IT environments. As IT teams increasingly deploy more applications in the cloud and at the network edge, it’s become more apparent that manual legacy processes won’t scale—especially when it’s already challenging to hire and retain IT personnel.

    It’s not clear how quickly IT teams will modernize software deployment processes using automated DevOps processes. Simple inertia is often a powerful force to overcome; however, most IT professionals can easily find something more compelling to do with their time that doesn’t involve using manually customizing operating system images.

  • Bridging the AppSec and DevOps Disconnect

    Bridging the AppSec and DevOps Disconnect

    Research estimates that cybercrime is going to cost the world $10.5 trillion annually by 2025, so it is no surprise that cybersecurity has become a top priority for business leaders. 

    Today, security teams are striving to harden their systems against cyberattacks and improve their resilience through more employee security training, incident response programs and the implementation of technology to monitor and detect threats. 

    Many organizations are also adopting a shift left security strategy, where security is being addressed earlier in the application development life cycle. These organizations are realizing that finding security issues in their software after it’s released is much riskier and more costly. After all, the longer a bug is in the wild, the longer an attacker has to find and exploit it. By implementing a shift left security strategy, the window of opportunity for an attacker decreases or can be completely removed if a security issue is addressed in the development stages, while also offering organizations significant security benefits and cost savings. 

    Shifting left is a security testing strategy where DevOps and security teams work in tandem to identify and address vulnerabilities during early development stages. This process significantly improves security as it means vulnerabilities are identified and mitigated before they are introduced to the enterprise environment.

    However, one of the biggest challenges organizations face when adopting a shift left security strategy (DevSecOps) is encouraging security teams and DevOps teams to work together.

    Encouraging AppSec and DevOps Collaboration

    Until recently, DevOps teams and AppSec teams were completely siloed. DevOps teams worked on accelerating the speed at which applications are released into the enterprise; application security teams only got involved in the later stages. However, this process has caused security concerns, particularly as more organizations move to agile development. 

    When security teams eventually got their hands on new applications and updates, security flaws were inevitably found that caused delays and friction with DevOps teams. 

    However, as organizations begin to embrace DevSecOps and shift left strategies, these two previously siloed teams are being forced to work together more closely. So, how can the friction be reduced and the disconnect bridged?

    Culturally, some ingrained attitudes and behaviors challenge the success of any DevSecOps efforts. Security teams have seen DevOps processes accelerate the speed at which software is delivered, but without security considerations, while DevOps teams experienced security slowing down processes and giving inconsistent results and feedback on security issues. Each party has their own manager to please; their own set of metrics that they’re measured against and a priority list as long as their arms already. Both teams follow different processes and, crucially, use different tools. DevOps can’t get around the security tool complexity and lack of integration with their existing toolset and security teams have no control over the CI pipeline to best implement security assurance.

    One of the best ways to overcome this friction is through better technology, process and culture that enables collaboration between teams. First, DevOps teams do care about security, but it might be lower on their priority list. Security teams must understand that DevOps teams care about code, quality and efficiency. They are not security experts and just because an organization is shifting left doesn’t mean they need to become one. Instead, organizations should implement tools for DevOps where security checks can be easily embedded.

    So, what can organizations do to improve the collaboration between AppSec and DevOps teams to achieve DevSecOps?

    DevSecOps is a culture and it requires a shift in thinking. Security teams and DevOps teams need to understand each other’s priorities and understand that by working together they are improving the overall security of the organization and decreasing the risk of cyberattacks. Does the DevOps team understand the potential risks a vulnerability could have on the organization overall? If not, security teams need to educate them.  

    Security automation tools offer great support when organizations are moving to DevSecOps, as they allow bugs and vulnerabilities to be flagged automatically as applications are being developed. This will allow them to be addressed before services go live; however, because they generate frequent alerts, this could add to DevOps’ already busy workloads. By deploying tools which can be synced with CI/CD pipelines and provide custom advisories so DevOps teams can address bugs themselves without having to ask AppSec teams, this can significantly speed up the process, reduce friction and ease workloads.

  • Hasura Adds Engine to Transform REST APIs to GraphQL

    Hasura Adds Engine to Transform REST APIs to GraphQL

    Hasura today unveiled a Data Hub repository for integrating application programming interfaces (APIs). The repository includes a connector that makes it easier for IT organizations to convert REST APIs into ones based on the GraphQL specification.

    Tanmai Gopal, Hasura CEO, said the connector eliminates the need to write custom code to connect existing REST endpoints to a GraphQL API using an update to the transformation engine developed by Hasura. Instead, the model for the GraphQL API is automatically overlayed on top of the REST API endpoint, explained Gopal.

    Originally developed by Facebook, GraphQL has emerged as a popular alternative to REST APIs because it enables developers to retrieve data at a more granular level, which results in improved performance. Hasura provides an instance of a GraphQL engine the company has developed around a project that is now hosted by the GraphQL Foundation, an arm of the Linux Foundation. GraphQL provides a complete description of the data made available via an API and is organized in terms of types and fields rather than traditional endpoints. In addition to clarifying what data is available via that API, developers can employ types to avoid writing manual parsing code.

    Hasura claims its engine has been downloaded more than 400 million times since its introduction in 2018. It automates the repetitive work involved in mapping models to APIs by providing common access patterns for pagination, filtering, joining, setting up authorization rules and optimizing performance. Hasura also provides APIs that are able to connect to multiple services and data sources, embed domain-specific authorization logic and provide additional layers of security.

    Hasura is now also adding a way to create identity-specific authorization policies for any GraphQL service or data source, enforcing security by limiting the models and fields of the GraphQL APIs in a way that eliminates the need for IT teams to cobble together disparate libraries and frameworks, said Gopal.

    In addition, Hasura is adding support for Google Cloud to Hasura Cloud in beta, a managed API integration service the company already provides via the Amazon Web Services (AWS) cloud. Support for the Microsoft Azure cloud will be forthcoming in 2022, added Gopal.

    It’s not clear the degree to which organizations are looking to replace existing REST APIs with ones based on GraphQL. However, Gopal noted there are plenty of instances where organizations need to overlay a GraphQL API on top of a REST API that they may not own. For example, a software-as-a-service (SaaS) platform that currently exposes a REST API may not have any plans to support GraphQL, he said.

    There’s no doubt the number of GraphQL APIs being employed in the enterprise is about to dramatically increase. The challenge now is finding a way to manage them alongside the previous generations of APIs that remain. The trouble is that many of those APIs were created by developers that may not have documented the APIs they created or, in some cases, never informed DevOps teams that they existed in the first place.

  • When, How and Why to Build a Developer Relations Team

    When, How and Why to Build a Developer Relations Team

    The developer role is changing. More and more often they are being rightfully viewed as key stakeholders who aid in setting company direction in this product-led world that we live in. For many technology vendors, earning the trust of developers is critical to their short-term and long-term success, but this presents a challenge. Developers have more than a full plate of work and traditional marketing tactics can fail to gain their attention. A new, more authentic approach was needed. This has led to the emergence of developer relations (DevRel), a term that can mean a lot of different things to different people.

    I view the role of DevRel as being responsible for creating good mutual relationships between a technology company, its product and external developers. Mature DevRel programs typically sit at the intersection of the marketing, engineering and product teams, as it is common to have developers in each of those groups. As such, DevRel teams consist of a unique group of people who fall somewhere in between the developer world and the marketing world. However, DevRel isn’t a one-size-fits-all idea. For early-stage startups, the makeup of a DevRel team tends to be more organic.

    When Should an Early-Stage Company Build a DevRel Team?

    Creating a DevRel team too early can be a mistake for many early-stage companies. It can be exciting for an early-stage company to want to invest in DevRel from the get-go, but the truth is, putting together this team too early (and before knowing if the product is even a fit in the market) can be money wasted. Developers have long memories, and bringing a flawed or unfinished product to them could create long-term damage to your brand.

    You need to first prove your worth in the market and experience growth before investing in DevRel. This way, you can ensure that your hypothesis was correct and your products have proven value. Once you’ve proven your hypothesis and have tested your products thoroughly, the next step is establishing short-term and long-term goals for the DevRel team you want to create. Know your market and have a plan of execution ready.

    What Does an Early DevRel Team Look Like?

    In the early stages of Algolia, for example, our DevRel team wasn’t even a formal DevRel team. It was a blend of DevRel and customer support. Our first priority was to create the best possible developer experience (DX). We, as developers, took the initiative to interact with the market. We were personally engaging with people that signed up with the service to offer our help.

    When your customers are developers, they can find it frustrating to speak to those who don’t understand code; therefore, it can be helpful to embrace a developer-to-developer connection when handling one-on-one support. This is invaluable for helping understand customers’ pain points and iterate very quickly with regards to the product. Imagine hearing about a bug and being able to fix it near-real-time!

    The advice I would give to anyone starting an early DevRel team is that your first evangelists should always be your core developers—they know your product inside and out. However, make sure that your core developers are using your product—”Eat your own dog food!” This is a very good way to make sure that your core developers have empathy with external developers. In fact, even today we ask core developers to do support a couple of days per month. As we approached the 150-employee mark, only then did we create a fully dedicated DevRel team. It was only then that we could expand into specialized skill sets to push activities at a larger scale.

    How to Engage Your Own Developers to Be Evangelists

    Once a strong developer experience is established, DevRel should focus on maximizing inbound activity, not specifically revenue. This can be in the form of free users, trials, student interest, etc. It’s a long-term growth investment. Trying to treat DevRel as a sales strategy and having the goal of impacting revenue is a recipe for failure. You want the developers on your DevRel team to be authentic. They aren’t salespeople; they shouldn’t be salespeople and if they try to be salespeople, it won’t be authentic.

    Your developers don’t necessarily need to be overly social or extroverted to embrace DevRel, either—that’s a common myth. They can stay true to themselves and genuinely try to help in ways that play to their strengths. Providing content is a great example of this. Have developers complete documentation for the features they build. View documentation as a core part of the product. For too many people, documentation is an afterthought when, in fact, it is one of the most important aspects of a product. Documentation can then be used as a jumping-off point for other content—blogs, whitepapers, etc.

    That said, if your developers are genuinely interested in the more social aspects of DevRel, offer public speaking and training tools for them. Developers with these skills can become the face of the company on webinars and panel discussions, attend events on the company’s behalf and more.

    The best DevRel programs understand the developer community, what types of tech they are using and then go where developers are to make connections. DevRel should amplify what the developer community is doing by showcasing use cases and solutions to problems. It should give a voice to your community of users by being the glue between developers and product teams.

    Why Do Companies Need DevRel?

    The API economy is making the role of developers and DevRel even more important than it already was. The competition for the attention of developers is already fierce; it is only going to increase as more organizations recognize that developers need a seat at the table when strategic decisions are made.

    Many companies are going to view DevRel programs through the traditional marketing lens with big-budget bets made on general awareness that isn’t personalized. This is going to fail. Instead, companies that have an authentic and measurable DevRel program in place, built around making meaningful connections, will be the most successful. Early-stage companies that embrace this thinking will gain an edge on larger competitors that are stuck in the old school way of thinking. 

  • Log4j: Is There Such a Thing as ‘Too Much’ Open Source?

    Log4j: Is There Such a Thing as ‘Too Much’ Open Source?

    The Log4j vulnerability got me thinking: Is there such a thing as too much open source?

    Before anyone immediately fires off a flaming email, rage tweet or scathing blog post, hear me out for a moment. If you know me, you know that I am an open source fanatic. I’ve been asked many times, “Should we use open source software and, if so, how much?” My response was (and still is) that open source software is a massive source of innovation and I can promise you, whether or not you use it, know that your competitors certainly are!

    I could go on and on extolling the virtues of open source and how it enabled the cloud, reshaped software architectures, created new product categories and gave us valuable tools like telemetry and increased visibility into cloud-native apps, infrastructure and beyond.

    When I first heard about the Log4j vulnerability on December 9, like many others, I quickly informed the tech leaders, engineers and SREs in my network about the serious potential risks such a zero-day vulnerability in the widely-used Log4j tool represented. In one way—probably the only way—the Log4j exploit shared a very important characteristic with the SolarWinds supply chain attack of late 2020: The widespread distribution and ubiquitous use of the software across applications, systems and organizations. Arguably, Log4j is used much more widely.

    This similarity raised questions I hadn’t fully considered in the context of such widely used software. Can we use too much open source software? Is Log4j too prevalent in its use and, therefore, a single point of failure? How bad would the Log4j situation be if a fix wasn’t immediately available or if one wasn’t forthcoming?

    The answer I kept coming back to is a resounding ‘no’. I still don’t think there’s such a thing as using too much (insert any open source project name) software. Log4j—and so many other open source software projects—are massively beneficial to us, and we virtually couldn’t function without these systems, tools and solutions in today’s age of ubiquitous software.

    What the current Log4j vulnerability, recent software supply chain attacks and other cybersecurity incidents with widespread impact highlight is our need to quickly respond to security incidents and take remediation steps anywhere they are found in the software stack. And that includes open source software. High-impact security vulnerabilities can occur anywhere across the numerous software stacks and services we use, though they have even greater impact when they occur in widely-used infrastructure, reusable components and microservices.

    In a world of infrastructure-as-code (IaC), it’s no longer a matter of patching a particular set of routers or servers. Unfortunately, much of the software stack is not containerized or built using smaller, easily replaceable containers and microservices—at least not yet. Our mindset and processes going forward from this incident must change, and we have to be prepared to respond to and remediate vulnerabilities both horizontally and vertically across the software stack. In certain circumstances, we have to do this on a large scale.

    As is common with active open source projects, Log4j contributors responded quickly with a readily available fix. The real answer to my original question above is that few are as prepared to respond to an important security vulnerability as those incredible, hard-working, active and engaged open source software developers.

  • The Graph Donates $48M to Advance GraphQL Platforms

    The Graph Donates $48M to Advance GraphQL Platforms

    The Graph, a provider of indexing and query tools based on the GraphQL language designed for blockchain platforms, today announced it has given $48 million to The Guild, a group of developers advancing an open source application programming interface (API) platform to further development of GraphQL-based technologies.

    Administered via The Graph Foundation, a nonprofit consortium that oversees the development of an open source graph database dubbed ONgDB, the agreement also calls for members of The Guild to contribute to the development of indexing and query tools being advanced by The Graph over the next four years.

    Eva Beylin, director of The Graph Foundation, said the goal is to fund the development of projects that leverage GraphQL, an open source data query and manipulation language for application programming interfaces (APIs) originally developed by Facebook, to create subgraphs used on blockchain platforms like Ethereum to index data in a way that is more accessible to developers.

    The open source community that is starting to evolve around blockchain platforms, also known as Web3, is now a major contributor to a range of GraphQL projects, noted Beylin. Those blockchain platforms are now being used to drive decentralized finance (DeFi) applications that do not rely on any single platform to process transactions. Those platforms are being employed by both startup and incumbent providers for financial services around the globe.

    It remains to be seen, however, how the GraphQL community will address security concerns. GraphQL APIs can easily suffer from broken object-level authentication issues just like any other API. The issue is a single GraphQL query could exfiltrate much more information than a typical API request. If the GraphQL provider does not have granular authorization checks for each particular method and resource, a GraphQL endpoint could become a major vulnerability.

    Cybercriminals also tend to launch brute-force attacks against APIs. With REST APIs, that malicious behavior is easier to catch with standard web application firewalls (WAFs) because it’s easier to notice hundreds of peculiar malformed requests. However, with GraphQL, a brute-force attack is harder to detect. It’s easier to limit this type of nefarious traffic with REST APIs by assigning access parameters to each resource and handling authorization checks one at a time.

    It’s not likely GraphQL APIs will replace REST APIs overnight. However, as the backend platforms for managing GraphQL APIs become more robust, the number of these APIs being used in a production environment by DevOps teams will dramatically increase—assuming there are no objections from cybersecurity teams.

    In the meantime, the open source community is clearly starting to rally around GraphQL, which should result in innovations applicable across a wide range of use cases. The challenge now is not only determining which type of API to employ and when, but also deciding whether any existing legacy APIs need to be replaced. One way or the other, however, the managing and securing of APIs—like it or not—is only going to become that much more challenging in 2022.