devopsy.kinsta.cloud

Category: Features

  • 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 serve our audience better.

    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:

    Dice.com

    APN Software Services
    San Jose, California
    Principle Engineering DevOps
    $190,000 to $200,000

    ZipRecruiter

    Craft Machine
    San Francisco, California
    Senior DevOps Engineer
    $160,000

    Monster.com

    Citibank North America
    Tampa, Florida
    App Dev Tech Lead Analyst
    $156,000 to $177,000

    Indeed.com

    Brighthouse Financial
    Remote
    Principal DevOps Engineer
    $133,000 to $168,000

    SimplyHired

    Hellebore Consulting Group
    Fairborn, Ohio
    Senior DevOps Engineer
    $125,000 to $185,000

  • Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

    Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

    Codenotary has extended the reach of its platform for automatically generating software bills of materials (SBOMs) to serverless computing platforms running software constructed using functions.

    Codenotary CTO Dennis Zimmer said because serverless apps are dynamically created, it’s not possible to generate SBOMs using traditional approaches. The TrueSBOM platform makes it possible to create an SBOM in real-time by adding one line to the source code of any application. The TrueSBOM for Serverless edition of the platform now extends that capability to the serverless computing frameworks made available in the cloud by Amazon Web Services (AWS), Microsoft and Google.

    That approach makes the SBOM a part of the application itself rather than a text file that is stored separately, he noted. Each time an application is updated or a scanner discovers a new vulnerability, a new SBOM is automatically generated, added Zimmer.

    Awareness of the need for SBOMs has skyrocketed since an executive order issued by the Biden administration made it clear that federal agencies would require them from software providers starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

    Most internal DevOps teams already have a good handle on what software components are used within the applications they deploy. The issue is that the organizations that use that software can’t easily verify what components are being used, noted Zimmer. That’s problematic because an organization may prohibit deployment of a specific software component because of a known vulnerability. TrueSBOM allows organizations that use an application to maintain control over their software environment regardless of what software artifacts are used to build closed or open source components, Zimmer added.

    It’s unclear how most organizations will operationalize SBOMs now that more of them are being created. Ideally, organizations should be able to approve only software with components that have been verified as secure.

    As SBOM mandates become more stringent, the number of application providers that are anxious to comply with rules for securing software supply chains should increase. The issue now is finding a way for both the developer and consumer of that software to streamline a verification process that, in its current form, is too cumbersome to manage effectively. As a result, many organizations are now putting together dedicated teams made up of cybersecurity professionals and software developers to manage SBOM processes, said Zimmer.

    Of course, there is a massive amount of code that has already been deployed that today doesn’t show up in an SBOM. While many emerging applications—created using artifacts such as functions and containers—are likely to be increasingly instrumented to dynamically generate an SBOM, the number of legacy applications that might need to be similarly instrumented is several orders of magnitude greater. As a consequence, the amount of effort required to generate SBOMs for every application in use might be greater than teams first anticipated.

  • Survey Surfaces Agile Development Challenges

    Survey Surfaces Agile Development Challenges

    A survey of 3,220 software development professionals published this week found that among the 80% of respondents that embraced Agile practices for building software, just under half are tracking on-time delivery (47%) and business objectives achieved (44%).

    The survey, conducted by Regina Corso Consulting on behalf of Digital.ai, a provider of a value stream management (VSM) platform. The survey also found a total of 19% of respondents were not sure what metrics were used to track software development progress.

    At the same time, 40% of respondents noted they are dissatisfied with Agile at their organization; a clash with company culture was listed as the leading cause (41%) of unsuccessful delivery. Half of respondents use a combination of Agile, waterfall and/or iterative processes, but 27% noted this combination of frameworks was a struggle for them.

    The survey also noted that just over a third of product and application owners (36%) that participated in the survey have adopted Agile.

    Derek Holt, general manager of Agile and DevOps at Digital.ai, said that percentage suggests that Agile principles are now being adopted beyond the engineering teams that construct software. As that appreciation for Agile principles continues to grow, the organizations these individuals work for also tend to start tracking value stream metrics, he added. That transition typically begins with a few pragmatic metrics before the organization matures enough to justify the adoption of a VSM platform, Holt noted.

    In time, however, that VSM platform not only helps organizations identify bottlenecks but also identifies potential quality issues and risks to the business, Holt added.

    Overall, the top three top Agile development priorities identified by respondents are to accelerate time-to-market (52%), delivery predictability (44%) and lower risk (31%). However, from a business perspective, the top three priorities are company goals (54%) and end customer satisfaction (43%) followed by time-to-deliver (35%).

    More than half (51%) of respondents, however, also noted that DevOps teams are not incorporating business feedback regularly. Well over half (58%) said the most valuable improvements to DevOps teams would be end-to-end visibility and traceability from business initiative through development, test and deployment to end users, while 55% said the ability to measure cycle time, wait time and bottlenecks would be an important improvement.

    Regarding Agile tools used, Scrum led the pack at 87%, followed by Kanban at 56% and Scrumban at 27%. The Scaled Agile Framework (SAFe) framework has been adopted by more than half of respondents (53%), while Scrum@Scale/Scrum of Scrums was adopted by 28% of respondents followed by Lean Management at 8%, according to survey respondents.

    The top benefit of Agile is increased collaboration (69%) followed by better alignment with the business (54%) and better work environment and increased visibility in the application development life cycle at 39% each.

    The debate over the merits of Agile frameworks, of course, remains fierce and no two organizations may ever have the same level of adoption. However, as the pressure to deliver quality software faster in the age of digital business transformation continues to mount, the more crucial it will become to align Agile and DevOps best practices.

  • Introduction to Flutter

    Introduction to Flutter

    Flutter is a development tool for creating cross-platform applications. Flutter was created by Google to help developers create frontends that run on almost any operating system, including Android, iOS, Mac, Linux, Windows desktop and the web.

    Ready to check it out? You’ll first need to install the Flutter software development kit (SDK).

    Installing Flutter

    To use the Flutter SDK, you need to have git installed on your computer; here are some tips for installing it based on your OS:

    • Windows: Download it here.
    • Mac: Although you can install Git manually, your best bet is to simply install Xcode, which includes Git; you’ll need XCode later.
    • Linux: In addition to Git, you’ll need several other tools listed here. If you’re using Ubuntu or Debian, you can get them all with this single command: sudo apt install git zip unzip curl xz-utils libglu1-mesa
    • ChromeOS: This option requires you to enable Linux on ChromeOS. Then you’ll want to install the same packages that I just listed for Linux.

    After the above prerequisites are met, you can download Flutter by going to this link.

    You can either download the SDK for your operating system or you can obtain it from GitHub. Only attempt the GitHub option if you’re familiar with cloning Git repositories.

    In this example, I’m going to download the Windows version by clicking the Windows link, which brings up the screen shown below. For Windows in particular, pay close attention to the warnings about where to install the SDK. (I like to have a folder called c:\dev where I put all my dev work, and under that a folder called c:\dev\tools. So the latter is the folder where I’ll put the SDK.)

    After the file is downloaded, extract it to a location such as c:\dev\tools.

    For Windows, Linux and ChromeOS, the next step is to update your path so that the system can find the tools found in the Flutter folder’s bin folder. (Mac users don’t need to do this step.) The Flutter installation docs are helpful here:

    • Windows: Make sure you use the full path, starting with the name of the folder you extracted the zip file into. For example, on my machine, that would be C:\dev\tools\flutter\bin, as shown in the image below. Then after you update the path, you’ll need to close and reopen your command-line shell (either Windows CMD or Powershell). For detailed instructions, go here.
    • Linux: Follow the instructions here.
    • ChromeOS: Follow the instructions here.

    Now test out the Flutter command to make sure it works by going to a folder outside of the Flutter’s bin folder and typing:

    flutter --version

    You should see a message such as this:

    Flutter 3.3.9 • channel stable • https://github.com/flutter/flutter.git
