devopsy.kinsta.cloud

Tag: software development

  • Technical Debt: Don’t Buy Buzzwords

    Technical Debt: Don’t Buy Buzzwords

    It is absolutely true that the only constant in IT is change. No sooner do a mass of us get the ‘next big new shiny thing’ implemented than people start telling us how much we need the next ‘next big new shiny thing.’ Often, that next big new shiny thing is actually helpful, and we feel (sooner or later) compelled to implement it. Sometimes, the next big new shiny thing is not very useful at all, and yet far too many of us implement it anyway.

    Not naming names here, but you’ve all got technical debt that I would classify as “bling” or “keeping up with the competition” functionality. It’s there; you’re paying for it and/or to maintain it, and yet it provides little value. Sometimes, you’re even forbidden from removing it because it is some exec’s pet project or some corner department is actually using it. You’d just have to replace this version of the next big new shiny thing with a different version.

    And I’m here to tell you: Stop. When considering new technology, the very first thing to do is build a list of the problems you are trying to solve and then describe scenarios where those problems crop up. Then compare the next big new shiny thing–be it features in an existing product or a new space/product completely–to how it solves real needs. People are the absolute worst about this with open source. “It’s free, so let’s try it out.” It. Is. Never. Free. And it is a rare team that tries it out and then removes it if it doesn’t work. Most of the time, they’re off to the next project too quickly to do that level of cleanup.

    SBOMs and SCA are ‘next big new shiny things’ of the recent past that actually help you clean up test/pilot garbage from the latest bout of next big new shiny things. So are containers since you can spin them up, play with the toys and then take them down. I am surprised at the number of teams out there who do not do this, but that’s changing pretty quickly. Use them; it’ll save a ton of cleanup time and a lot of technical debt.

    But most importantly, only buy what you absolutely need. We’ve been dropping an ever-increasing number of tools into the development environment for a decade, and those tools do not (yet) maintain themselves. There is infrastructure cost, possibly licensing cost and staff time. Don’t waste it; focus on what is literally most important.

    And that might mean putting your foot down. We in IT have been loathe to do that since Agile started, but telling a C-level that they don’t need an AI to create new drink recipes (or whatever the current generative AI boardroom craze is) is in the best interests of the company. Focus on systems that help do the work or that protect what does do the work.

    You’re still rocking it, so if rocking the boat a bit in the process causes problems, you might just be at the wrong company or in the wrong role. Achieve, but achieve meaningful results.

  • Atlassian Strengthens Jira Navigation and Integration

    Atlassian Strengthens Jira Navigation and Integration

    Atlassian today made it simpler to navigate the Jira Software and Jira Work Management project management applications as part of an ongoing effort to make it simpler for DevOps teams to collaborate with other stakeholders of application development projects.

    Megan Cook, head of product for Atlassian, said the ability to share release dates across multiple calendars, overviews that aggregate views of and summarize multiple projects along with command palette and importer tools make it simpler for, for example, marketing teams and other individuals outside of a DevOps team to keep track of application delivery schedules.

    In addition, Atlassian has tightened integration between Jira and Confluence, a wiki-based collaboration application, and a previously launched Atlassian Intelligence capability that infuses generative artificial intelligence (AI) capabilities will also soon be added to Jira Work Management alongside existing support for Jira. There will also be connectors for Jira Work Management to integrate with Atlassian Admin, Atlassian Analytics, Access and Data Lake offerings, along with advanced security features.

    Finally, Atlassian is adding support for a design tool developed by Figma that can now be directly installed in Jira.

    Collaboration between application development teams and the rest of the business is becoming more crucial as organizations increasingly realize how much they depend on software to drive revenue. One of the primary reasons Atlassian is investing in generative AI is to make it simpler for anyone to understand the status of any given project and the downstream impact any change to a delivery schedule is likely to have.

    Generative AI, of course, has already moved from being considered advanced technology to a set of capabilities that most end users will soon expect to be embedded within every application. One of the primary benefits generative AI provides is it makes a range of applications originally designed for specialists, such as a software engineering team, more accessible to a wider range of end users.

    It’s not clear how much generative AI will change the relationship between DevOps teams and the rest of the business, but with increased visibility, there should be a greater appreciation for the challenges developers and DevOps teams face. Any member of an organization should be able to plainly see, for example, why more resources need to be allocated to a specific project to ensure that an application is delivered on time.

    At the same time, application developers will find project management processes are about to become less disruptive as it becomes simpler to automatically import relevant data from the tools and platforms they use directly into a project management application such as Jira.

    One way or another, software engineers should expect that as generative AI continues to evolve, the divide between them and the rest of the business will narrow. There may be times when that level of additional scrutiny may feel burdensome, but on the whole, it should make it easier for DevOps teams to get the resources required to achieve any given goal. After all, the root cause of any given delay to a project will soon be plain for anyone to see.

  • JFrog swampUP: Addressing the Advent of AI

    JFrog swampUP: Addressing the Advent of AI

    At JFrog SwampUp 2023, the buzz with all about AI, especially with JFrog’s announcement of Machine Learning (ML) Model Management capabilities. These conversations around AI and ML reflected these technologies’ growing influence and importance in the DevOps world. How much of the generative AI conversation is just hype, though? And what does that mean for AI and ML as a whole? Alan Shimel, CEO of Techstrong Group, and I sat down with Stephen Chin, VP of DevRel at JFrog, to find out.

    As far as Chin is concerned, even as more companies create and leverage AI models, these models must be managed like any other software component. Chin said JFrog Artifactory acts as a staging ground to operationalize models using DevSecOps best practices. Algorithms and models will continue to grow in size and complexity, and they will require robust processes around deployment and management – just like any other software artifact. The key, Chin said, is to think of ML as just another development language and leverage tools that standardize and streamline working with it. Compared to traditional enterprise applications, though, DevOps workflows for AI/ML are still relatively immature, but Chin said JFrog’s new model management capabilities aim to provide that missing automation and governance using DevSecOps best practices for governance, security, and licensing compliance.

    Additionally, Chin noted that AI/ML have become essential for development teams to keep up with the explosive demand for code. At this point, AI has become table stakes. In the AI arms race, the winners are those who understand AI has become a vital development tool to enhance productivity. In terms of job security, the losers are the ones who can’t keep up with the volume of code. According to Chin, you are out of the running if you don’t embrace AI.

    Looking ahead, AI will not make developers obsolete, though – quite the opposite. Given the quasi-unlimited appetite for new code, Chin emphasized that developers who embrace AI will have more work than ever. One way to think of it is that AI provides a new form of “outsourcing” to boost human productivity, much like previous waves of innovation in computer science.

    When it comes to security, there are still challenges that need to be addressed; code generated by today’s AI solutions still has significant drawbacks like potential data bias, lack of explainability and simple errors. In the long term, though, Chin believes AI itself will provide the solution to secure an exponentially growing codebase, given its superior scale. Just as AI will make individual developers more productive, it can also supercharge security teams – but it can also empower bad actors. The key will be continuing to democratize the benefits to even the playing field. AI promises to be a transformative technology on the scale of the Bronze Age or Quantum computing, Chin said, but the path forward will require humans and machines working together to ensure it’s used for good.

    It’s clear that the pace of innovation in AI and ML is rapidly accelerating. As these technologies become further democratized and integrated into developer workflows, they promise to transform how software is built and secured, Chin said. Companies must take advantage of this technology innovation by providing the pipelines and governance for this software revolution, he added. Chin believes the future will likely see a more symbiotic relationship between humans and AI assistants collaborating to generate, refine and safeguard code. By proactively shaping the responsible use of these technologies, it’s possible to maximize the benefits while minimizing the risks. While this journey has only just begun, the destination is an exciting new era of human potential unlocked by AI, Chin said.

  • CloudBees CEO: State of Software Development is a Disaster

    CloudBees CEO: State of Software Development is a Disaster

    CloudBees CEO Anuj Kapur told attendees at a DevOps World event today that with developers spending only 30% of their time writing code the current state of software development in enterprise IT organizations is a disaster.

    After more than 14 years of effort, the promise of DevOps—in terms of being able to accelerate the rate at which applications are being deployed—remains largely academic, said Kapur. In fact, the effort to shift more responsibility for application security further left toward developers has only increased the amount of cognitive load and reduced the amount of time available to write code, he noted.

    However, with the rise of generative artificial intelligence (AI), an inflection point that will dramatically increase the velocity at which applications are being built and deployed has arrived, said Kapur. The challenge will be achieving that goal without increasing the cognitive load on developers. That cognitive overload results in 70% of developers’ time not being productive within organizations that often hire thousands of developers, he noted.

    Despite all the DevOps issues that need to be addressed, AI advances promise improvement. The overall DevOps market is still relatively young, given the current level of adoption, said Kapur. “We continue to believe the market is early,” he said.

    Today, CloudBees took the wraps off the first major update to the open source Jenkins continuous integration/continuous delivery (CI/CD) platform to have been made in the past several years. At the same time, the company also unveiled a DevSecOps platform based on Kubernetes that is optimized for building and deploying cloud-native applications based on portable Tekton pipelines. That latter platform provides the foundation through which CloudBees will, in the months ahead, apply generative AI to software engineering to, for example, create unit tests on the fly and automate rollbacks.

    In addition, DevSecOps capabilities will be extended all the way out to the integrated development environments (IDE) to reduce the cognitive load of developers.

    The overall goal is to reduce the number of manual processes that create bottlenecks that make it challenging to manage DevOps at scale.

    Criticism of the level of developer productivity enabled by DevOps compared to other development approaches needs to be tempered, said Tapabrata Pal, vice president of architecture for Fidelity Investments, because it still represents a significant advance. There is still clearly too much toil, but the issues that impede the pace at which developers can effectively write code tend to be more cultural than technical, he added.

    Organizations are not inclined to automatically trust the code created by developers, so consequently, there is still a lot of friction in the DevOps process, noted Pal.

    In theory, advances in AI should reduce that friction, but it’s still early days in terms of the large language models (LLMs) that drive generative AI platforms and their ability to create reliable code, he added. That should improve as LLMs are specifically trained using high-quality code, but in the meantime, the pace at which substandard code might be generated could overwhelm DevOps processes until AI is applied there as well, said Pal.

    Thomas Haver, master software engineer for M&T Bank, added that while assisted AI technologies will have a major impact, it’s not reasonable to expect large organizations to absorb them overnight. Patience will be required to ensure advances are made in ways that are both secure and sustainable, he added. In some cases, organizations may opt to build their own LLMs to achieve that goal, noted Haver. “You should not expect to change on a dime,” he said. “It will take time to see the fruits of our labor.”

    While many DevOps challenges need to be resolved, the benefits continue to outweigh the cost and effort required to succeed. The hope is that, with the help of AI, the return on those investments will continue to accrue.

  • Will ChatGPT Replace Human Software Developers? Probably Not

    Will ChatGPT Replace Human Software Developers? Probably Not

    Since the release of ChatGPT, there has been a great deal of hype around generative AI and how companies can leverage it to cut costs and democratize software and application development. Naturally, with discussions of cost-cutting and democratization come whispers about what will happen to software developers.

    This is a real and valid concern, but software developers’ skills, expertise and creativity are still very much needed.

    While generative AI and AI code generation tools like ChatGPT have shown some promise and potential benefits, they are still in their infancy—like many other innovative technological advancements. We also don’t know what scenarios they may present down the road or their true abilities when the technology matures. For instance, how will it integrate with other technologies? We don’t know what will happen when a ChatGPT-generated line of code breaks or needs to be changed. We don’t know if it can provide a novel solution to a unique problem or what security threats it will present.

    Given these unknowns, technology executives should think twice about replacing experienced and creative technology talent, such as software developers, with AI code generators.

    Will ChatGPT create novel code to solve a unique problem never encountered before? Probably not.

    A Tale as Old as Time (Or at Least a Decade)

    The technology industry has been searching for and developing new ways to make certain software development tasks much easier and more streamlined for years. One example of this is low-code/no-code.

    The notion of simplifying application development and replacing software developers with laypeople (citizen developers) has been around for more than a decade now, as low-code and no-code solutions have grown more popular. These solutions have promised that companies don’t need technical talent to get their software and app projects off the ground.

    However, if you look at the impact of these solutions today, their use can result in large amounts of technical debt and almost always require the skill of experienced software developers.

    The reason? Building complex software and applications is extremely difficult; it’s an art.

    Low-code and no-code solutions have their rightful place and can make things easier if a company is looking to launch a simple app or static web page. These solutions can increase the pace of development and time-to-market and enable everyday people without any development skills to facilitate them. However, they are not actually a complete solution and often overlook aspects of development that a human software developer would typically address. Without a skilled expert involved, low-code/no-code platforms often can’t solve a unique problem a company has.

    So, how does this relate to AI code generators like ChatGPT? Here’s how.

    A Similar Situation—With One Key Difference

    When thinking about their place in the development process, AI code generators are not that different from low-code or no-code solutions. The thinking is that they will also enable non-technical individuals to create software and applications with ease.

    Yet, there is one key difference—they promise expertise, too. But is the expertise coming from the AI code generator or the person piloting it? The answer is simple; it is not from the code generator.

    There have been examples of companies and individuals that have tried using ChatGPT to build code, and they have appeared to be successful. However, without the input of the individuals using it, it never would have been able to create the code on its own unprompted.

    This means that the expertise of skilled, human software developers is still very much needed, especially when building intricate software and apps that require complex functionality such as optical character recognition (OCR), internet-of-things (IoT) connectivity and more.

    A Future With Software Developers

    Because of the expertise still required to create elaborate and innovative software and applications, AI code generators will not replace software developers anytime soon, if ever.

    The technology used in these tools is still in its infancy, presenting many lingering questions and potential challenges. We will see this confirmed by the trials and tribulations experienced by the few companies and executives attempting to replace software development teams with tools such as ChatGPT.

    Knowing AI code generators follow a similar path as low-code and now-code solutions, companies and executives should use them as developer enablement tools. These tools should complement the work of software developers by empowering them to focus on the complex tasks software and apps today require.

  • Despite Concerns, AI Increasingly Used to Build Software

    Despite Concerns, AI Increasingly Used to Build Software

    A survey of 1,001 senior technology executives, developers, and security and operations professionals published this week by GitLab finds 67% are working for organizations already using artificial intelligence (AI) to build software, with 60% of those respondents reporting their organizations use it every day. A full 90% said their organizations are either already using or plan to use AI to build software.

    More than half (51%) have already identified productivity as a key benefit, but 32% are also “very” or “extremely” concerned about introducing AI into the software development life cycle (SDLC).

    Those concerns included AI-generated code introducing security vulnerabilities (39%) and whether that code may not be subject to the same level of copyright protection as human-generated code (48%). A full 95% of senior technology executives said they prioritized privacy and intellectual property protection when selecting an AI tool.

    Most organizations will continue to move forward with AI, but nearly two-thirds of respondents (65%) who use or are planning to use AI for software development said their organization hired or will hire new talent to manage its implementation.

    A full 81% cited a need for training to successfully use AI in their daily work, with 75% of respondents saying their organization provides training and resources for using AI. However, a roughly equal percentage also said they are finding resources on their own.

    David DeSanto, chief product officer for GitLab, said it’s already clear that AI will have a major impact on productivity simply because 75% of a developer’s time is typically spent on activities that have nothing to do with writing actual code.

    Less clear is the amount of expertise required to use AI to build software. In some cases, development teams may need to master, for example, prompt engineering to automate DevOps workflows at scale, but in many more instances, it’s likely the DevOps platform will automatically execute the commands required.

    Regardless of approach, it’s clear that as the amount of code being created by developers starts to steadily increase, the need to leverage AI to manage DevOps workflows will become more acute. The challenge is the pace at which developers can leverage AI to write code is, for the moment, exceeding the pace at which it is being embedded into DevOps platforms.

    In addition, organizations must determine whether to converge DevOps workflows with the machine learning operations (MLOps) workflows used to build AI models that are integrated into applications. As more MLOps capabilities are added to the GitLab platform, it will become easier to achieve that goal and enable data scientists to work more collaboratively with DevOps professionals, noted DeSanto. Today, a cultural divide between two distinct IT cultures is slowing down the pace of AI innovation.

    One way or another, DevOps workflows are about to be transformed. The challenge now is determining which tasks and bottlenecks are likely to be eliminated by AI to enable DevOps teams to focus on managing applications at an unprecedented scale.

  • Developer Activities

    Developer Activities

    developer-activities

  • The Differences Between DevOps, DevSecOps and SRE

    The Differences Between DevOps, DevSecOps and SRE

    DevOps, DevSecOps and SRE are all quickly gaining traction within the tech world due to their effectiveness and promise of reliability for companies. Each framework provides various levels of safety and scalability—DevOps is agile, DevSecOps prioritizes security above all else and SRE focuses on performance optimization. Together, these are changing how software gets deployed from conception to production. We’ll break down each one in detail.

    What is DevOps?

    DevOps is a set of practices that combines software development and IT operations, which aims to shorten the software development life cycle (SDLC).

    DevOps bridges the gap between those two areas by bringing together different people–developers, operators, testers and system engineers–who are responsible for different parts of the software delivery process, from planning to deployment into production environments.

    A core tenet of DevOps is to automate manual processes within each stage of the SDLC, eliminating much of the redundant work that used to take weeks or even months. This automation significantly drives down costs, as well as reduces problems posed by human error when running manual tasks.

    The following are some of the core tenets of DevOps:

    1. Collaboration
    2. Quality and reliability
    3. Automation
    4. Scalability
    5. Security

    What is DevSecOps?

    DevSecOps (or DevOps security) is an emerging field within the DevOps practice that focuses on strengthening software security within the development and operations process.

    These three distinct groups often have different priorities when it comes to building software applications. Developers are focused on speed-to-market objectives from their employers or clients, operations focus on reliability and scalability, while security teams prioritize safety from malicious actors or data breaches. At the same time, with DevSecOps, these goals become united under one umbrella: Build fast and reliable applications with built-in protection against attacks.

    DevSecOps focuses on implementing security as code—or automating many routine tasks involved with identity management, like user authentication and authorization. To ensure that security is properly integrated into your DevOps pipelines, below are some key DevSecOps practices:

    1. Automate security processes whenever possible
    2. Encourage continuous testing
    3. Prioritize remediation over detection
    4. Create a culture around secure coding principles

    What is SRE?

    SRE stands for site reliability engineering. The basic idea behind SRE practices is that software engineers should be responsible for both the development as well as the reliability of their product as a whole. This means having an understanding of not only how users will interact with the application or service but also how it interacts with other services in its operating environment, such as databases, firewalls, cloud environments, etc.

    To maintain uptime while meeting these requirements, SRE applies various techniques like automation and continuous deployment processes to ensure high availability.

    A key goal of site reliability engineering is service-level objectives (SLOs), which measure how consistently a service meets its goals over a given period of time—such as how often it’s available, how quickly it responds to requests made by users or customers—and establishing goals around those SLOs. Achieving objectives like these helps organizations build customer trust in their products and services since it ensures that they have stable and reliable day-to-day operations.

    Here are some of the most important SRE principles:
    1. Automation
    2. Proactive monitoring
    3. Fault tolerance
    4. Measurement and analysis
    5. Service-level objectives (SLOs)

    DevOps Vs. DevSecOps Vs. SRE

    The differences between DevOps, DevSecOps and SRE can be summed up in three main areas: Scope, roles and objectives.

    DevOps focuses on improving the speed of releasing software by automating processes and optimizing collaboration between development and operations teams. This helps organizations create a continuous delivery pipeline to quickly deploy code into production with minimal risk. As such, it is typically focused on development or operations activities and has become synonymous with agile methodologies such as continuous integration/continuous delivery (CI/CD).

    DevSecOps expands upon these concepts to include security considerations from the very beginning of a project’s life cycle instead of tacking them on after the fact. By shifting security left in the process–meaning bringing security earlier into the design phase–teams are able to reduce risk early on while achieving faster results overall through continuous feedback loops.

    As part of this shift left process, DevSecOps practitioners focus heavily on automating security compliance activities as part of their job function rather than waiting until after deployment has occurred.

    Meanwhile, SRE focuses more broadly on keeping the user experience consistent across various products an organization offers by responding to customer needs quickly while creating automation processes that allow common tasks to be repeated without manual intervention from engineers or developers.

    Then there is also platform engineering, which is a closely related yet distinct discipline with its own unique responsibilities. While both DevOps and platform engineering involve automation and working with the infrastructure that supports software development, there are some key differences between them.

    Platform engineering can be defined as a practice that involves developing a standardized platform on which all applications will run. Platform engineers build the underlying infrastructure to support applications, including servers, databases, virtualization layers and networking components using standardized toolsets. An important task for this field is designing an application’s architecture in such a way that allows it to scale easily with increased demand or usage levels. Additionally, they create self-service tools that enable developers on their team to quickly spin up new environments without requiring outside assistance.

    Wrapping Up

    In conclusion, while all three approaches have similar goals–ensuring reliability, speeding up the software delivery process and securing user data–they do so using different strategies:

    ● DevOps favors automation.
    ● DevSecOps puts focus on proactive security measures.
    ● SRE prioritizes optimization, reliability and scalability.

    Each one can contribute significantly when appropriately implemented into any organization’s workflow, depending upon its own specific needs.

  • System Initiative Open Sources Digital Twin Tool for DevOps

    System Initiative Open Sources Digital Twin Tool for DevOps

    System Initiative (SI) today announced it is making the digital twin tool it developed to manage DevOps workflows available under an open source Apache 2.0 license.

    Company CEO Adam Jacob said the approach will enable third parties to contribute to a project that is still early in its development cycle while SI provides commercial support via a subscription service.

    SI has developed a tool that creates a digital twin of a DevOps environment that provides a level of abstraction that makes it simpler to manage complex workflows at scale.

    At the core of that effort are models of IT environments created by the SI platform accessed via a visual interface. The automation framework built into the platform uses the relationships between models to infer configuration dynamically and generates typescript code that a DevOps team can then apply to automate a task.

    Feedback loops are provided in real-time to give insight into the viability of a configuration, in addition to eliminating the need for state files to track and ‘plan’ versus ‘apply’ stages.

    This approach streamlines a lot of the complexity that creates bottlenecks in DevOps workflows in what heralds the arrival of a new DevOps 2.0 era, said Jacob.

    In general, SI is making a case for an alternative approach to managing DevOps as the existing platforms and framework are fundamentally broken, added Jacob. Models that create digital twins of DevOps environments represent the arrival of a new era of software development and deployment, he noted.

    As more organizations realize their dependency on software to drive digital processes many are then looking to improve the productivity of developers and the DevOps teams that support them. Unfortunately, many DevOps teams are supporting DevOps workflows using custom code that varies widely in quality. Rather than rely on a DevOps engineer to write code, the SI digital twin tool will create code that can be applied more consistently to create DevOps workflows programmatically.

    One of the reasons few organizations today have fully automated DevOps across the application development and deployment process is that it’s simply too difficult to achieve using legacy tools and DevOps platforms. It’s not clear to what degree a digital twin approach to managing DevOps will resolve that issue, but when coupled with the arrival of artificial intelligence (AI) capabilities the way DevOps is managed is clearly about to transform.

    It may take a while for that transition to occur, but DevOps teams that have historically embraced automation are at the very least going to aggressively experiment with technologies that promise to eliminate much of the drudgery that makes DevOps more tedious than need be. The issue, as always, will be determining which technologies live up to the current level of hype being generated in a way that can be easily adopted.