devopsy.kinsta.cloud

Category: DevOps Practice

  • Building Higher-Quality Software With Open Source CD

    Building Higher-Quality Software With Open Source CD

    Business is accelerating, and experience– for customers, partners and employees–is everything. This means nearly all applications need to be enhanced with new features, security updates and bug fixes on ever-shorter cycles. But isn’t rushing new code into production, especially in cloud environments, a recipe for mistakes, security vulnerabilities and user frustration? Not if the right approach is taken.

    Continuous delivery (CD) enables development teams to rapidly and regularly deploy software updates into production systems without jeopardizing user experience or creating security risks. Battle-tested open source CD orchestration solutions, including Spinnaker and Argo, provide a cost-effective way to deliver secure, high-quality software at massive scale to multi-cloud and Kubernetes environments.

    What is Continuous Delivery (CD)?

    Most software development teams suffer from quality issues related to outages, tracking down bugs and security vulnerabilities, complex upgrades, release rollbacks and more. According to a 2020 report by the Consortium for Information & Software Quality™ (CISQ™), software quality suffers as companies rush to add more value at greater speeds. In 2020, the cost to companies was $2.08 trillion in the U.S. alone.

    CD relies on a framework of stakeholder collaboration, process automation and continual and rigorous risk assessment and feedback to ensure a smooth, high-volume flow of high-quality code is deployed to production systems. When done right, CD reduces software development risks by enabling development teams to deploy changes such as new features, configurations, bug fixes and even experiments into production safely, quickly and sustainably. It also reduces costs associated with software deployments, failed releases and customer frustration and attrition.

    With effective CD workflows in place, development teams gain confidence and are more productive, delivering better products faster while eliminating the frustration of missed release dates, management wrath and the blame game associated with software bugs and vulnerabilities making it into production.

    Open Source CD Solutions

    Prior to the rise of open source CD solutions, companies often relied on point automation using scripts. These could improve efficiency a bit, but when companies moved from the monolithic architecture of a mainframe or on-premises servers to a microservices-based production environment, the scripts could not be easily adapted or scaled to cope with the more complex environment. This led to the formulation of continuous delivery orchestration solutions that could ensure code updates would flow to their destination in a repeatable, orderly manner.

    Two highly popular open source CD solutions have emerged, Spinnaker and Argo. Spinnaker was developed by Netflix and extended by Google, Microsoft and Pivotal. It was made available on GitHub in 2015. Spinnaker creates a “paved road” for application delivery, with guardrails to ensure only valid infrastructure and configurations reach production. It facilitates the creation of pipelines that represent a software delivery process. These pipelines can be triggered in a variety of ways, including manually, via a cron expression, at the completion of a Jenkins Job or other pipeline and other methods. Spinnaker also provides cluster management, as well as visibility into an application’s cloud footprint, letting users resize, delete, disable and even manually deploy new server groups using strategies like blue-green deployments.

    Argo CD, a container-native deployment engine for Kubernetes, supports CD pipelines, enabling the automated deployment of applications within Kubernetes. Introduced in 2018, Argo CD utilizes the Argo GitOps Engine, an open source library that implements core GitOps features. It allows users to manage, automate and audit the software deployment with Git as the source of truth. Features of Argo CD include drift detection, the analysis of the health of application resources and a real-time view of application activity.

    As open source software, both solutions offer all the benefits that the open source model offers, including low start-up costs, rapid and continual innovation and paid support when it becomes necessary.

    A CD Automation Success Story

    Symphony provides a cloud-based collaboration platform for financial institutions that are highly regulated and render services to millions of customers, so the solution must meet rigorous standards for security and regulatory compliance. The company wanted to enable a multi-tenant system to improve performance and reduce the cost of operations for each client. However, the existing software delivery system created bottlenecks in integration testing, long triage times and manual handovers of releases to site reliability engineering (SRE). The ever-growing number of delivery pipelines and software delivery environments also increased infrastructure costs and the burden on human resources, making it difficult to deliver features faster and ensure compliance at scale.

    Symphony determined it needed a completely new CD solution supporting infrastructure and software delivery workflows that they could retrofit into their existing platform. The solution needed to support infrastructure-as-code, pipeline-as-code and configuration-as-code, while providing visibility, auditability and faster approval processes. Symphony opted for a CD solution that harnessed the power of both Spinnaker and Argo to automate the entire end-to-end CD process, including pipelines for infrastructure, deployment, testing and promotion to production deployments. With the solution, Symphony was able to slash the time required to onboard new environments by 98%–just 10 minutes to get the infrastructure and platform ready for the client. This also allowed for fast and frequent changes.

    With automated CD in place, the company enjoyed significant cost optimization through automation. It was also able to increase security and compliance through automatic policy checks that continually enforced compliance across the stages of each pipeline–without compromising delivery speed.

    Getting Started

    As you review potential CD solutions, ensure they can deliver the required level of:

    • Ease of setup and configuration
    • Visibility and collaboration
    • DevOps tools integration and extensibility
    • Built-in deployment environment support
    • Security and governance
    • Workflow flexibility
    • Performance, uptime and scalability

    Get an Expert Assessment

    While the benefits of a CD solution are enormous, deploying one is not trivial. It pays to make good choices to get it right the first time. A professional assessment of your existing environment and processes can help you in several ways, including:

    • Exposing your current silos
    • Identifying the bottlenecks in your software delivery process that can be automated
    • Identifying productivity improvement opportunities for everyone involved in the delivery journey
    • Giving you the insights you need to make an informed decision about your CD solution.
    • Providing advice on best practices that can transcend the deployment process to the next level of efficiency and quality

    If your company requires the rapid delivery of secure, high-quality software releases, the time to deploy a continuous delivery solution is now.

  • GitHub Previews Free CI/CD Migration Tool Due in 2023

    GitHub Previews Free CI/CD Migration Tool Due in 2023

    At its GitHub Universe event, GitHub today unveiled a bevy of updates to its cloud service, including a forthcoming set of migration tools. The tools will automate migrations from legacy continuous integration/continuous delivery (CI/CD) platform to GitHub Actions.

    GitHub Actions Importer is already being used by a small group of enterprise IT organizations to migrate workflows and template the GitHub CI/CD platform.

    Damian Brady, senior manager for developer advocacy at GitHub, told conference attendees that these free tools will become more broadly available in 2023. GitHub Actions Importer will be distributed as a Docker container that manifests itself as an extension of the GitHub command line interface (CLI).

    One of the biggest challenges the company has faced in driving adoption of its platforms is that many DevOps teams don’t want to rebuild the templates and workflows they are already using on their existing CI/CD platform, he noted.

    Other GitHub Actions extensions include native integration with software development tools for building internet-of-things (IoT) applications and support for personal access tokens (PATs) that enable more granular control over permissions and repository access.

    Other security capabilities include expanded access to audit log events in the enterprise edition of GitHub, an ability for maintainers of open source repositories to privately share vulnerability reports and support for Ruby as one of the programming languages now supported by a CodeQL tool for discovering vulnerabilities.

    Additional extensions to existing services for developers also were previewed, including an ability to interact with the GitHub Copilot tool for automating code writing using voice commands. Dubbed “Hey, GitHub!” the tool is available as an experiment being advanced by the GitHub Next research team.

    Finally, the company previewed enhancements to code search-and-view capabilities in the Codespaces tool that will now be made available for free for up to 60 hours per month to developers.

    GitHub claims its CI/CD platform is now being used to process 10 million builds a day, most of which are employing code accessed via its repository. It’s not clear how that compares to other CI/CD platforms, but it’s apparent the GitHub Actions CI/CD platform has gained a significant amount of traction as GitHub continues to make a case for creating tighter integrations between its repository and CI/CD platform. GitHub is also clearly signaling it will spend a lot more time wooing organizations that already have a legacy CI/CD platform installed.

    In the meantime, the next era of DevOps has arrived as workloads become both more complex to build and deploy across highly distributed computing environments. Many of the CI/CD platforms that organizations deployed are now straining under the weight of multiple customizations and extensions that have been made over the years. Each DevOps teams will need to decide whether maintaining those platforms makes the most technical and economic sense or if they should migrate to a more modern platform.

    Regardless of what they decide, one thing that is certain is that DevOps teams won’t be getting larger, so the need to invest in higher levels of automation has become pressing.

  • Cribl Simplifies Telemetry Data Analytics

    Cribl Simplifies Telemetry Data Analytics

    Cribl today announced general availability of a search capability that makes it simpler to query observability data where it resides without having to first collect and centrally store it.

    Nick Heudecker, senior director for market strategy for Cribl, said Cribl Search makes it possible to analyze telemetry data at its point of origin or when it is stored in a low-cost object storage platform to minimize costs.

    As the volume of telemetry data being collected continues to grow, DevOps teams are struggling with ingesting it all. Cribl takes advantage of a platform it created to stream and normalize the collection of telemetry data. Cribl Search adds the ability to also query that data at the endpoint where it resides, said Heudecker.

    While observability has always been a core tenet of DevOps, achieving it has been a major challenge. In addition to deploying and managing agent software to instrument IT environments, there’s a significant amount of time and effort required to set up the pipelines necessary to transfer data to a platform for storage and analysis. The more data is collected, the greater storage costs become. Cribl is making a case for automating those tasks using a tier of software that abstracts data into a format that can be more easily collected and analyzed.

    In general, observability is emerging as the next logical evolution of continuous monitoring. Existing monitoring tools enable DevOps teams to track specific pre-defined metrics. Observability platforms are intended to make it easier to query telemetry data to discover the root cause of an issue that is not being tracked by a set of pre-defined metrics.

    It’s not clear yet whether IT organizations perceive observability to be an evolution of monitoring or a distinctly separate but complementary capability, but it’s apparent IT teams need a lot more context than they have historically been able to attain using legacy monitoring tools. Each platform used within an enterprise typically comes with its own monitoring tools that are used by the IT teams tasked with managing it. Whenever there is an issue, it’s not uncommon for DevOps teams to spend hours correlating data from multiple tools to ascertain the root cause of a problem. Observability platforms promise to reduce that time and effort by applying analytics to data collected from multiple platforms. The challenge is finding a way to efficiently collect all that data, which in the past has often required a data engineer to build a pipeline spanning multiple sources of telemetry data.

    One way or another, observability platforms should make it easier for DevOps teams to manage IT issues more proactively. The goal, as always, is to identify issues before they cause a major disruption. In that sense, it may be difficult to prove the ROI of deploying an observability platform. However, the best IT incident is always going to be the one that never happened or, at the very least, never escalated to a level of noticeable disruption.

  • OutSystems Acquires Ionic to Further Automate App Development

    OutSystems Acquires Ionic to Further Automate App Development

    OutSystems this week revealed it has acquired Ionic, a provider of an open source framework that provides developers with a higher level of abstraction for building and deploying mobile and desktop applications.

    OutSystems CTO Patrick Jean said Ionic will accelerate the company’s ongoing efforts to extend the reach of its platform for building low-code applications without developers having to worry about, for example, the screen size of the device an application is deployed on it because the framework automatically right-sizes it. Ionic, in effect, will provide an extension to the platform that OutSystems already uses to automate the building and deployment of low-code applications, he added.

    In addition to its namesake user interface (UI) framework for building mobile applications that can run on multiple platforms, the Ionic portfolio also includes a tool for natively deploying web applications, dubbed Capacitor, and a toolchain for building web component-based design systems, dubbed Stencil. Collectively, these tools are used today by more than five million developers.
    OutSystems plans to extend the capabilities of these tools to make it simpler to deploy applications on both mobile devices and desktop systems, said Jean. The overall goal is to reduce the cognitive load that developers currently carry when they need to build and deploy applications that run on multiple platforms, he added.

    That capability will prove critical as more individuals beyond professional developers become involved in building, deploying and updating applications, noted Jean. In fact, many of those developers are likely to be business people that only develop applications on a part-time basis, he added.

    The percentage of applications being built using low-code tools has increased dramatically. Professional developers have embraced these tools and platforms alongside so-called citizen developers that are using them to build applications, as well. As the backlog of applications that needs to be built steadily increases, low-code platforms have played a crucial role in enabling developers to keep pace with the demand for new applications.

    Less clear is the impact these low-code applications are having on DevOps workflows. On one hand, there are clearly more applications that need to be deployed than ever. At the same time, many of the DevOps and data modeling processes that once required, for example, a dedicated continuous integration/continuous delivery (CI/CD) platform are being embedded in the platforms provided by the vendors that create low-code tools.

    Regardless of how low-code applications are deployed, the one thing that is certain is the pace of digital business transformation is being greatly accelerated by these tools and platforms. DevOps teams will soon need to put guardrails in place that enable developers with a wide range of experience and skillsets to securely deploy and update applications.

    On the plus side, DevOps teams should also expect it to become easier to automate the delivery of low-code applications at levels of unprecedented scale. In fact, the issue going forward may not be whether IT can keep up with the needs of the business but whether the business can keep pace with the rate of innovation now being enabled.

  • SRE Survey Reveals Major Technical and Cultural Challenges

    SRE Survey Reveals Major Technical and Cultural Challenges

    Catchpoint, in partnership with Blameless, today published an annual survey of 559 site reliability engineers (SREs) that found 59% of respondents didn’t view tool sprawl to be a major concern. Another 40% said tool sprawl is a moderate (33%) to serious problem (8%).

    More than half of respondents said they build as much as 30% of the tools they use themselves, with more than half (54%) noting their organization tracks three or more different types of telemetry data to drive observability. The top three types of telemetry data collected are infrastructure (62%), application (58%) and network monitoring (55%) and, on average, the survey suggested the median toil level of SREs dropped 5% year-over-year.

    Just under half of respondents (46%) also noted they saw no or low value from artificial intelligence for IT operations (AIOps) compared to 30% that have seen moderate to high value. Another 25% are still unsure.

    Finally, the survey concluded that organizations that have adopted a “just culture”—where organizations ensure that incident reporting is not met with punitive measures—are 500% more likely to be Elite performers in terms of the DevOps Research and Assessment (DORA) metrics defined by Google.

    Leo Vasilou, director of product marketing for Catchpoint, said that the survey results provided some insights into the challenges SREs face as they strike a balance between trying to achieve DevOps goals and the fact that hiring has become more constrained during an economic downturn.

    That stress, however, has less to do with managing toolchains than it does ensuring that applications driving critical business processes are consistently available, he noted.

    SREs have emerged as a distinct DevOps function in recent years, focused almost exclusively on programmatically managing the dependencies that exist between a wide range of applications and the underlying infrastructure upon which they depend. Optimizing applications in the cloud-native era has become more challenging because the number of dependencies that exist between the microservices that make up a modern distributed computing environment continues to exponentially increase. In many cases, applications are continually added to IT environments without a commensurate increase in the overall size of the SRE team.

    Regardless of the economic climate, hiring and retaining SREs remains a challenge given the demand for IT professionals with those skills. Of course, there is no formal SRE certificate that is widely recognized so who qualifies to be an SRE tends to vary from one organization to the next. The one thing that is generally agreed upon is that SRE automate a wide range of tasks that would otherwise require multiple IT administrators to perform. Glassdoor also reports that, on average, an SRE makes north of about $125,000, which ranks among the highest salary level within any IT organization.

    Each organization, depending on their geographic region, would need to determine how many IT administrators they could replace if they hired an SRE. That doesn’t mean IT administrators that rely on a wide range of graphical tools to manage IT tasks are going away any time soon, but as DevOps continues to evolve, the dynamics between SRE and IT administrators also will continue to evolve.

  • Snowflake Makes Case for Building and Deploying Apps on Platform

    Snowflake Makes Case for Building and Deploying Apps on Platform

    During a Snowday 2022 event, Snowflake this week moved to make it simpler to build applications on top of its cloud platform for managing data in addition to enhancing the overall security of the platform.

    The company has made generally available Snowpark, a framework for building Java, Scala, SQL or Python applications. Snowflake also committed to making generally available in early 2023 an open source Streamlit framework for building Python applications that Snowflake acquired earlier this year.

    Snowflake also revealed it is adding observability tools to the platform to make it easier to build, test, debug, deploy and monitor data pipelines, including alerting tools (private preview), logging capabilities (private preview), event tracing (private preview), task graphs and history (public preview).

    Torsten Grabs, director of product management for Snowflake, said those capabilities will make it easier to alert DevOps teams to issues that might arise with applications deployed on the Snowflake platform.

    At the same time, Snowflake is also making it simpler to build data pipelines by making a Serverless Tasks capability generally available. In addition, the company is previewing a Schema Inference engine that makes it simpler to ingest data and a Dynamic Tables capability to declaratively manage data pipelines.

    Other capabilities being added to the platform include a public preview of a Query Acceleration Service to make additional compute resources available on demand. Snowflake has also improved query efficiency with join elimination in addition to providing search optimizations.

    There are also now cost optimization tools that enable IT teams to run a cost-benefit analysis of Snowflake services in addition to tools that make it easier to replicate data across multiple cloud computing environments running the Snowflake platform.

    IT teams can now also replicate Streams and Tasks via a capability in public preview that enables data pipelines to seamlessly work on secondary Snowflake accounts and configure failovers using a graphical tool that is available in private beta.

    Finally, Snowflake has also enhanced its cross-cloud Snowgrid Capability to make it easier to share both public and private listings of data in addition to applying tags to and searching masked data.

    The latest editions to the Snowflake platform come at a time when more organizations are starting to adopt DataOps best practices to manage data. Snowflake is now making a case for building and deploying applications on top of a platform that automates the management of the data pipelines used by applications to access data.

    It’s not clear to what degree the Snowflake platform will be employed to host applications, but the company is clearly betting the volume of data residing in its cloud platform will attract a wide range of application developers that, in turn, will need to be supported by DevOps teams.

    Of course, Snowflake is not the only provider of a data warehouse or data lake that has similar ambitions. Regardless of platform, however, the one thing that is clear is that a convergence of DevOps and DataOps workflows is now underway as IT organizations look to streamline the management of the massive amounts of data that now reside in the cloud.

  • Developer’s Guide to Fuzz Testing

    Developer’s Guide to Fuzz Testing

    Fuzz testing continues to grow in popularity among developers within the open source community. Google’s open source security (OSS) team recently reported finding more than 40,000 bugs in 650 open source projects through the use of fuzz testing. But if you have no clue what fuzz testing is (yet), don’t worry. You’ve come to the right place.

    What is Fuzz Testing?

    Fuzz testing is a dynamic testing method for finding bugs and security issues in software. During a fuzz test, a program or a function under test gets executed with invalid, unexpected or random inputs to uncover unlikely or unexpected edge cases. 

    Value of Fuzzing for DevSecOps 

    As we know, DevSecOps extends the approaches of DevOps and Agile by adding suitable security testing methods alongside every phase of the software development life cycle (SDLC), creating a dynamic and continuous testing process. 

    Part of that testing process can and should involve fuzzing to detect security and stability issues at all phases of the SDLC and empower developers to ship software quickly and securely. For example, to prevent regressions from going live by running automated fuzz tests on every code change.

    Especially in the automotive industry and complex embedded projects, where a lot of untrusted and complicated data gets processed, fuzzing brings excellent benefits to DevSecOps. Indeed, developers can apply fuzzing similar to unit testing to automatically test their security-critical modules for potential vulnerabilities. But with fuzzing on an integration level, they can also cover all the complicated and dangerous edge cases that can occur in the interaction between different modules. 

    Fuzz Testing Benefits

    Fuzzing code generates thousands of automated test cases in a second, with the fuzzer receiving in-depth feedback on code coverage and the program states reached to simulate the interaction of different modules during the execution of the source code. The fuzzer can adapt and mute its inputs based on runtime feedback in the following iterations to maximize code coverage. Some of the benefits are:

    1. (Almost) no false positives: If you find a crash, fuzzing provides you with the error source and the malicious input that caused the issue. So, you can be sure that each finding is a real vulnerability.
    2. Debug reproducible findings: Modern fuzz testing tools will provide you with the input causing the issue, including the source of the error. With this, you already have a lot of helpful information to reproduce the bug and load it directly into the debugger. 
    3. Find issues in forgotten edge cases: Because fuzzing is executing a program with invalid or random input, it also uncovers unlikely and unexpected edge case errors that would not otherwise have been revealed.

    Who Uses Fuzz Testing?

    As cybersecurity regulations and standards continue to expand globally, more and more organizations are extending cybersecurity programs and running automated security testing before they ship software. Whole industries, especially those that involve advanced quality and security regulations, are setting standards for security testing that recommend fuzz testing, including automotive, aviation, finance, healthcare, telco and energy.

    Digging deeper into the automotive industry, for example, a variety of International Organization for Standardization (ISO) and other organizational standards now recommend fuzzing:

    Best Practices

    The most effective way to do security testing, fuzzing included, is to do so continuously. This means integrating fuzzing right into your CI/CD pipeline. Doing so creates quick feedback cycles so developers can fix security vulnerabilities before the code is shipped. Integrating fuzzing tools into code hosting systems like GitHub is also valuable. Doing so allows communication and alerts to be shared across your DevOps team as soon as a problem is uncovered, which helps to facilitate fixing vulnerabilities. 

    What Bugs Can I Find?

    While the practice remains relatively new, fuzzing has already discovered thousands of bugs across different use cases. Bug and vulnerability types discovered include:

    • Remote code executions
    • Injections, which can be triggered by untrusted inputs 
    • Memory leaks: Incorrect memory allocation 
    • Exposure of sensitive data: Accidental exposure of personal data
    • Functional bugs: Inputs that are not being responded to 

    and many more bugs, such as undefined behavior, uncaught exceptions and buffer overflow. Learn more.

    Getting Started

    You can try out an open source fuzzer, like Jazzer (for Java testing) or the CI Fuzz CLI (for C/C++ testing). When you’re comfortable with fuzzing and want to use this approach in more complex environments, enterprise solutions offer added features like API fuzzing, reporting and CI/CD integration. 

    So give it a shot and join the community of open source developers using fuzzing to quickly and securely ship their software. 

  • Developers Continue to Prefer Remote Work

    Developers Continue to Prefer Remote Work

    A survey found 83% of developers are working remotely more than half of the time, with more than three-quarters (76%) reporting they have maintained or increased the frequency of remote work in the last year. In fact, three in five respondents (62%) work remotely at least 90% of the time.

    The survey, published by Netlify, a provider of a platform for building the front end of Web applications using the Jamstack framework, polled 6,544 developers in the Jamstack community and found more than half (55%) would quit their jobs if forced to return to an office.

    It’s not clear how much remote work has become a de facto requirement for organizations to attract and retain developer talent, but it’s clear that, in the wake of the COVID-19 pandemic, the dynamic between developers and the organizations that employ them has completely changed.

    Netlify CEO Mathias Biilmann said regardless of industry, it’s apparent that DevOps teams are going to continue to need to make adjustments to foster collaboration across distributed teams. Senior managers will find it increasingly challenging to manage workflows across a workforce that is also witnessing a lot of turnover, he noted. A third of survey respondents (33%) reported having changed jobs in the last year. It’s not clear how much a lack of interaction in the office might be impacting innovation, but at a time when demand for developer talent far exceeds the available supply, organizations will need to adjust to what appears to have become a permanent new reality.

    At the same time, the Netlify survey noted the pace at which emerging technologies are being embraced continues to rapidly evolve—perhaps because of rather than in spite of remote work. For example, the survey found 70% of developers reported using a serverless computing framework in the last year. Nearly half (47%) are also experimenting with edge dynamic sites, the survey found. It’s clear that company culture, at least in terms of technology adoption, plays a large role in attracting developer talent.

    Overall, 96% of survey respondents noted that JavaScript is their primary choice of programming language, with 21% of developers now specifically using TypeScript to build applications. The React framework for building applications, meanwhile, is being used by 71% of developers, with 47% reporting they employed the Next.js version of that framework. Other React frameworks gaining traction include Vite (32%), Sveltekit (15%), Astro (11%), Remix (10%) and SolidJS (6%).

    However, emerging Web3 technologies have yet to gain traction. While 7% to 10% of developers have tried out technologies such as cryptocurrencies and NFTs, only 3% reported using these technologies regularly. A total of 42% of developers either didn’t know what Web3 was or didn’t care about it, while 31% felt negatively about it, the survey found.

    Ultimately, the primary reason organizations invest in DevOps is to increase developer productivity. The challenge is that, as developers embrace more tools and platforms for building applications, the process of deploying those applications becomes more challenging to manage effectively. One way to achieve that goal is to separate frontend and backend software development processes to enable developers to focus more on writing code rather than managing the arcane processes required to deploy it.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    ZipRecruiter.com

    Comcast
    New York City
    Lead Software Engineer – DevOps
    $190,950 to $225,278

    Indeed.com

    Divi Technologies
    Remote
    DevOps Engineer
    $140,000 to $155,000

    SimplyHired

    Perimeter 81
    New York City
    DevOps Engineer
    $130,000 to $175,000

    Dice.com

    OnDemand Group
    Minnetonka, MN.
    Senior DevOps Engineer
    $120,000+

    LinkedIn

    Gainwell Technologies
    Remote
    Senior DevOps Engineer
    $92,500 to $115,600

  • Introduction to SPIFFE/SPIRE

    Introduction to SPIFFE/SPIRE

    For a long time, people have been logging into the apps they use via passwords or password managers. And many open standards and identity providers on the market continue to evolve how users authenticate and authorize with websites and applications. The issue is that the same problem exists for software services—when applications talk to applications, how do we prove the credibility of service-to-service connections?

    Enter SPIFFE and SPIRE. SPIFFE is a specification for implementing identity for workloads, and SPIRE is the code that implements this specification in practice. Together, the projects create a standardized, secure way to identify software services and authenticate them. SPIFFE and SPIRE recently reached graduation status with the Cloud Native Computing Foundation (CNCF), solidifying the projects’ maturity as a top open-source standard mechanism to deliver cryptographic runtime identity for both cloud-native and legacy workloads.

    SPIFFE and SPIRE are already used across many major public deployments. Yet not all developers are familiar with their intricacies. Below, I’ll take a gander at both projects and how they operate to provide a bit more context. I also spoke with Evan Gilman, SPIFFE/SPIRE maintainer, to gather more insights on the history of the projects and their future goalposts.

    What is SPIFFE?

    The Secure Production Identity Framework For Everyone (SPIFFE) is a specification for workload identity. According to Gilman, the easiest way to think about SPIFFE is as a passport. Similar to how people are issued passports in a common shape with a barcode and standard information, SPIFFE dictates the standard methods to prove and validate the identity of a service. It’s like bringing the “Sign in with Google” experience to the software services themselves, he adds.

    There are three key components in SPIFFE. First, SPIFFE specifies that services shall identify themselves with what’s called a SPIFFE ID, which is defined as a URI in the format of spiffe://trust-domain-name/path. These IDs are then encoded into a SPIFFE Verifiable Identity Document or SVID. SVIDs aren’t so much a document type themselves — instead, they support either X.509 or JWT document types. Last but not least, SPIFFE specifies a workload API that issues and rotates these SVIDs, along with the keys needed to validate them.

    What is SPIRE?

    SPIRE is the code that implements the SPIFFE specification—you can think of it as a production-ready SPIFFE runtime environment. SPIRE, the “flagship SPIFFE implementation,” is a true end-to-end instantiation of SPIFFE that securely issues SVIDs, renews SVIDS and performs attestation, among other functions. If SPIFFE defines what a passport is, then SPIRE is the agency that issues the passports, said Gilman.

    The SPIRE agent runs on a node and exposes the workload API, which hooks into each workload. A workload, as defined by the SPIFFE documentation can be a web server, an instance of a MySQL database, a worker program or a web application composed of independently deployed systems. By communicating in this manner, SPIFFE/SPIRE can solve the issue of “secret zero,” which refers to the conundrum of proving the first credential to newfound systems.

    More Background on SPIFFE/SPIRE

    Joe Beda, a co-founder of Kubernetes, first proposed SPIFFE at GlueCon in 2016. At the time, Google was considering what internal technology it had that might prove helpful to the broader industry. It’s said that the technology that inspired SPIFFE/SPIRE can trace its roots to security and identity subsystems brought to Google from AT&T and Bell Labs.

    Nowadays, SPIFFE/SPIRE is actively maintained by many organizations, and we continue to see impressive production use cases. “SPIRE is deployed in some staggeringly large cases,” explained Gilman. SPIFFE/SPIRE adoption can be seen within GitHub, Netflix, Pinterest, Square, Transferwise, Uber and many other large technology companies. In terms of ownership, Gilman said that SPIRE is most used by platform engineers, infrastructure engineers or security engineers, depending on the organization’s roles.

    Future Outlook for SPIFFE and SPIRE

    SPIFFE/SPIRE appear to have the resources and backing to maintain a stable implementation, so the future looks bright for both projects. In terms of new features, in mid-2022, a first-class integration with SPIRE was merged into the Istio service mesh as a more flexible alternative to Istio’s built-in SPIFFE implementation. Another recent update is experimental support for SPIRE on Windows. Regarding future plans, SPIFFE/SPIRE maintainers will likely continue to iteratively improve the specification and implementation with frequent updates.