Framework • revision b8f7f1f986 (2 weeks ago) • 2022-11-23 06:43:51 +0900
Engine • revision 8f2221fbef
Tools • Dart 2.18.5 • DevTools 2.15.0

    This will tell you if the installation is possibly ready. If instead, you see a message that the command is not found, double-check that you have your path correct; that’s typically the most likely cause for that error.

    Now, why did I say ‘possibly’? Because Flutter itself can tell you if there are any other tools you’ll need by running this command:

    flutter doctor

    Here’s an example of what I saw when I ran it:

    This tells me I have some of the necessary tools installed, but not all:

    • Flutter itself, as well as all the tools that came with it
    • Android toolchain: I don’t have this one.
    • Chrome browser: You’ll need this for debugging web versions of your app.
    • Visual Studio: This is the full IDE from Microsoft; you’ll need it if you want to develop your app for Windows Desktop. You can use the free Community version. For that, go here and choose the free Community version.
    • Android Studio: I don’t have this one.
    • VS Code: This refers to Visual Studio Code, the free editor/IDE from Microsoft, which is not the same as Visual Studio. It’s a separate tool and neither is dependent on the other. Before you install it, read my notes below.

    Before installing anything else, you’ll want to decide what platforms you’ll be targeting. If you’re going to include Android in that list, you’ll need to download and install both the Android toolchain and Android Studio. In that case, you’ll be developing from within Android Studio.

    But if you’re not targeting Android, you do not need to install the Android toolchain or Android Studio. The official installation docs are a little vague on this point, so I tested it out myself. I was able to target Windows desktop and a browser without needing to install any of the Android tools.

    If you’re not targeting Android, then you’ll want to install VS Code to do your development from within. You can find it here.

    Building an App

    For this example, I’ll continue with Windows, and I’ll build a quick Windows desktop app.

    In a command shell, I’ll first create a folder in my c:\dev to hold my projects by typing these commands:

    cd c:\dev
