devopsy.kinsta.cloud

Category: Features

  • Bitrise to Invest $3M in DevOps Cloud for Mobile Apps in EU

    Bitrise to Invest $3M in DevOps Cloud for Mobile Apps in EU

    Bitrise, a provider of a DevOps platform for building mobile applications, plans to invest $3 million to create data centers in the European Union (EU) that meet sovereign cloud requirements.

    Company CEO Barnabás Birmacher said Bitrise has spent much of the past year integrating its stack and consolidating the infrastructure it needs to support its platform in the U.S. Now, Bitrise is taking the next step toward ensuring that any data used to build a mobile application doesn’t leave the EU at a time when many organizations are either voluntarily deciding to depend less on IT infrastructure in the U.S. or are being required to use IT infrastructure in a specific geographic region.

    To satisfy those requirements, Bitrise is acquiring the server and storage infrastructure it requires, which is then housed in a data center facility in Amsterdam that is owned by a third-party provider. That approach ensures that at any point necessary those servers and storage systems can be moved to another data center, noted Birmacher.

    Regardless of location, the data centers will be based on the same Apple M4 and Linux-based infrastructure that Bitrise has built a DevOps platform on top of to streamline the building and deployment of mobile applications.

    It’s not clear how fragmented software engineering is about to become as teams are required to ensure that application development projects only access data located in specific regions. Many DevOps teams have been relying on software-as-a-service (SaaS) application platforms that are designed to scale out across multiple geographic regions as additional compute resources have been needed. With the rise of sovereign cloud requirements, however, providers of those platforms need to ensure that any data being accessed never leaves a specific region.

    That issue can be especially challenging for organizations that may have relied on highly distributed teams of developers that may reside in multiple countries.

    In fact, one of the reasons more organizations are relying on the managed DevOps services that Bitrise provides is to help minimize that complexity, said Birmacher.

    As the pace of mobile application development continues to accelerate, more organizations are looking to rely on managed DevOps services, added Birmacher. They simply can’t afford to not only only build a DevOps platform, but also maintain, update and secure it, he noted. That’s especially the case when it comes to building mobile applications simply because there isn’t a lot of forgiveness when it comes to, for example, having to rollback an application once it’s been made available in an app store, so ensuring that every test has been properly conducted is crucial, said Birmacher.

    Regardless of who actually manages a DevOps environment, the need to continuously update mobile applications created additional challenges. End users expect that new features and capabilities will be added at a regular cadence. The number of organizations that can afford to invest in their own DevOps environment, as a percentage of those building mobile applications, remains comparatively small. So for the bulk of them, the only way to ensure best software engineering practices are being consistently followed is, after all, to rely on a service.

  • Survey: Pace of Increased Adoption of GitOps Varies Widely

    Survey: Pace of Increased Adoption of GitOps Varies Widely

    A survey of 660 software development professionals finds 93% have embraced GitOps as a methodology for building and deploying software, with 68% planning to increase usage.

    Conducted by Octopus Deploy, a provider of an automation platform for releasing software, the survey finds another quarter (25%) plan to retain their current usage compared to 7% that plan to reduce or stop GitOps usage.

    Steve Fenton, director of developer relations for Octopus Deploy, said the survey also makes it clear that GitOps maturity levels also tend to vary considerably. For example, under one-third of organizations use GitOps across less than 20% of their production systems. The survey also finds only 35% of respondents that have adopted GitOps make use of continuous reconciliation and automatic rollback mechanisms. That suggests that many organizations might only be going so far as to house infrastructure-as-code (IaC) configurations alongside source within a centralized Git repository.

    GitOps, at its core, refers to the process of automating the provisioning and management of IT infrastructure using a set of best practices that extend to include IaC tools. Ideally, a GitOps workflow should ensure a system is managed declaratively, automatically pulls the desired state declarations from the source, stores that data in a way that enforces immutability and versioning, and then provides some way to observe those interactions.

    Once infrastructure is managed with code, it becomes easier to converge the management of IT operations and application deployment. Kubernetes, meanwhile, provides an ideal GitOps platform because it presents a standard set of application programming interfaces (APIs) that enable clusters to automatically pull code as required versus requiring an IT team to manually push code out to a platform.

    Regardless of the level of GitOps maturity, there tends to be a high correlation between adoption of GitOps and modern IT platforms such as Kubernetes, noted Fenton. In general, many organizations are typically inclined to rethink legacy processes whenever a new platform is adopted, he added. In fact, it’s not uncommon for a team that has adopted GitOps to deploy microservices-based applications to be working along software engineering teams that are using legacy approaches to deploy more monolithic applications, said Fenton.

    A GitOps workflow should ultimately make it simpler for IT operations to achieve continuous delivery of applications, a goal that has remained elusive despite the widespread deployment of continuous integration/continuous delivery (CI/CD) platforms. In fact, while CI is widely used to build applications, the percentage of organizations consistently using CD to deploy software has remained comparatively small.

    It’s not clear to what degree the rise of platform engineering as a methodology for managing DevOps workflows at scale might drive increased adoption of GitOps. The one thing that is certain is that as the pace of application development continues to accelerate in the age of artificial intelligence (AI), the need to revisit software engineering workflows will become apparent. The only issue to be resolved now is determining how much to revamp existing workflows versus opting to simply start over again from scratch.

  • Kusari Adds AI Security Tool to Inspect Code as Pull Requests Are Made

    Kusari Adds AI Security Tool to Inspect Code as Pull Requests Are Made

    Kusari has added an artificial intelligence (AI) tool that runs a security risk assessment every time an application developer makes a pull request.

    Company CTO Mike Lieberman said Kusari Inspector is designed to make it simpler for security to be shifted left toward application developers in a way that doesn’t impinge productivity.

    Most application developers care about security, but getting the information they need to ensure it has historically been problematic, said Lieberman. Kusari Inspector makes use of AI and dependency graph analytics to surface issues long before vulnerabilities and other structural flaws are incorporated into a software build, he said.

    Using a tool priced at $10 per seat per month, Kusari Inspector continuously learns about the codebase and individual application developer preferences, making it possible to generate instant, context-rich, annotated security reports with inline explanations for every new or updated pull request. Developers are then provided go/no-go guidance, remediation suggestions, and step-by-step instructions to mitigate risks such as exposed credentials, misconfigurations, typosquatted or maliciously named dependencies and prohibited licenses.

    In addition to identifying those issues, Kusari Inspector will also rank risky, low-trust, or vulnerable dependencies—direct and transitive—based on multiple data sources to provide developers with a deeper understanding of application security issues, said Lieberman. Developers via a natural language interface can also chat with Kusari Inspector to clarify findings, customize recommendations, and set security standards.

    Finally, Kusari Inspector will automatically generate and collect source data for a software bill of materials (SBOM) across all connected projects and repositories.

    The core Kusari platform leverages AI to identify dependencies and understand the blast radius of incidents using metadata it collects from throughout the software supply chain. That capability is now being extended further left to provide application developers with a tool that enables them to write more secure code.

    It’s not clear how much DevOps teams are investing in AI, but a recent Futurum Group survey finds that 41% of DevOps professionals expect generative AI tools and platforms will be used to generate, review and test code. A separate Futurum survey of cybersecurity leaders finds all are investing in software supply chain security, with application security posture management (ASPM) and DevSecOps automation and orchestration topping the priority list, followed closely by security composition analysis (SCA) tools, application programming interface (API) security and dynamic application security testing (DAST) tools. In addition, 30% of respondents expect to be piloting a software bill of materials (SBOM) initiative in the next 24 months/

    However, the source of the funding for these initiatives is becoming more of a shared responsibility, with only 21% of respondents reporting that security budgets are the sole source. In fact, half of the respondents (50%) noted that application development teams now own responsibility for application security.

    Overall, only 25% of respondents said there is limited collaboration with application development teams, resulting in occasional friction, compared to 59% that said there is good collaboration with room for improvement. Only 16% said there is a tight partnership based on shared goals.

    Hopefully, AI tools will continue to close that gap in a way that reduces the current level of stress felt today by all concerned.