devopsy.kinsta.cloud

Category: IT as Code

  • Cloud Orchestration and its Impact on DevOps Teams

    Cloud Orchestration and its Impact on DevOps Teams

    Cloud orchestration refers to the coordination and management of various interconnected cloud services and resources to automate and streamline complex IT processes. In simple terms, it is the process of integrating, synchronizing, and automating various cloud-based components to create a seamless and unified workflow. 

    Cloud orchestration aims to optimize the deployment, management, and use of resources in a cloud environment, improving efficiency, reducing costs, and ensuring that cloud services are delivered in a timely and effective manner. It is related to the concept of CloudOps (cloud operations), which uses cloud orchestration concepts to allow more efficient management of cloud resources. Cloud orchestration is a critical aspect of modern IT infrastructure management, as it enables organizations to manage and control their cloud resources more effectively.

    Difference between Cloud Orchestration and Cloud Automation

    Though the terms cloud orchestration and cloud automation are often used interchangeably, they have distinct differences. 

    Cloud automation refers to the process of automating individual tasks and processes within the cloud environment. It involves the use of scripts, templates and other tools to automate repetitive tasks, such as provisioning resources, deploying applications and configuring environments. The primary goal of cloud automation is to reduce the time and effort needed to manage cloud resources.

    Cloud orchestration is a broader concept that encompasses not only the automation of tasks but also the coordination and management of the entire cloud ecosystem. It involves the integration of various cloud services, tools and resources to create a unified, streamlined workflow. Cloud orchestration ensures that all components in the cloud environment work together seamlessly, automating complex processes and managing dependencies between tasks.

    In essence, cloud automation is a subset of cloud orchestration. While cloud automation focuses on automating individual tasks, cloud orchestration takes a more holistic approach, orchestrating multiple tasks and resources to achieve a higher level of automation and efficiency.

    How Cloud Orchestration Enhances DevOps Practices

    Increased Efficiency and Speed

    One of the main benefits of cloud orchestration in a DevOps context is the ability to increase efficiency and speed in the software development and deployment process. By automating and streamlining various tasks, cloud orchestration eliminates manual processes, reduces the potential for human error and accelerates the overall development cycle. 

    Improved Collaboration and Communication

    Cloud orchestration fosters better collaboration and communication between development and operations teams by providing a unified platform for managing cloud resources. This shared platform enables teams to work together more effectively, breaking down traditional silos and ensuring that all stakeholders have visibility into the development and deployment process. 

    Enhanced Infrastructure and Application Management

    Cloud orchestration simplifies the management of complex cloud infrastructure by providing a single, unified platform for cloud optimization—improving the management of resources, applications and services in the cloud.

     This centralized management approach enables organizations to more easily monitor, control and optimize their cloud environment, ensuring that resources are used effectively and that applications are running smoothly. With cloud orchestration, organizations can more easily scale their infrastructure to meet changing demands, ensuring that they have the resources they need when they need them.

    Improved Monitoring and Troubleshooting

    Cloud orchestration provides improved monitoring and troubleshooting capabilities, enabling organizations to more effectively identify and address issues in their cloud environment. With comprehensive monitoring tools and dashboards, teams can gain insight into the performance of their applications, identify bottlenecks and pinpoint potential issues before they become critical.

    Challenges of Integrating Cloud Orchestration With DevOps

    Despite the numerous benefits of cloud orchestration, integrating it into DevOps practices can present several challenges. Some of the common challenges include:

    • Complexity: Cloud orchestration involves the integration of various cloud services, tools and resources, which can be complex and time-consuming. Organizations may struggle with complexity, particularly if they lack the necessary expertise or resources to effectively implement and manage the solution.
    • Resistance to change: Implementing cloud orchestration requires a change in mindset and approach to software development and deployment. As your organization migrates more systems to the cloud, some team members may be resistant to adopting new processes and tools, making it difficult to fully embrace and realize the benefits of cloud orchestration.
    • Security concerns: As with any cloud-based solution, security is a critical concern when integrating cloud orchestration into DevOps practices. Organizations must ensure that their solution is secure and that they have the necessary policies and procedures in place to protect their sensitive data and resources.
    • Cost and resource constraints: Implementing and managing a Cloud Orchestration solution can be resource-intensive, requiring significant investment in infrastructure, tools, and personnel. Organizations must carefully consider the costs and resources required to implement cloud orchestration and determine whether the benefits outweigh the investment.

    Best Practices to Integrate Cloud Orchestration Into DevOps

    To successfully integrate cloud orchestration into DevOps practices and overcome the challenges mentioned above, organizations should consider the following best practices:

    • Assess your organization’s readiness: Before implementation, evaluate your organization’s readiness for change. This includes assessing your existing infrastructure, processes and tools, as well as your team’s willingness and ability to adopt new practices and technologies.
    • Develop a clear strategy: Develop a clear strategy for integrating cloud orchestration into your DevOps practices. This should include defining your goals and objectives, identifying the tools and resources you will need and establishing a timeline for implementation.
    • Choose the right tools and technologies: Select the appropriate tools and technologies that best meet your organization’s needs and requirements. Consider factors such as ease of integration, scalability, security and cost when evaluating potential solutions.
    • Train and educate your team: Ensure that your team has the necessary knowledge and skills to effectively implement and manage cloud orchestration. This may involve providing training and education on new tools, processes and best practices, as well as fostering a culture of continuous learning and improvement.
    • Monitor and measure success: Continuously monitor and measure the success of your implementation. This includes tracking key performance indicators (KPIs), such as deployment speed, resource utilization and application performance, to ensure that your solution is delivering the desired results.

    Conclusion

    Cloud orchestration is an essential tool for organizations looking to streamline and optimize their IT infrastructure, particularly in the context of DevOps practices. By automating and coordinating complex cloud processes, organizations can improve efficiency, speed, collaboration and overall performance. 

    However, successfully integrating with DevOps can be challenging, requiring a clear strategy, the right tools and technologies and a commitment to continuous improvement. By following the best practices outlined in this guide, organizations can overcome these challenges and fully realize the benefits.

     

     

  • FinOps Gaining Ground, But Progress is Slow

    FinOps Gaining Ground, But Progress is Slow

    A CloudBolt Software survey found that while the majority (98%) of respondents worked for organizations with a formal FinOps team (82%) or are actively considering adding one (16%), realizing value from FinOps is slow. More than half of existing FinOps teams (54%) were formed just 12 months ago or less, the survey also found.

    The trouble is, only one in of 500 respondents claimed to achieve any material value from FinOps to date. More than three-quarters of respondents (76%) said they will have to wait two to three years to see real FinOps-driven results.

    The survey polled 500 executives, engineers and developers at companies with over 5,000 employees in the U.S., Canada, United Kingdom and Australia. It was conducted by Wakefield Research on behalf of CloudBolt Software, a provider of a platform for managing distributed computing environments.

    A total of 45% of respondents also questioned FinOps efficacy in the real world. Specifically, 15% flagged FinOps as being “theoretically easy but harder in practice,” with another 13% regarding it as “much ado about nothing.” Another 10% said it is “nothing more than a suggested framework,” while 7% labeled FinOps as “a necessary evil.”

    Nevertheless, a full 89% also described FinOps as the silver bullet for reining in the complexity of cloud cost management, with 68% noting that FinOps is among their organization’s most strategic priorities for 2023. The average size of a FinOps team is now 4.1 people, with the “director level” being the senior-most leader on the team 53% of the time, the survey noted.

    A total of 71% noted that achieving this year’s IT goals without a FinOps practice would pose a significant challenge, with 74% reporting that FinOps is now on par with ITOps, DevOps, SecOps and other IT disciplines.

    In addition, 71% of respondents said funding for FinOps initiatives increased in 2023, with 58% reporting key performance indicators (KPIs) and metrics to the C-suite or board of directors.

    CloudBolt Software CTO Kyle Campos said it’s clear that when it comes to reining in costs, large enterprises are struggling to effectively manage IT across multiple silos. In many cases, organizations were investing heavily in IT before and during the COVID-19 pandemic to drive digital business transformation initiatives without many cost controls being put in place, he added.

    Now that organizations are encountering economic headwinds, many chief financial officers are now asking IT leaders to be a lot more efficient, noted Campos.

    Developers, in particular, have for years been provisioning cloud infrastructure resources with little to no oversight. Unfortunately, developers are prone to leaving the proverbial lights on by, for example, leaving application development environments running over a weekend or simply forgetting that a virtual machine has been left to run for weeks—sometimes even months.

    Developers are also not especially good at alerting IT leaders of possible spikes in consumption due to, for example, a data-intensive workload being constructed. No finance team likes to be surprised by a monthly bill for a cloud service that is twice as much as the previous month.

    The one thing that is certain is that time is of the essence. FinOps, at its core, may not necessarily be a new idea, but IT organizations that fail to practice it may soon find themselves being held more accountable than any time in recent memory.

  • HashiCorp Acquires BluBracket to Extend Secrets Management Reach

    HashiCorp Acquires BluBracket to Extend Secrets Management Reach

    HashiCorp this week revealed it has acquired BluBracket to add a set of scanning tools for discovering static secrets to its portfolio.

    James Bayer, senior vice president of research and development for the Secure product line at HashiCorp, said the existing Vault platform for managing secrets is designed to enable developers to manage them as they build applications. BluBracket has developed a secrets management tool that makes it possible to discover secrets in applications that have already been deployed in production environments, he said.

    The amount of secrets management-related technical debt many organizations have can be enormous, especially if they’ve been deploying applications for decades. IT teams need a tool that discovers secrets in applications that, in many cases, were deployed by application developers that are no longer with the company, Bayer added.

    The BluBracket tools make it possible to discover those unmanaged secrets even before efforts are put in place to improve application security, he noted.

    HashiCorp will initially integrate BluBracket’s functionality into HashiCorp Vault to expand HashiCorp’s zero-trust capabilities, and add detection and remediation workflows via additional capabilities expected later this year. That’s critical, because for decades, developers have been storing secrets in applications and forgetting to remove them before an application is deployed.

    In general, HashiCorp is moving to transform its Vault platform into an orchestration engine for managing secrets regardless of where those secrets might be stored, said Bayer. That approach will enable developers to build applications and store their secrets on, for example, the Amazon Web Services (AWS) cloud in a way that can be centrally managed via the Vault platform, he added.

    Most organizations today are at varying stages of embracing DevSecOps best practices to improve software supply chain security. It’s not clear how readily secrets management is being embraced as part of those modernization efforts, but as cybercriminals routinely scan for application secrets stored in clear text, the need to encrypt secrets becomes a higher priority.

    The core DevSecOps issue most organizations are wrestling with is how involved cybersecurity teams should be in application development. There’s clearly a concerted effort to push more responsibility for application security further left toward developers. The challenge is, even when those tools are provided, it’s not clear that developers can distinguish between the severity of one vulnerability versus another.

    Conversely, most cybersecurity teams don’t really understand how modern applications are developed. That doesn’t necessary mean cybersecurity professionals need to dive deep into application development workflows, but it does mean they should, at the very least, understand how applications are constructed to make sure the appropriate security guardrails have been put in place.

    Regardless of approach, it’s clear there is a need for some type of centralized security function to better ensure application security. Unfortunately, the cultural divide between application developers and cybersecurity teams remains fairly wide. The DevSecOps journey ahead will be long, as each organization determines how best to bridge that gap when the supply of available cybersecurity expertise remains constrained.

  • Survey Surfaces Raft of Enterprise IT Challenges

    Survey Surfaces Raft of Enterprise IT Challenges

    A survey of  enterprise IT leaders found less than a third (32%) are extremely confident that they have the right technology, processes and people in place to execute an effective approach to IT management.

    The survey, conducted by Rocket Software, polled 275 U.S. IT leaders in organizations with more than 1,000 employees. A full 93% of IT leaders are also committed to maximize the value of investments in existing platforms.

    As a result, the top priorities for IT leaders are hybrid cloud computing (65%), data and content management (68%) followed by DevOps and infrastructure and application modernization, tied at 58%, and automation (57%).

    A total of 62% noted they have a much greater focus on efficiency due to the economic landscape, with faster DevOps processes, automated processes and increasing overall output as the top three improvements that would be most impactful for increasing efficiency.

    The survey also suggested many organizations still have much work to do to achieve those goals, with 63% of respondents spending anywhere from six to 15 hours on manual data entry and analysis each week.

    Phil Buckellew, president of infrastructure modernization for Rocket Software, said most organizations are still trying to determine the right level of DevOps to adopt. Few organizations have implemented DevOps workflows on an end-to-end basis, with many employing a mix of DevOps and waterfall processes to build and deploy applications across a hybrid cloud computing environment, he noted.

    Overall, IT leaders are most worried about improving overall IT performance (60%), data security (50%), process risk and compliance (46%) and the need to improve agility (41%), the survey found. Respondents also noted that they measure success within their IT organization by increased efficiency (71%), optimized resources (67%) and reduced risk (63%).

    The survey makes it clear that, despite challenges, enterprise IT organizations are committed to hybrid cloud computing as they become more comfortable with using various platforms that are fit for purpose, said Buckellew.

    Mainframes, for example, continue to play a major role in running online transaction processing (OLTP) applications alongside analytics applications that are now being infused with artificial intelligence (AI) capabililities, noted Buckellew.

    A quarter of survey respondents also identified providing cloud applications with access to mainframe data as an area where they need additional tools, followed by automation (22%).

    The biggest automation obstacles are the complexity of implementing automation (18%), resistance to process change among workforce (18%) and lack of skillsets to implement automation (18%), the survey finds.

    As always, the biggest challenge in enterprise IT environments is often simple inertia. Organizations that have been building and deploying applications on mainframes, for example, have been relying on waterfall processes for decades. Many of them have now adopted DevOps processes to varying degrees, but few have completely replaced legacy approaches to building and deploying software, noted Buckellew.

    It’s not likely the management of complex hybrid cloud computing environments will be simplified any time soon, but progress continues to be made. Soon, AI may automate many existing manual tasks. In the meantime, however, the number of enterprise IT organizations standardizing on a single IT platform remains few and far between.

  • Bionic Extends Application Security Posture Management Platform

    Bionic Extends Application Security Posture Management Platform

    Bionic this week added a pair of tools to its application security posture management (ASPM) platform that make it simpler to triage threats based on severity and attach a risk score.

    Josh Cho, senior director of global systems engineering at Bionic, said the Bionic Signals and Business Risk Scoring tools ingest data from third-party security tools to provide analytics capabilities. The first two vendors with which Bionic has integrated its ASPM platform are Wiz and Sonatype.

    The goal is to partner with additional vendors that provide unique cybersecurity capabilities that don’t compete with one another, said Cho.

    The agentless Bionic ASPM platform enables organizations to manage application risks by continuously collecting data from services and their dependencies, application programming interfaces (APIs) and DevOps data flows both in pre-production environments and after applications are deployed. Bionic then assesses any changes made to those environments based on a set of cybersecurity policies it provides. If an issue is discovered, the platform will create an alert informing the appropriate development team of best practices that eliminate the issue.

    While there is a lot of effort being made to shift more responsibility left toward application developers, there is often not enough cybersecurity context provided, said Cho. Bionic’s ASPM platform aggregates data from multiple tools to enable DevSecOps teams to better prioritize their remediation efforts, he added.

    It’s not clear how much organizations have embraced DevSecOps best practices, but one of the issues that needs to be addressed is the often-conflicting alerts generated by the various tools being used. Bionic is making a case for an ASPM platform that synthesizes data from multiple sources to streamline DevSecOps workflows.

    One way or another, more organizations will be embracing DevSecOps to better secure their software supply chains as more regulations are mandated. The challenge they face today is that most application developers—and the DevOps teams that support them—don’t have a lot of cybersecurity expertise. As a result, it becomes difficult to discern which vulnerabilities require immediate attention and which can be addressed in a regular update. In some instances, an alert generated by a cybersecurity team may not even been relevant—because the application in question is not internet-facing or the impacted module has not been loaded.

    In fact, it’s that very lack of context that often results in application developers disregarding the alerts generated by cybersecurity teams. Whenever there is a breach, however, cybersecurity teams always demand to know why their alert was ignored.

    No developer, of course, deliberately sets out to build and deploy vulnerable applications. In the race to meet delivery deadlines, there are always going to be tradeoffs. The issue then becomes keeping track of the cybersecurity technical debt that accumulates over time. An ASPM solution provides a means to keep track of that debt to enable DevSecOps teams to keep the risk in perspective.

  • Survey Sees Value But Limited Understanding of Platform Engineering

    Survey Sees Value But Limited Understanding of Platform Engineering

    Platform engineering is emerging as method for managing DevOps at scale, but a survey suggested that many organizations are still not clear on the concept.

    A survey of 100 DevOps engineers, platform engineers, developers, site reliability engineers and IT managers conducted by Civo, a cloud service provider, found 85% of respondents work for organizations that have partially or fully embraced a DevOps culture, with nearly two-thirds (65%) identifying platform engineering as the next evolution of DevOps. Nearly, a third (30%) of respondents work for organizations that are already currently evaluating whether they should adopt platform engineering.

    Overall, the survey found 50% of the respondents at organizations that have adopted platform engineering reported improved standardization, with 43% also seeing faster product delivery.

    However, only 41% of the respondents in DevOps roles that were familiar with platform engineering said they had a moderate to high level of familiarity with the concept.

    Saiyam Pathak, director of technical evangelism at Civo, said the survey makes it clear that, in terms of understanding how platform engineering best practices should be implemented, there is need for more clarity. Many organizations initially adopted DevOps to spur innovation, so any approach to centralization shouldn’t come at the expense of developer productivity, he noted.

    Historically, DevOps adoption of DevOps workflows in most organizations has been driven from the bottom up. As a result, it’s fairly common for multiple application development teams within an organization to have adopted multiple DevOps platforms to manage workflows. Advocates for platform engineering are making a case for eliminating many of those redundant platforms in favor of, for example, a single continuous integration/continuous delivery (CI/CD) platform that serves as a corporate standard.

    At the core of those efforts is the assumption that centralization will reduce costs by eliminating redundancy. At a time when more organizations than ever are sensitive to the cost of IT, there is always going to be a natural tendency to rationalize platforms. Challenges arise, however, when centralization results in a loss of flexibility. Many of the teams adopt DevOps because they want to be able to add and replace tools as they see fit. If there is a corporate standard that narrows their tool options, those teams may start to look for ways to do an end-run around the corporate standard.

    The philosophical IT battle between advocates for centralization and proponents of decentralization has been around since the first PCs showed up in enterprise IT environments. As always, organizations need to strike a balance between both extremes, said Pathak.

    It’s not clear how much platform engineering might accelerate the pace at which applications are built and deployed, but the total cost of DevOps should decline as various tools and platforms are consolidated. The challenge, of course, is that centralizing DevOps workflows is likely to disrupt the application development workflows on platforms that may about to be rationalized.

    Regardless of what platforms become the corporate standard, the one thing that is certain is the cultural challenges associated with successfully making that transition will loom large within most organizations.

  • How to Empower DevSecOps in a Complex Multi-Cloud Landscape

    How to Empower DevSecOps in a Complex Multi-Cloud Landscape

    Organizations are embracing cloud-based application delivery for speed of delivery and scale. However, the proliferation of multi-cloud systems to access and maximize the cloud’s capabilities is driving complexity in IT environments. Many organizations do not consider how multi-cloud adoption is expanding their attack surface—and the risk is growing: The 2023 CrowdStrike Global Threat Report found cloud exploitation cases grew by 95% year-over-year and cases involving threat actors targeting cloud environments were up 288% from a year prior.

    The expansion of cloud infrastructure and services has increased the pressure on organizations to protect assets within their multi-cloud environments. To alleviate this burden, more businesses are turning to DevSecOps, a practice that incorporates security at an earlier point in the development life cycle. This practice of shifting left helps improve the quality and reduces risk of applications, as well as makes the delivery of these applications more efficient since any potential issues are found earlier in the development process.

    DevSecOps is being adopted rapidly by organizations today to address the expanding array of threats and increasingly sophisticated attacks targeting multi-cloud environments. However, securing the cloud can be tricky due to its dynamic nature and multi-cloud makes shift left security even more complex. For DevSecOps to truly be effective, here are three things that organizations should consider doing.

    1. Strive for Complete Visibility in a Multi-Cloud Environment

    It is important that DevSecOps teams have a comprehensive understanding of their multi-cloud environment. Without it, they will not be able to identify a variety of security risks including vulnerabilities, privileged credentials, misconfigurations and other threats that may leave their organization’s cloud assets vulnerable.

    The best way to get full visibility across multi-cloud environments is through a cloud security posture management (CSPM) tool. With a CSPM tool, DevSecOps teams can identify misconfigurations and proactively detect threats. In addition, DevSecOps teams should also use a cloud infrastructure entitlement management tool (CIEM) to manage identities across all of their cloud infrastructure resources. The primary goal of a CIEM tool is to mitigate the risk that comes from the unintentional and unchecked granting of excessive permissions of user credentials.

    2. Visibility and Compliance Do Not Guarantee Security

    Organizations need to develop a comprehensive security strategy to mitigate issues within the development process. This may include implementing tools, automation and standards to enable developers to follow the desired security behavior. These approaches reduce developer friction, as well as diminish the likelihood that unsafe or default configurations will be used. Historically, DevOps teams have pushed back on integrating security since their concern is that it slows down the development lifecycle. However, DevSecOps is gaining traction in recent years because organizations are realizing integrating security sooner in the development lifecycle is more efficient than reactively patching problems as they arise.

    A tool that DevSecOps teams should look to leverage is cloud workload protection (CWP) because it offers breach protection for workloads, containers and Kubernetes, while enabling them to continue to build, run and secure applications with speed and confidence.

    3. Create Consistency With Security Tools

    Ideally, organizations should opt for a single platform that consolidates capabilities such as CSPM, CWP and CIEM. The reason for consolidation is to eliminate security gaps from having multiple security solutions. As a result, DevSecOps teams should turn to cloud-native application protection platform (CNAPP) tools to create more consistency within the multi-cloud environment.

    Securing multi-cloud environments can be complex. By empowering DevSecOps teams using these best practices, organizations will be able to move faster than today’s adversaries and have the agility to quickly adapt to present and future cybersecurity challenges in their multi-cloud environments.

  • How to Avoid Risk When Using Multiple Low-Code Platforms

    How to Avoid Risk When Using Multiple Low-Code Platforms

    Organizations are still increasing their use of low-code/no-code (LCNC). But this adoption isn’t always consolidated around one tool—frequently, multiple low-code/no-code platforms are used under the same roof. In fact, Gartner predicts that by 2024, 75% of large enterprises will be using at least four low-code development tools for both IT application development and citizen development initiatives.

    Utilizing multiple low-code/no-code platforms simultaneously introduces some security concerns. This is partially due to a lack of standard policies to govern different platforms in the same way. Low-code platforms are often incompatible with traditional IT security processes, like vulnerability scanning, manual code reviews and runtime security monitoring. Organizations going all-in on citizen development need safe ways to use low-code/no-code platforms. So, how can they safely enable this innovation without hindering productivity?

    I recently met with Michael Bargury, CTO and co-founder, Zenity, about securing LCNC systems. Bargury, who oversees the OWASP Low-Code Top Ten list, has significant insight into both the benefits and drawbacks of low-code/no-code platforms. Below, we’ll review the potential risks of using multiple low-code platforms and consider ways to mitigate these concerns.

    Why Companies Have Multiple Low-Code Platforms

    Interest in low-code has been rising, and low-code/no-code adoption continues to accelerate across enterprises. According to Bargury, large enterprises often don’t get a choice in the matter—low-code tools are arising organically, and it’s challenging to keep a lid on their proliferation.

    One way this occurs is that low-code becomes embedded into the SaaS platforms everyone already uses. Software platforms integral to business operations, like Salesforce, Microsoft Office and ServiceNow, have arguably mutated into low-code platforms, making them more like cloud providers than SaaS vendors, said Bargury.

    The other way low-code platforms emerge is through bottom-up transitions, says Bargury. This could be a specific knowledge worker working in a subset of the business to automate a domain-specific operation or integrate various tools. Then, there are the platforms, like OutSystems, Mendix or Mulesoft that specifically target professional developers.

    Organizations going all-in on citizen development may build a center of excellence and focus efforts on a single platform. And low-code platforms targeting developers will sometimes encourage more consolidation. Yet, “different platforms solve different use cases better,” explained Bargury. As a result, you will usually have a few converging in the same enterprises.

    Potential Security Concerns of Multiple Low-Code Platforms

    The emergence of low-code is similar to the bring your own device (BYOD) movement. IT and security leaders fought to avoid it at one point, but nowadays, everyone does it. So, what are the security implications if low-code becomes similarly ubiquitous? Well, no matter how it’s generated, low-code-bred programs are still applications susceptible to the same logical problems. And unfortunately, compared to your typical traditional code development life cycle, low-code development is fraught with discrepancies, says Bargury.

    Immature CI/CD Pipelines

    Some platforms do not offer the kind of mature CI/CD process one would expect from a software development platform. For example, there may be no way to create tests or separate your environments. Since there’s no coherent and consistent way to push code from development into production, you lack a way to apply secure development across platforms. “You don’t have a way to ensure every piece of software is up to your standards,” said Bargury.

    Opaque Underyling Codebases

    In traditional software development, you apply your own security reviews to ensure applications don’t contain risks. This includes shift-left scanning, security gates, manual reviews to catch mistakes early on and runtime scanning to catch unknown vulnerabilities in production. But there aren’t always parallels in low-code development. Low-code solutions typically have their own way of doing things with fewer standards, and they avoid exposing the underlying code and Git, said Bargury.

    Lack of Visibility

    As such, with low-code obfuscation, you lose a degree of visibility into how an application runs. Logs may be insufficient or wholly inaccessible. It’s also tricky—or at times impossible—to set up runtime monitoring, let alone scan various platforms. This means that low-code users can’t leverage powerful observability tools to identify errors and remediate security holes.

    Lack of Unified Policies

    Finally, establishing common authorization and permissions across multiple low-code development platforms is another hurdle. Since low-code vendors have their proprietary building blocks, you’re unable to leverage something like OPA or Kyverno to create and unify policies. Lacking shared policies across tools makes it challenging to verify that best practices have been implemented, says Bargury.

    How to Secure Multi-LCNC

    Low-code can grant much creative potential. But, knowing the above risks, what should IT be doing to reduce risks around low-code—especially when using multiple platforms? Well, Bargury shared several steps to help cybersecurity leaders start safely addressing the emergence of increasingly low-code capabilities.

    1. Take low-code development under the application security umbrella. First, low-code must be brought under the security umbrella, if it isn’t already. “It should be part of their mandate,” said Bargury. Shift the responsibility to professionals well-trained in resolving threats.
    2. Understand your surface area. As a basic security tenant, you can’t secure what you don’t know. Thus, Bargury recommends increasing your visibility into each low-code platform by collecting logs when possible and centralizing your analysis.
    3. Create automated guardrails. Next, it’s critical to identify your risks and set guardrails for your low-code users—especially when citizen development is involved. The OWASP framework provides a good overview of common risks and mitigation advice across robotic process automation (RPA), integration and low-code. In general, it’s important to design permissions with the rule of least privilege in mind. This can help reduce the chance of vulnerabilities like LCNC-SEC-03: Data Leakage and Unexpected Consequences and LCNC-SEC-01: Account Impersonation.
    4. Address gaps within the development life cycle (SDLC). Lastly, low-code platforms often provide the building blocks to secure applications, but it’s still up to you to ensure they are safely used. Cybersecurity teams should continually audit the low-code SDLC to ensure holes don’t persist.

    You’re Responsible for Securing Low-Code Development

    Low-code development platforms aren’t 100% safe from harm. It’s not out of the question for hackers to abuse low-code platforms and turn them against their owners. For example, Microsoft’s Detection and Response Team (DART) reported how a hacker group used entry to a low-code tool to remain hidden within an organization for six months, using credential stuffing to access an administrative account. By creating automations, they were able to use internal discovery tools and exfiltrate secrets and data that could have been used for privilege escalation.

    As you can see, there are legitimate concerns for low-code, especially at scale. However, security responsibility is not always that transparent. To date, there isn’t an equivalent of a shared cloud responsibility model in the realm of low-code development. As such, at the end of the day, you need to take the reins to own the applications that you build and ensure everything is secure.

  • Choosing the Right Software Deployment Tools

    Choosing the Right Software Deployment Tools

    Imagine this scenario: After investing countless hours in developing your software, it is finally ready for deployment. Now, you must select the appropriate software deployment tools to guarantee a seamless release.

    This article will guide you through the concept of software deployment and discuss various tools that cater to different needs—from dedicated deployment tools to comprehensive CI/CD pipeline solutions and GitOps approaches. By understanding these categories and their benefits, you’ll be well-prepared to make an informed decision on which tool is the best fit for your organization’s needs.

    What is Software Deployment?

    Software deployment plays a crucial role in the software development life cycle. It involves packaging, distributing and installing an application on target systems or environments, aiming to make your software accessible and usable for end-users seamlessly.

    In today’s fast-paced world, companies must be able to deliver applications rapidly and reliably. A well-planned software deployment strategy ensures that new features reach users promptly while minimizing downtime and errors during updates.

    What to Look For in a Software Deployment Tool

    When selecting the ideal software deployment tool, consider the following factors:

    • Automation: The tool should automate complex software deployments, making the deployment process faster and more efficient.
    • Continuous deployment: Continuous deployment tools allow you to deploy software repeatedly, ensuring consistent deployments. Choose a tool that automates release management and integrates automated builds throughout the development process.
    • Scalability: The tool should be capable of handling large-scale deployments and distributing software across multiple servers. Opt for a tool that enables applications to deploy to multiple servers simultaneously.
    • Integration: The tool should integrate with version control and other third-party tools, making the deployment process seamless. Look for a tool that integrates with modern DevOps processes and connects automated builds to configuration management.

    Full CI/CD Tools

    Bamboo

    Bamboo by Atlassian is a robust tool that integrates seamlessly with other Atlassian products, such as Jira and Bitbucket.

    It offers first-class support for multiple languages and platforms while providing built-in deployment projects for smooth releases.

    GitLab CI/CD

    GitLab CI/CD, an integral part of GitLab, simplifies pipeline management using YAML configuration files stored within your project repository.

    This approach enables easy collaboration among team members while ensuring consistent build environments across all stages of development.

    Codefresh

    Codefresh is a cloud-native solution designed specifically for Kubernetes deployments, It provides a modern interface to manage pipelines visually, along with advanced real-time debugging capabilities.

    Dedicated Deployment Tools

    Jenkins

    Jenkins was originally conceived as a continuous integration (CI) tool, but many organizations use it mainly for deployment. It is an open source automation server that provides support for building and deploying software projects, as well as to schedule and run tasks at regular intervals. Learn more about Jenkins in this in-depth blog post.

    Harness

    Harness is an intelligent software delivery platform that simplifies deployments through automation and machine learning. Their continuous delivery-as-a-service (CDaaS) approach helps you deploy faster while minimizing risks and errors.

    AWS CodeDeploy

    If you’re using Amazon Web Services (AWS), AWS CodeDeploy might be a perfect fit for your needs. This completely managed service automates code deployments to any instance or serverless Lambda function in AWS, guaranteeing consistent results every time.

    Spinnaker

    An open source project backed by Netflix and Google, Spinnaker offers powerful multi-cloud continuous delivery capabilities for deploying applications at scale across various cloud providers like AWS, GCP, Azure, Kubernetes clusters, etc.

    GitOps Tools

    Argo CD

    Argo CD is a declarative, Kubernetes-native continuous delivery tool that uses Git repositories as the source of truth for application definitions. It simplifies rollbacks, provides audit trails and enforces consistency across environments.

    Flux CD

    Flux CD, another Kubernetes-focused option, automates deployments by monitoring your code repository for changes and applying them to your cluster accordingly. Bonus: It supports multi-tenancy and integrates with Helm charts.

    Weave GitOps Core

    Lastly, Weave GitOps Core offers an open source foundation for managing Kubernetes applications using the power of GitOps workflows. This versatile tool can be extended to fit various use cases while maintaining simplicity in its core functionality.

    Conclusion

    There are many software deployment tools available that can help automate the software delivery process, reduce errors and improve collaboration between development and operations teams. From open source tools like Jenkins to cloud-native solutions like AWS CodeDeploy, each tool has its own strengths and features that make it suitable for different use cases.

    When selecting a software deployment tool, it is important to consider factors such as compatibility, automation, scalability, security, monitoring, deployment environment compatibility, integration with existing tools and support and documentation. By carefully evaluating these factors and choosing the right tool for your specific needs, you can ensure that your software deployment process is efficient, reliable and successful.

    Image Source: Freepik

  • Quali Adds Governance and Cloud Cost Control Tools to Automation Platform

    Quali Adds Governance and Cloud Cost Control Tools to Automation Platform

    Quali today revealed it added governance and cloud cost management tools to its Torque platform for automating IT infrastructure management.

    David Williams, senior vice president for market strategy at Quali, said the added governance tools will make it possible to enforce security, compliance and consumption policies as IT environments are launched using the automation blueprints that Torque enables IT teams to create.

    At the same time, IT teams can now also define consumption policies based on cloud runtime or regions employed within a cloud computing environment. In addition to taking advantage of dashboards to visualize consumption of cloud resources, IT teams can also use Torque to identify cloud waste including detached, inactive and overprovisioned instances. They can pause, right-size or tear down environments to reduce costs and eliminate the possibility of a billing surprise at the end of the month, noted Williams.

    Torque also enables IT teams to detect drift and then update live cloud environments to remediate any that fall out of scope, he added.

    Quali has been making a case for an environment-as-a-service approach to managing IT. That approach is based on a set of triggers for controlling infrastructure via a software-as-a-service (SaaS) platform that can be invoked either via an application programming interface (API) or a graphical user interface (GUI).

    In addition to providing a set of infrastructure provisioning guardrails that prevent mistakes from being made, Torque makes it possible to automatically deploy complete application environments on top of infrastructure provisioned as code using blueprints rather than relying on low-level Terraform scripts. The goal is to increase developer productivity by enabling IT teams to create self-service portals that developers can use to spin up environments.

    That approach is becoming more appealing as many organizations begin to adopt platform engineering as a method to centralize the management of DevOps workflows, noted Williams. In fact, as part of that effort, many organizations are starting to unify the management of cloud and on-premises IT environments, he added.

    While many developers routinely provision IT infrastructure using tools such as Terraform, many of them lack the cybersecurity expertise required to ensure cloud computing environments are configured properly. Developers also tend not to remember to de-provision cloud resources when no longer needed; over time, those factors contribute to unnecessarily increased cloud costs.

    Ultimately, the goal is to find ways to centrally manage IT environments to reduce costs and improve cybersecurity without inhibiting the pace at which developers are building innovative applications, said Williams.

    At the same time, as application environments become more complex, it is becoming even more challenging to provision and manage IT environments at a time when many organizations are reluctant to hire additional IT staff, he noted.

    One way or another, IT environments will become more automated. The issue is determining how best to organize the IT teams managing those environments as tasks that once required a lot of manual effort are increasingly automated.