md projects
cd projects

    I’m going to make a Flutter app called flutter_demo by typing the following. (Make sure you’re in the projects folder before typing this):

    flutter create flutter_demo

    Note that the name for your project must be in all lowercase letters, and it can contain underscores. So, for example, using uppercase letters results in an error:

    If I type this:

    flutter create FlutterDemo

    I see this:

    "FlutterDemo" is not a valid Dart package name.
See https://dart.dev/tools/pub/pubspec#name for more information.

    When done correctly, you’ll see output such as this:

    Creating project flutter_demo...
Running "flutter pub get" in flutter_demo... 1,186ms
Wrote 127 files.
All done!
In order to run your application, type:
$ cd flutter_demo
$ flutter run
Your application code is in flutter_demo\lib\main.dart.

    Before we open the code, let’s run it! First, go into the new folder flutter created:

    cd flutter_demo

    Then run it by typing:

    flutter run

    This command runs whatever Flutter application is in the current folder. In this case, that’s the app you just created.

    When you start it, it will ask for some choices. Because I don’t have Android or an emulator installed, I only see options for Windows Desktop and Chrome and Edge. (Edge is based on Chrome, so it works, as well.) Here’s what I see:

    Multiple devices found:
Windows (desktop) • windows • windows-x64 • Microsoft Windows [Version 10.0.19044.2130]
Chrome (web) • chrome • web-javascript • Google Chrome 107.0.5304.107
Edge (web) • edge • web-javascript • Microsoft Edge 106.0.1370.37
[1]: Windows (windows)
[2]: Chrome (chrome)
[3]: Edge (edge)
Please choose one (To quit, press "q/Q"):

    Press the option for Windows. This will build the Windows desktop version (which might take a minute or so) and launch it, resulting in a window that looks like this:

    This isn’t much, but there’s a sample in it where you can click the plus sign and see the number in the middle increment. That’s all.

    Now let’s try running the same app in Chrome. First, close the app window and press Arrow-Up or re-type:

    flutter run

    This time, choose the option for Chrome.

    Now Flutter builds a web-ready version that runs on Chrome, starts a local web server to host the app, launches Chrome and pushes a URL to Chrome to load the app from the local web server. Here’s the browser window:

    Notice that it looks virtually identical to the desktop version but is inside a browser this time.

    If you’re a web developer, I encourage you to right-click inside the browser app and select View Page Source. Notice there’s a line that loads a file called flutter.js, and there’s some JavaScript code that responds to the window’s Load event that calls into Flutter. You won’t be writing JavaScript code, but it’s always good to have at least some understanding of what your front end is doing!

    Adding to the Code

    Now let’s add just a bit to the sample code. For this, I’ll use VS Code. From within the app’s main folder (in my case, c:\dev\projects\flutter_demo) type

    code .

    (Make sure to include the dot after the word code; otherwise, VS Code will open in whatever folder it last ran.)

    Before delving into the code, you’ll want to install a special Flutter extension for VS Code. Click the gear in the lower left and click Extensions. In the box labeled Search Extensions in Marketplace, type flutter. (Don’t click Enter; just pause a moment and the search will begin.) Find the one called Flutter that has over five million downloads, as shown here:

    Click the Install button. The button will show “installing” while the extension is being downloaded and installed.

    After the extension is installed, VS Code will ask whether you want to use it with your current project. You might also see a message regarding updating the Dart extension, which came alongside Flutter. Click Yes for the Flutter one; click Get packages for the Dart one. (You can ignore the message about opening the settings file.)

    Now you have all several flutter tools available VS Code’s Extensions Palette. Press Ctrl+Shift+P to open the palette. Type flutter and you’ll see the full list.

    For now, however, let’s first just run the app. Click the Run menu, and then click Run Without Debugging. You’ll see the Windows app open again.

    Now go back to VS Code. Even if you’re not familiar with Dart, if you know other “curly bracket” languages such as C++, C#, Java, JavaScript and so on, you’ll probably be able to read the code. There’s a function called main() that starts the app, providing a class called MyApp. That class is farther down in the code. Look closely at all the comments. Read them carefully and learn from them. The MyApp class contains a build function that returns an object with a “home” member; that member is an instance of MyHomePage, which is also a class in this file. Continue studying that code, and you’ll see mentions of widgets and layouts. Look closely at the function called _incrementCounter and how it’s triggered later on through an onPressed event.

    Conclusion

    Play around with the code; try changing some of the string literals, for example, until you’re quite familiar with it. Then dive into the first demo provided by the Flutter folks at Google, which you can find here. Soon you’ll be up and running with your own Flutter app that you can run on any device!

  • Introduction to MACH Architecture

    Introduction to MACH Architecture

    In recent years, the need to construct end-to-end digital experiences has become increasingly important. But to deliver new features and services promptly, organizations must double down on agility and reusability. As part of this trend, applications have become increasingly modular, often constructed using pre-built microservices and integrating common SaaS to avoid reinventing the wheel.

    MACH is an architectural style that fits into these trends quite well. It stands for Microservices-based, API-first, Cloud-native, and Headless. The locus of the movement is The Mach Alliance, a group of API-first companies abiding by these principles. At the time of writing, MACH is gaining mindshare as more API-first companies enter the market and the appetite for cloud-native technology grows.

    I recently chatted with Gary Ballabio, VP of technology partnerships, Cloudinary, about the ongoing MACH trend. According to Ballabio, MACH delivers “best of breed” technologies that avoid the bloat of larger platforms. Yet, for software consumers, building in a MACH style will require stitching together individual components and orchestrating them effectively. Below, we’ll explore MACH and consider the benefits and drawbacks of utilizing tools that conform to this approach.

    What Is MACH?

    MACH is an emerging software architecture style adopted by a number of commerce and digital experience tools. To understand MACH a bit deeper, it’s necessary to understand the underlying concepts of microservices, API-first, cloud-native and headless. So, let’s first break apart these familiar terms:

    • Microservices: Unlike monolithic development, a microservices architecture organizes functionality into self-contained, specialized components. This improves reusability and allows for more frequent, targeted software updates.
    • API-first: API-first takes design-first one step further. It means putting the consumption model, the API, ahead of other concerns, like the application or UI. Web APIs have become ubiquitous for connecting a microservices ecosystem and exposing data and functionality to partners and public consumers.
    • Cloud-native: An umbrella term for projects purpose-built for the elasticity and scalability of the cloud.
    • Headless: Headless means separating the front end, or “head,” from the back end. By decoupling development this way, websites and apps are better equipped to cater to multiple platforms and devices.

    According to Ballabio, companies can leverage cloud-ready best-of-breed functionality by integrating tools that adopt MACH principles. Incorporating one single SaaS to fit a specialized need can also be considered an alternative to using large, comprehensive enterprise commerce suites like Salesforce, Adobe or SAP, said Ballabio.

    There are many examples of specialized SaaS services built in the MACH style. Some include Algolia for search and recommendations, Cloudinary for media management, Builder.io for mobile experiences, or Contentstack as a headless CMS. All these tools are members of The MACH Alliance, a group of over 70 vendors, partners, startups, systems integrators and other ambassadors dedicated to fostering the MACH approach. And although the emphasis has been on commerce and digital experiences, MACH is expanding beyond that scope to other areas.

    MACH technologies support a composable enterprise in which every component is pluggable, scalable, replaceable.

    Some readers may wonder, “How is this different than Jamstack (JavaScript, APIs and markdown)? In a way, MACH is similar to Jamstack, as both approaches aim for headless frontend experiences and a modular backend powered by APIs. But a key difference, said Ballabio, is that MACH doesn’t dictate the use of specific programming languages.

    Benefits and Drawbacks of MACH

    MACH combines many development trends we’re seeing in the software landscape. Digital applications are becoming more composable, cloud-first is rising, and headless models can deliver customization benefits. Yet, there are some potential drawbacks to introducing this style too. So, let’s weigh some of the positives and negatives of adopting MACH architecture.

    Benefits

    • Flexibility: The most significant benefit of MACH is the flexibility it offers, said Ballabio. “There’s value in being able to choose the services you want to use based on your own unique requirements.” Looping in a specific API-first tool for something like e-commerce, payments, CMS or email can enable a lot of customization.
    • Reduced waste: This can create less waste, too, as you create a leaner footprint by acquiring only what you need for each project, and freemium models enable consumers to pay for only what they use. This is helpful when you want a single component but don’t require the bells and whistles of a more holistic platform.
    • Best-of-breed: Niche API-first products are focused on doing one thing really well, and this particular focus can improve quality and agility. It also releases engineers from being at the whim of an extensive product’s development life cycle.
    • Developer-first: Lastly, most digital experiences share common functionalities that developers shouldn’t have to reinvent. MACH supports being developer-first, says Ballabio, which is an asset to companies investing in developer experience.

    Drawbacks

    • Increased maintenance: Consuming many third-party cloud services will inevitably bring new maintenance hurdles. These include tracking, monitoring and securing all integration points. It also requires responding to new version updates.
    • Stitching together: Naturally, when you add a cloud-based abstraction layer to the services you consume, the onus is on the consumer to then to stitch them together to make components talk to one another.
    • Startup costs: Due to the coordination between services, initial costs and engineering time could be more than implementing a holistic suite, admitted Ballabio. “But you get more long-term benefits,” he said.
    • Assistance may be required: Those unaccustomed to microservices development and API integration may need help. This may require the support of systems integrators or middleware to orchestrate connections.
    • Lack of standards: MACH is more of a general architecture rather than a standard specification. Thus, the precise technologies under the hood and the specific behaviors may differ from service to service.

    Future of MACH

    A recent MACH Alliance study found 79% of tech leaders plan to invest more in MACH technologies in the next year. Although the style has been primarily trending in Europe, Ballabio predicts the U.S. will soon pick it up. The MACH Alliance presents and advocates for an open and best-of-breed enterprise technology ecosystem.

    Along with the rise of composable architecture, the MACH approach is gaining interest among cloud-native leaders who see the advantage of assembling applications using pre-fabricated building blocks. MACH is especially a good fit for greenfield development, where the slate is clean to integrate new technology.

    MACH represents a new category of companies that are growing together. Ballabio remarks that he feels part of a movement, part of an industry—and, arguably, this movement can potentially disrupt larger commerce ecosystems.

    But although MACH gives a name to a face, most techies still aren’t aware of the acronym. While the concept may, for now, live in the domain of vendor-speak, Ballabio foresees it becoming a more common parlance for consumers and end developers.

  • Dead Downtown: It’s YOUR Fault | Pentagon’s FOUR Cloud Vendors | Apple Adds MORE Price Flexibility

    Dead Downtown: It’s YOUR Fault | Pentagon’s FOUR Cloud Vendors | Apple Adds MORE Price Flexibility

    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: Home working is ripping the heart out of cities, the DoD’s bizarre cloud strategy, and Apple adds a $10,000 app price option. (more…)

  • Chainguard Adds Private Edition of Code Signing Platform

    Chainguard Adds Private Edition of Code Signing Platform

    Chainguard today added a private preview of a Chainguard Enforce Signing service, enabled by the open source Sigstore project, that allows developers to generate digital signatures for software artifacts using identities and one-time-use keys they create themselves.

    Kim Lewandowski, head of product for Chainguard, said Chainguard Enforce Signing provides an alternative to relying on a public service to generate those digital signatures. It also allows organizations to bring their own key and certificate so that key usage can be monitored and audited per compliance and privacy requirements.

    In addition, Chainguard added a library of policies that administrators can deploy directly from the Chainguard Enforce web console to their environments.

    The Chainguard Enforce Signing feature is based on Sigstore, an open source project that provides a protocol to simplify cryptographic certificate generation by removing the need to manage keys. At its core, Sigstore creates a set of short-lived ephemeral keys with a trust root based on an auditable public log. Because it creates an immutable log, everyone participating in the software development process, including auditors, can now transparently track the chain of custody for any software artifact.

    Key management, key compromise/revocation and the distribution of public keys and artifact digests are challenging to manage. Developers are also required to determine which keys to trust in addition to learning how to sign them when different platforms are employed.

    Chainguard’s alternative is enabling organizations to host their own immutable log rather than relying on a public service to eliminate the need to manage keys, noted Lewandowski.

    Historically, code signing platforms have been problematic because they were susceptible to tampering. Cybercriminals can, for example, swap out digests to gain access to compromised credentials. Digests and public keys are also often distributed across vulnerable websites susceptible to hacks or inadvertently stored on a public Git repository.

    Code signing—along with software bills of materials (SBOMs)—is one of two technological advances that will improve the security of software supply chains. SBOMs, of course, are going to be considered more reliable when the software components they describe are signed by the developers that created them.

    Less clear is whether the signing of code will improve its overall quality. Most developers take pride in their code, but the overall quality of the software deployed in production environments could always be improved. Developers may decide to review the code they contribute to a build more intently if they know they will be required to sign it.

    In the meantime, it’s only a matter of time before organizations require that developers sign code before it is deployed in a production environment. In addition to increasing confidence in the quality of the code employed, those signatures make it simpler to track down the development team that created code whenever there is an issue that needs to be resolved. After all, the most challenging issue organizations encounter when trying to update software is not so much the creation of a patch as much as it is identifying who should create that patch based on their knowledge of the software components used.

  • Report: Impact of Bad Software on US Economy Reaches $2.41 Trillion

    Report: Impact of Bad Software on US Economy Reaches $2.41 Trillion

    A report published this week by Synopsys in collaboration with the Consortium for Information & Software Quality (CISQ) estimated that software quality issues might adversely impact the U.S. economy to the tune of $2.41 trillion in 2022.

    Cybercrime losses due to a rising number of software vulnerabilities alone are on track to increase 42% in 2022 after growing 64% in 2021, according to the report.

    More troubling still, the number of failures due to weaknesses in open source software components accelerated by an alarming 650% from 2020 to 2021.

    Finally, the report estimated that overall technical debt would increase to $1.52 trillion in 2022.

    Dr. Anita D’Amico, vice president of cross-portfolio solutions and strategy for Synopsys Software Integrity Group, said that despite these issues, there is cause for optimism. The silver lining is that more organizations are aware of software supply chain issues in the wake of a series of high-profile breaches.

    As more responsibility for application security also is shifted further left toward developers, the number of vulnerabilities being introduced into applications should also begin to decline steadily, she added. In addition, more organizations will soon be following the lead of the federal government by requiring software bills of materials (SBOMs) that will make it simpler to remediate vulnerabilities once they are discovered, noted D’Amico.

    Of course, there are still many cultural and technical issues that need to be resolved before DevSecOps best practices are consistently employed across most organizations. However, the expectation is that cybersecurity teams will be able to concentrate more on crafting cybersecurity policies as application development and IT operations teams assume more responsibility for implementing those policies, said D’Amico.

    But while giving individual developers the tools they need to write more secure code is a major step in the right direction, there is also a need to make sure the builds to which they contribute code also remain secure. As such, DevOps teams need to implement guardrails across every stage of a DevOps workflow to make sure vulnerabilities are not created as code is merged. In addition, DevOps teams now need to be aware of any malware added to an open source software component downloaded from a compromised repository. Even once patched, there’s a good chance another developer will have downloaded the same vulnerable component to construct a different application.

    No one knows for certain how many vulnerabilities may have already been introduced into production environments, but it’s unlikely all those issues will ever be completely addressed. Organizations with limited technical resources will need to prioritize the patching of the most severe vulnerabilities in their application environment based on how accessible code may be to cybercriminals.

    Cybercriminals certainly are getting more adept at exploiting vulnerable code. Developers may soon find themselves being required to update software components deployed by someone else many years earlier. In the meantime, more accountability for application security should lead to better quality code that, over time, will reduce the current unsustainable level of technical debt.

  • Looking to the Future of Developer Experience

    Looking to the Future of Developer Experience

    Developer experience is where it’s at! Developer experience (DX) means taking a user experience approach to the developer journey. DX (also abbreviated as DevEx) is commonly applied to areas like documentation, sandbox environments, SDK ergonomics and more. By improving a developer’s experience with a tool, software providers can increase stickiness and retain more users.

    Nowadays, having a sleek developer experience is a competitive advantage—especially since developers often have the discretion to purchase new tools. And amid an ongoing skills gap, maintaining quality DX for internal software ecosystems is also important to retaining happy engineers and avoiding burnout. All these factors mean developer experience is becoming a C-suite objective. So, where is DX heading? How will the developer workflow change in the near future?

    I recently met with Ash Arnwine, director of developer relations, Nylas, to ponder what’s on the near horizon regarding developer experience. According to Arnwine, DX is still a very new concept. Yet, it has become an integral aspect of positioning modern software, especially for public-facing SaaS, and will undoubtedly drive purchasing decisions in the year ahead. Below, we’ll share some predictions of how DX will evolve within four general categories: onboarding, building, deploying, and maintaining.

    State of Developer Experience

    First off, what is the state of developer experience within the tech world at large? Well, Arnwine is quick to note that the concept is still relatively nascent. “Developer experience was something that we didn’t talk about that long ago.” Yet, the idea is growing in mindshare as developers exercise greater control over the software life cycle.

    In fact, the 2022 StackOverflow survey found that 66% of professional developers have at least some influence over their organization’s purchases of new technologies, up from 56% in 2020. Furthermore, the way developers learn is changing. The new generation of programmers is primarily self-taught, relying on coding bootcamps or other online resources. An impressive 70% of developers learned how to code from online resources.

    What we end up with, said Arnwine, is a growing developer population with a much wider range of skills than in the past. And since no one is there to hand-hold them, the technology itself must be usable and intuitive—the onus is on the software provider to craft frictionless self-service workflows. And with developers’ growing influence in purchasing, DX becomes a competitive advantage and an executive talking point, said Arnwine.

    Onboarding

    Developer experience is a broad topic, but it’s most often associated with the time it takes to get started with a tool. This is often referred to as ‘Time to First Hello World.’ But although it’s an important step, the metric might doesn’t always carry much significance. Time to value, on the other hand, said Arnwine, takes this a step further and is a better gauge of success.

    For example, onboarding to a web API would likely involve the signup process, creating an account, getting API keys and perusing the documentation—all before a first call is sent. According to Arnwine, there are techniques to apply at this stage to help developers move faster throughout the onboarding process to reach value sooner.

    Here are some ways in which developer onboarding is becoming more streamlined:

    • Automatically generating keys upon signup.
    • Providing a terminal within the developer dashboard to test sample code.
    • Handing developers the code they need to be customized to their specific stack.
    • Using specifications as a single source of truth for documentation.

    Building

    What can SaaS companies do to help improve DX while building? Well, one way is to enable auto-complete within IDEs. When developers onboard with a new tool, they are often handed an SDK and reference documentation. But, it doesn’t add value to send programmers back and forth between a browser to look up method names. Instead, Arnwine believes developer tools should be “baked into the IDE in a way a modern developer would expect.”

    One example of auto-complete on steroids is Fig, a next-gen command line that supports auto-complete for over 500+ popular CLI tools. Taking this a step further is GitHub Copilot, an AI assistant that can take natural language prompts and generate pretty complex code suggestions. The industry appears to be heading toward more AI-fueled low-code software development—a trend that could significantly improve a developer’s experience during the construction process.

    However, one potential downside of increased software development automation is ensuring the AI suggests correct code snippets. Thus, Arnwine said he anticipated possible troubleshooting and debugging problems. Furthermore, SaaS providers will have to vet systems that generate glue code to ensure it’s accurate and up-to-date with the latest versions. His advice to SaaS providers is to meet developers where they are, but do their best to maintain a quality experience that they can control.

    Deploying

    For a long period of software development history, IT administrators were the only ones able to deploy software. The old-school method required getting a hosting provider, installing Ubuntu and plenty of other legwork. Nowadays, however, software deployment has become far more drag-and-drop. DevOps has become more democratized in recent years, and we will likely see greater usability emerge in the years ahead.

    One way to increase developer experience for deployments is through more custom automated routines via GitHub Actions or similar event-based systems. And plug-and-play pre-built actions could reduce the barrier to using such systems. Such connectivity is necessary to enable a docs-as-code approach, said Arnwine.

    Maintaining

    Another area that could use a serious developer experience upgrade is dependency management. Software dependencies go through a life cycle. They are versioned, updated, retired and sometimes replaced outright. As such, keeping track of an evolving surface area of third-party dependencies can be a headache. To make matters worse, software supply chain threats have complicated the integrity of many open source dependencies consumed by most applications.

    Although it’s imperative for organizations to maintain parity with dependencies, a single person is rarely tasked with continuously checking dependencies and monitoring for security threats. Therefore, more automation for dependency management and security monitoring is necessary. For example, Arnwine uses Snyk, which sends a weekly report on the state of his dependencies.

    Final Thoughts

    Assuming you have the killer functionality to back it up, an investment into developer experience can help a developer tool stick out in a crowded marketplace. But of course, improving the DX means many different things depending on your context. It could be a subtle user interface tweak, adding relevant code samples or making your documentation more intuitive.

    On the other hand, a negative developer experience can turn away potential users and cause frustration throughout the application support life cycle. This can instill a poor reputation among programmers.

    To review, in the near future, we’ll likely witness the developer experience evolve in the following areas:

    • Enhanced methods that streamline the signup process.
    • Auto-complete and AI-driven code suggestions that understand a developer’s stack and meet them where they work.
    • More intuitive, automated deployment models.
    • Increased automation around the maintenance of dependencies.

    While developer experience is a growing concern, it shouldn’t be the only measurement of a SaaS — the ongoing value it brings developer consumers and end users is just as (if not more) important to consider.

  • Survey Surfaces Raft of DevSecOps Cultural and Technical Challenges

    Survey Surfaces Raft of DevSecOps Cultural and Technical Challenges

    A global survey of 606 IT, security, application development and DevOps decision-makers found that the biggest barrier to adoption of DevSecOps best practices is cultural rather than technical. However, the survey, which polled organizations with more than 500 employees and was conducted by Progress, also found only 16% of respondents planned to prioritize addressing those cultural issues in the next 12 to 18 months.

    A full 71% of respondents cited culture as the biggest barrier to DevSecOps progress, with only 30% expressing confidence in the current level of collaboration between security and application development teams currently being achieved. In contrast, 46% of respondents were not particularly confident while nearly a quarter (24%) were not at all confident.

    Nevertheless, well over half of respondents (57%) said security threats are the number-one technology factor driving the evolution of DevSecOps, even though just over half (51%) admitted they were only somewhat familiar with how security fit into a DevSecOps workflow.

    Overall, 86%of respondents said they are experiencing security challenges that include prioritizing externally facing applications over internal applications (47%), securing different types of workloads that were using different development and delivery methodologies (46%), meeting delivery deadlines (45%) and meeting audit requirements specified by the security team (39%). Just over three quarters (76%) recognized they could be more strategic in managing DevSecOps.

    The top three initiatives needed to support a shift to a more strategic DevSecOps approach identified are more investment in continuous learning for developers and engineers (61%), upskilling of developers and engineers to move into site reliability engineering (SRE) roles (60%) and improved communication between developers, security and operations (60%).

    Survey respondents also identified a need to define a clear set of policies and procedures (66%), define the role and responsibilities of staff across teams (62%), create a continuous feedback loop (49%) and automate recurring security tasks (41%).
    Despite that level of awareness, however, only 40% said they believed implementing security training and upskilling efforts across multiple stakeholders was very important when implementing DevSecOps.

    Prashanth Nanjundappa, vice president of product management for Progress, said given all the cultural and technical challenges organizations face, it’s apparent that both a top-down and bottom-up approach to implementing DevSecOps best practices is required. Attempting to shift responsibility left toward application development teams is not going to suffice on its own, he noted.

    The survey also suggested that many organizations are trying to address application security issues as they modernize their application portfolio. A total of 59% said they struggled to attain buy-in/funding for refactoring efforts that didn’t provide new user capabilities. However, only 39% said they had adopted a comprehensive modernization approach based on cloud-native architecture principles, while another 22% felt they lacked one entirely. Just under a quarter (24%) said their approach to modernization is to largely rip-and-replace applications.

    The top business factor driving the adoption of DevSecOps was a focus on business agility enabled by fast and frequent delivery of application capabilities (59%). Just under half (45%) said it had taken six to 12 months to achieve a return on DevSecOps investments, while 31% said it had taken longer than a year. However, only half (50%) of respondents were familiar and interested in both infrastructure and policy-as-code.

    There is no doubt that the DevSecOps journey ahead will be long and arduous. However, there are also a wide range of small process changes that could have a massive impact in terms of improving application security in the short term. The challenge is to quickly identify those opportunities while at the same time employing a more systematic approach that ultimately makes it a lot simpler to implement a set of DevSecOps best practices consistently.