staging-devopsy.kinsta.cloud

Tag: devops

  • Security Across the SDLC

    Security Across the SDLC

    We’ve seen some interesting movements in the security space over the last couple of years. My focus is on application security, but one of the movements we’ve seen is the blurring of what is application and what is infrastructure security, so I do a fair amount of that also. And then, with the advent of WAAP, we have network security playing a role in AppSec… It’s a growing snowball.

    I will start with the mandatory happy declaration that DevOps no longer treats security as an annoyance. While we’re well past that, I think the shock of the whole “security is a problem, not protection” mentality that DevOps started with is still hanging with us, and some still actively believe that. But at this point, we’re well on the “Security is part of the process” trail we should be on.

    If you look at the top-level changes, static application security testing (SAST) vendors have grown to be development security, covering SAST, DAST, IAST, RASP and even a bit of data security. Meanwhile, load balancers and WAF slowly evolved into full-on web applications and API security that covers the production side with active protections for things like DDoS and DLP.

    Likewise, we’ve seen this with the growth of cloud workload protection and how the entire digital architecture is being pulled into CSPM.

    I’ve said it before – we’re in a consolidation phase. It looks like it will go even further than I thought, though. Now, we are starting to see an interesting development: WAAP vendors are starting to include some or all of DAST, SAST and RASP. Arguably, they always did some IAST because their focus was on runtime protection, but their emphasis is more on protection than test, so it will be interesting to see that bit expand also.

    And all of this includes an inconvenient fact. We don’t have any more people to do security than we ever did; in fact, we have less. That’s part of the reason that we haven’t shoved security everywhere – there aren’t people to do it. In true DevOps fashion, we have distributed the work across other teams – Dev is right there where code security and API security start, so we’ve implemented SAST and DAST bits right into the IDE, for example. Or Ops has always done some amount of security, and we’ve just upped the amount. But they don’t magically have more time, either. I’m sure you are feeling it if you are a practitioner; almost all of us are. AI promises to help with that, and in security, it will likely deliver. Another thing I’ve pointed out before is that security is one space that really does stand to gain from generative AI – in helping make more secure code, in helping make all the permutations of tests, in making rules based upon observed data and more. The time-saving benefits will deliver, in my opinion. But it’s still a lot of work, and some of it is straight-up additional work because we weren’t doing things like container security a few years ago.

    In the short term, if full SDLC security is applied, there will be more work. In the long term, the mega platform for security may well reduce this work as it limits notifications across tools. Maybe we should name the coming mega platform SecArch. Also in the long term, AI will help alleviate some of the load. Until then, buckle in. You’re not likely to get staff to cover new work. But it will be worth it. Just keep plugging along, and know when to say you just can’t add one more thing to the pile.

  • Anima Adds Ability to Personalize Generative AI Code

    Anima Adds Ability to Personalize Generative AI Code

    Anima today revealed is has added an ability to personalize the code its generative artificial intelligence (AI) platform creates based on how an application is described using tools from Figma and Adobe.

    That capability makes it possible for the code being generated to resemble the coding style of an organization or specific developer more closely.

    Anima CEO Avishay Cohen said the company developed this capability to reduce the editing time that is otherwise required when trying to embed code generated by a large language model (LLM) within an application that has a well-defined coding methodology.

    The platform that Anima provides is based on a mix of LLMs and heuristics that the company developed to generate code. In this case, the code being generated is written in React or HTML to make it simpler to build an application’s front end. In contrast, a general-purpose LLM such as ChatGPT is not optimized for creating these types of graphical applications.

    Developers no longer need to worry about, for example, making sure each pixel is perfectly placed because the Anima platform automates that part of the application development process, including adding responsive behavior, animations and logic, noted Cohen. In addition, customized instructions may be applied to an entire project or even a specific component.

    In effect, the platform enables backend developers to automatically create a front-end for their application from a description in tools provided by Figma or Adobe. As a result, developers can allocate more time to writing business logic and optimizing application performance, said Cohen.

    Later this year, Anima will integrate its platform with GitHub and other continuous integration/continuous delivery (CI/CD) platforms as part of an effort to extend the reach of the platform across an entire codebase, he added.

    There is, of course, already no shortage of generative AI tools for writing code, but the degree to which they have been incorporated into DevOps workflows varies from one organization to the next. Much of the code created using platforms such as ChatGPT can vary widely in terms of quality. These platforms were trained using code collected from across the web so it’s not uncommon for the code generated to include known vulnerabilities that DevOps teams need to scan before incorporating into a build. In other cases, the code generated might simply break when installed.

    Regardless of these issues, however, the amount of code being generated by machines is only going to increase, especially as more LLMs that are specifically trained to create code based on examples that have been closely vetted become more widely available.
    In the meantime, developers who never especially enjoyed building the visual front ends of applications can now focus more of their time on tasks they prefer. Alternatively, developers who specialize in the front ends of applications will find that much of the toil involved will soon be automated in a way that should provide more time for them to create customized experiences.

    One way or another, the overall pace at which applications are built is about to exponentially increase. The challenge now will be finding ways to take advantage of AI to enable DevOps teams to keep pace.

  • Using LLMs to Automate Pipeline Conversions From Legacy to Tekton

    Using LLMs to Automate Pipeline Conversions From Legacy to Tekton

    There have been many technological advancements in the market today, but the main hindrance is the cumbersome process of switching from the existing technology/framework to the new one. This is where teams and organizations are left behind in the tech curve. In the DevOps landscape, CI/CD pipelines are the backbone of DevOps, and how you work with them largely dictates your DevOps efficiency.

    CI/CD pipelines, too, like other major technologies and frameworks in the past, have seen various evolutions; the latest among them is being made reusable in an attempt to standardize CI/CD. However, here too, there are several cons:

    1. The pipelines are not proprietary to end-user enterprises and belong to the DevOps platforms which are not open-source
    2. Migrating to these platforms and pipelines is a huge task
    3. They may not be as efficient as depicted

    Speaking of new advancements in technology, most might be familiar with Tekton for CI/CD pipelines: It is Google’s open source framework that is now a graduated CDF project. It redefines how pipelines are built (through reusable tasks) and these tasks are open source and community-vetted. They allow for pipeline authorship, and enterprises can re-use them across platforms that are compatible with Tekton, thus preventing vendor lock-in.

    While this mitigates the first challenge of pipeline ownership and migrations, however, the same problem plagues DevOps teams – transitioning from existing legacy technologies/frameworks to newer, much more capable frameworks like Tekton.

    However, what if there was a way to seamlessly automate your transition from legacy pipelines to cutting-edge, reusable Tekton pipelines without toil? This is precisely what the article aims to explore – automating the conversion of Yaml scripts of existing pipelines to Tekton Yaml scripts.

    Let us consider the three most popular CI/CD platforms for this use case – Jenkins, GitLab and Azure DevOps. Before we proceed to the proposed approach to achieve this (which is detailed in the second half of this article), let us first look at the limitations of Jenkins, GitLab and Azure Pipelines and why one should convert.

    Common Limitations of Jenkins, Azure and GitLab Pipelines

    Resource Intensive: Legacy pipelines can be resource-intensive, especially for larger organizations or projects. Managing server resources, optimizing configurations and ensuring sufficient hardware can be a challenge.
    Complex Setup: Setting up and configuring Jenkins, GitLab and Azure DevOps can be complex, particularly for self-hosted instances. This complexity may require experienced administrators and substantial time investment.
    Plugin and Integration Compatibility: All three platforms may face compatibility issues with certain plugins or integrations.
    Scaling Challenges: Scaling in organizations, especially when dealing with multiple microservices, necessitates a shift from individualized scaling to a template-based approach. Failing to do so leads to a chaotic increase of pipelines, undermining standards and organizational processes.
    Costs: While both Jenkins and GitLab offer free and open-source versions, some advanced features or capabilities may only be available in higher-tier paid plans. This can lead to cost considerations at scale.
    Customization Complexity: These platforms can be complex to customize workflows and integrate custom scripts as they require advanced scripting knowledge.
    User Interface Complexity: Though they have feature-rich interfaces, it can sometimes be overwhelming for new users to navigate the platforms and find specific settings or options.
    Limited Native Integration & Plugins: The native integrations of Jenkins, GitLab and Azure may not cover the full spectrum of tools and services a team may need. Additional integration efforts or third-party tools may be required to bridge gaps in the development workflow.

    As can be seen in the above limitations, many are common including scalability challenges, being resource intensive, limited integrations etc. All the challenges boil down to one common denominator: Complex pipeline management at scale.

    This is where a framework like Tekton can help tackle all the challenges at once, by just easing pipeline management: with its K8s-native pipelines that are reusable, open source and tasks that are community-vetted.

    Tekton Pipelines: Advancing CI/CD with Kubernetes-Native Automation

    Tekton, an open-source project, is rapidly gaining traction as a game-changer in the world of CI/CD pipelines. Its Kubernetes-native design is a standout feature, seamlessly integrating with Kubernetes clusters to harness its scalability and resource efficiency.

    Furthermore, Tekton’s cloud-native roots ensure it can execute tasks in lightweight, ephemeral containers, optimizing resource utilization. The ability to declare CI/CD pipelines as code, coupled with GitOps practices, enhances automation and reproducibility.

    How are Tekton Pipelines Different?

    Kubernetes-Native Automation: Tekton pipelines are deeply integrated with Kubernetes, utilizing Custom Resources and Operators to define and execute CI/CD workflows.

    Declarative and Modular: These pipelines are defined declaratively using YAML manifests, promoting version control, collaboration and code reviews. The modular design of tasks and pipelines enables teams to create reusable components for building, testing and deploying applications.

    Containerization and Isolation: Each task in a Tekton pipeline runs within a dedicated container, ensuring isolation and reproducibility of the build and deployment environment.

    Event-Driven Architecture: Tekton pipelines can be triggered by various events, such as code commits, pull requests, or external events, providing a responsive and event-driven CI/CD process.

    Scalability and Efficiency: Tekton pipelines leverage Kubernetes’ inherent scalability, enabling efficient execution of tasks across a dynamic pool of worker nodes.

    Visibility and Observability: They offer built-in monitoring and logging, allowing teams to gain insights into pipeline execution, track progress and diagnose issues.

    Integration and Extensibility: Tekton pipelines can be easily extended with custom tasks and integrations, enabling teams to connect with various tools, services and cloud platforms.

    Cloud-Native Best Practices: By embracing Tekton pipelines, organizations align with cloud-native best practices, promoting the use of Kubernetes and containerization for streamlined application delivery.

    Why Transition From Jenkins, GitLab, and Azure Pipelines to Tekton Pipelines?

    Migrating from Jenkins, GitLab, or Azure pipelines to Tekton pipelines can be a strategic choice, especially for organizations deeply entrenched in Kubernetes and cloud-native methodologies.

    Optimize Kubernetes-Centric Workflows: Projects tightly integrated with Kubernetes may find Tekton pipelines more aligned with their ecosystem.

    Accelerate Cloud-Native DevOps: Organizations aiming to embrace a cloud-native approach and leverage Kubernetes infrastructure.

    Performance and Scalability: Tekton pipelines run on clusters that can dynamically be created and destroyed according to demand, thus taking resource optimizations to the next level.

    Cloud-Native Best Practices: Best practices, such as containerization, declarative configuration and infrastructure-as-code are a natural fit due to their Kubernetes-native design.

    Proposed Workflow for Automating Pipeline Conversions at Scale

    The overarching objective of this workflow is to facilitate a seamless conversion process using large language models (LLM) without delving into the intricacies of fine-tuning but rather using the benefits of prompt engineering. Central to this approach is the use of the chat context and the strategic application of roles for LLM models to establish context. Along with this, sample pipelines are leveraged to train and fine-tune the model to define how the corresponding YAMLs of all these platforms look for any given pipeline.

    The use of prompts and instructions tailored to fit the use case of generating contextual pipeline YAML and conversion of Jenkins/Gitlab pipelines to Tekton pipelines makes this workflow possible. We maintain a context and a contextual mapping of real-world examples and the most appropriate prompt designs to produce the most accurate responses. The role of users in this context adds weight and further refines the response received.

    However, before proceeding into details and examples, let’s set the base for what exactly generative AI means and its context in our use case:

    Generative AI and LLM for Automating YAML Script Conversions

    Generative AI, such as LLMs, create content like text, benefiting from patterns in large datasets. Large language models (LLMs), with billions of parameters, excel in generating human-like text by understanding language structures. They have broad applications, including natural language understanding, summarization, translation and content generation, promising automation and human-like interactions with AI.

    Adapting the Model to Solve Real-world Use Cases

    Fine-tuning and prompt engineering are two common methods used to train large language models (LLMs) like GPT-3, BERT and others. These methods help adapt pre-trained models for specific tasks or generate contextually relevant responses. Both fine-tuning and prompt engineering play crucial roles. Fine-tuning helps the model comprehend complex use cases, while prompt engineering provides detailed requirements, extracting the best results from the model.

    Why Prompt Engineering?

    Prompt engineering stands out as a highly advantageous approach in specific use cases where precision, control and customization over AI model behavior are paramount. This method empowers developers and users to meticulously design input prompts, effectively guiding AI models to produce contextually relevant and desired responses.

    Prompt engineering is both an AI engineering technique for refining large language models (LLMs) with specific prompts and recommended outputs and the term for the process of refining input to various generative AI services to generate text or images.

    The process of prompt engineering to fit our use case includes :

    Defining the goal: The first step in the process of AI prompt engineering involves setting a clear objective.

    Crafting the initial prompt: With the goal in mind, it’s time to draft an initial prompt. This could take the form of a question, a command or even a scenario, depending on the goal.

    Testing the prompt: The initial prompt is then input into the language model, and the response is analyzed.

    Analyzing the response.

    Refining the prompt: With the insights gathered from testing and analysis, it’s time to revise the prompt. This could involve making it more specific, adding more context or changing the phrasing.

    Iterating the process: The testing, analyzing and refining steps are repeated until we are satisfied that the prompt consistently guides the model toward generating the desired response

    To conclude, here’s an example of typical YAMLs from Jenkins, GitLab and Azure DevOps, and how the same YAML looks when converted to a Tekton YAML. This goes a long way in facilitating teams to finally make a jump from their existing pipelines to cutting-edge reusable pipeline frameworks:

    Jenkins YAML

    GitLab YAML

    Azure YAML

    Converted Tekton YAML

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    staging-devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted 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:

    SimplyHired.com

    D2 Consulting
    Springfield, Virginia
    DevOps Engineer
    $150,000 to $180,000

    Indeed.com

    Mariner Finance
    Remote
    DevOps Engineer
    $120,000 to $150,000

    ZipRecruiter

    Cogility Software
    Irvine, California
    DevOps Engineer
    $110,000 to $140,000

    CareerBuilder.com

    BAE Systems
    Manassas, Virginia
    DevOps Engineer
    $92,290 to $156,860

    Dice.com

    Rackner
    Falls Church, Virginia
    Software DevOps Engineer
    $90,000 to $140,000

  • How Network APIs Will Finally Realize the Potential of 5G Slicing

    How Network APIs Will Finally Realize the Potential of 5G Slicing

    The applications used by people and businesses today run over the top of the network. That is, they use the network to transmit data from one point to another but don’t interact with the network in any way.

    As those applications get more advanced, that comes with a risk. If the network isn’t provisioned adequately, a self-driving car, for instance, might suddenly lose connectivity and freeze in the middle of an intersection.

    That’s why developers are progressively realizing they’re going to require more from the network if they are to create revolutionary new applications. But the catch is they’re also not network specialists.

    Instead, they yearn for quick and simple ways to tap into and onboard 5G network capabilities within their applications — to dynamically adjust connectivity speeds based on real-time conditions, for example. That’s where network application programming interfaces (APIs) enter the picture.

    In 2023, the telecoms industry committed to unprecedented levels of openness with the announcement of the GSMA Open Gateway initiative and the growing popularity of the CAMARA project.

    In 2024, there is an expectation that there could be even more momentum around and demand for open network APIs as developers start to get real access to them — and begin to explore the potential of leveraging specialized network capabilities, delivered through techniques such as network slicing for their enterprise and consumer applications.

    What are Network APIs and How Will They Be Used?

    A network API is like any other API that allows for two or more applications to communicate with each other. It’s just that, in this case, one of those applications is the network itself.

    This is possible because today’s cloud-native 5G networks are fundamentally software-based, meaning they are also programmable through APIs and other software development tools. So unlike the networks of years ago, which were more hardware-dependent and closed in nature, developers can now get easy access to deep functionality and data within the network.

    Through a network API, applications and networks can share information about their status and needs, allowing for optimizations to be made on either side. The network could signal to a drone or autonomous vehicle where other related devices are operating or whether congestion is likely to occur in a given area, enabling on-the-fly route changes to maintain optimal performance. Or the application could use that information to request specialized capabilities from the network in certain situations, such as low-latency connectivity or more uplink capacity.

    The ability to deploy specialized network capabilities for specific applications in specific locations may sound familiar. It’s essentially the promise of network slicing, which was promoted heavily in the early days of 5G rollouts but never really caught on as expected.

    This is largely because network slices have to be planned for and provisioned well in advance — a dealbreaker for applications that need to manipulate parameters such as quality of service based on real-time conditions.

    Network APIs change that, providing access to specialized network capabilities in a dynamic, automated way — whether by spinning up a network slice or through the use of other telecommunications tools. The emerging applications of tomorrow will increasingly require such specialized network capabilities.

    Consider beyond visual line of sight (BVLS) drones that are operated remotely by a person hundreds of kilometers away. As the drone travels, it will need different network capabilities at different parts of the journey based on the unique conditions it encounters along the way.

    Deutsche Telekom has been working to deploy network APIs for this very scenario, which includes APIs for location verification (for more precise tracking of the drone’s position) as well as “quality on demand,” so that as it passes over highly congested areas where thousands of people are also using up network capacity, the drone can get greater prioritization to ensure it doesn’t fall out of the sky.

    That’s just one potential use case. Network APIs can open up innovations for industrial robots, real-time streaming of immersive video using multiple cameras, latency-sensitive applications like VR and cloud gaming, and much more.

    Creating a Network-Powered System Ecosystem

    APIs can help foster a network-powered ecosystem of digital innovation that brings benefits to everybody involved. By being able to leverage specialized network capabilities on demand, developers can create innovative applications and experiences for their customers — transforming their ideas into real solutions.

    Existing applications can also be enhanced for better performance, such as drones that can reliably transmit high-definition video from any location and under any circumstances to improve the situational awareness of first responders and public safety agencies.

    For the communication service providers (CSPs) who operate the networks, these APIs will help deliver a better return on investment for their 5G infrastructure. Revenue growth for traditional communications services in both the consumer and enterprise markets is limited by an unwillingness to pay more for those services and the perception that value lies in the applications rather than the network.

    Thus, the need for CSPs to develop new revenue streams has never been greater. By charging developers for access to the network APIs — and by forging closer connections to the applications that will use the capabilities within the network — CSPs will be better able to generate monetizable value from their networks.

    What’s Ahead for Network APIs

    APIs have been around for more than two decades. The fundamental principles of network slicing have been talked about since the introduction of 4G. While these technologies have been around for years, they will come together in exciting new ways in 2024, enabling entirely new possibilities.

    In the year ahead, there will likely be a greater demand for specialized network capabilities among application developers. That demand will be driven by early digital adopters in industries such as oil and gas, automotive, industrial and high-tech manufacturing, public safety, security, gaming and entertainment, and others.

    But it’s important to note that no one company can make all this work. There needs an ecosystem of companies coming together. Developers need to demand it, and CSPs need to build systems and platforms to support it.

    Infrastructure vendors will play a role as well, with network as code platforms to provide easy access to network APIs — serving as the bridge that enables greater levels of collaboration, innovation and mutual growth so everybody can harness the full potential of 5G networks.

  • How To Get Cash

    How To Get Cash

    how-to-get-cash