devopsy.kinsta.cloud

Category: News

  • flox Unveils More Accessible Instance of Nix Framework

    flox Unveils More Accessible Instance of Nix Framework

    This week, flox launched a more opinionated implementation of the open source Nix framework that programmatically automates package management and system configuration.

    Fresh from raising an additional $16.5 million in funding, flox CEO Ron Efroni said the company will also make an enterprise edition of its namesake flox framework available later this year.

    The Nix framework has been available since 2003 and provides DevOps teams with a portable, fully isolated development, test and production environment along with a catalog and tools for managing software packages. There are more than 5,000 contributors to the platform, but Nix is based on a unique programming language that many DevOps teams have found challenging to master.

    The flox framework provides a higher layer of abstraction for invoking Nix, and provides a set of guardrails to make the framework more accessible to a wider range of DevOps teams, said Efroni.

    That approach will make it easier to share development environments and packages across teams, machines, individual developers and entire organizations. The framework also provides visibility into the software bill of materials (SBOM) for applications used in production environments to enable real-time vulnerability management and detection without scanning, noted Efroni. That capability makes it easier to discover dependencies spanning multiple architectures; many organizations today still try to track dependencies using spreadsheets and tools that don’t serve to make DevSecOps processes simpler to manage, he added.

    It’s not clear how many organizations are using Nix today, but Efroni said that as software development management continues to become more complex across multiple platforms and architectures, there is a clear need for a different approach to enabling portability at scale. The biggest obstacle is overcoming the psychological biases many DevOps teams have developed toward Nix over the last two decades, he noted. A more opinionated framework should reduce the overall fear factor associated with Nix, noted Efroni.

    Regardless of the frameworks employed, it’s become apparent that DevOps teams are struggling under the weight of all the code they must manage, much of it written in multiple programming languages. Many organizations that embraced DevOps early are now finding the platforms they deployed have become challenging to manage and maintain. As application environments become more complex, there is a need to modernize DevOps workflows. Less clear is whether those efforts might be focused on, for example, containers and serverless computing frameworks versus a framework such as flox that is designed to span multiple architectures and platforms.

    It might be a while before IT organizations develop a unified approach to application development and deployment, given all the preferences of individual development teams. However, with the rise of platform engineering, it’s apparent more organizations are trying to strike a balance between developer freedom and the need to reduce the total cost of DevOps. That cost continues to rise as additional software architectures and platforms are employed.

    In the meantime, flox plans to contribute to both Nix and its own more opinionated version of the framework in the hopes of one day making it easier to achieve that goal.

  • Atlassian Extends Scope of Jira Project Management Portfolio

    Atlassian Extends Scope of Jira Project Management Portfolio

    At the Atlassian Presents: Unleash event today, Atlassian announced it is adding a Jira Product Discovery application to its portfolio. Jira Product Discovery makes it easier for organizations to keep track of the ideas that drive software development initiatives.

    At the same time, Atlassian is making available Jira workflow and toolchain templates to make it simpler for software development teams to extend the scope and reach of the project management software they use to track those projects. Rather than each organization developing these templates, Atlassian is now providing them in a way that allows organizations to customize and extend them as they see fit.

    Finally, Atlassian also announced that an existing Jira Work Management tool will be made available for free through March 2024.

    Megan Cook, head of product for software teams at Atlassian, said these additions will make it easier for organizations to collaborate around software development projects that businesses increasingly depend on to drive revenue. The overall goal is to make it easier for multiple stakeholders of the projects to more easily collaborate with software developers that rely on Jira to manage those projects, she added.

    These latest offerings are part of an ongoing Atlassian effort to enable organizations to simplify collaboration and enable organizations to embrace value stream management (VSM) without having to acquire a dedicated platform. In some cases, organizations may decide to adopt a dedicated VSM platform, but a project management application should make it simpler for everyone in an organization to keep track of how software development projects are impacting the business, noted Cook.

    It’s not clear just how many businesses are aligning their internal processes around DevOps workflows, but as more of them realize how dependent they are on software, there is a clear need to collaborate more efficiently with software development teams. In fact, many organizations are now trying to adjust to the rapid rate at which software is being delivered thanks to the adoption of DevOps best practices. In some instances, updates to software are now being delivered faster than many businesses can absorb given the impact those changes have on digital processes.

    The irony is many business executives used to routinely complain about how long it took IT organizations to adjust as business conditions changed. Now, many businesses are rolling out additional digital capabilities via software updates that can be made multiple times a month.

    The rate at which organizations will collaborate across departments will naturally vary, but the days when each department was a fiefdom unto itself are coming to an end. There may even come a day when organizations will need to restructure as the walls that once separated various fiefdoms become more porous.

    One way or another, the way organizations are managed is evolving in the digital age. Organizations are employing software to pivot more frequently as business conditions evolve. Each new idea can not only be tracked but also quickly evaluated for feasibility given the level of software development resources required, noted Cook. The challenge and the opportunity is as much about changing the culture of an organization as it is about modernizing the processes used to build and deploy software.

  • Report Affirms Continued AWS Cloud Dominance

    Report Affirms Continued AWS Cloud Dominance

    A report published this week by Wiz, a provider of a cloud security platform, found more than half of organizations (57%) are using multiple clouds, with 22% currently using three or more platforms.

    However, the report also noted that 72% of all workloads are running on the Amazon Web Services (AWS) cloud. Among organizations that have more than one cloud platform, Microsoft Azure (41%) is the most common secondary platform (41%), while Google Cloud Platform (GCP) is the most used tertiary platform among organizations employing two or more clouds (44%).

    The report also noted 9% of AWS customers use managed database servers, compared to 87% in GCP and 82% in Azure. However, over 91% of companies also have non-managed database servers running in a cloud. In total, only 6% of companies use managed database servers exclusively, compared to 90% using a mix of managed and non-managed database servers, the report finds.

    The most widely deployed databases are PostgreSQL, Redis and MySQL, with 90% of organizations running at least one instance of a PostgreSQL server.

    Scott Piper, principal cloud security researcher for Wiz, said the report makes it clear that despite gains by Microsoft and Google, AWS remains the most dominant cloud service provider. Even after a decade, rival cloud service providers have not been able to overcome the first-mover advantage that AWS continues to enjoy. In many cases, a second or third cloud is being employed only because a single development team preferred it or an IT team assumed responsibility for it when their company acquired another organization using it, noted Piper.

    However, while most organizations have multiple accounts per cloud service provider, the report also found that the bulk of the application workloads are managed via only a handful of accounts, he added. That suggests more organizations are subject to higher levels of disruption in the event of an outage than many of them may realize, said Piper.

    One of the reasons so many organizations have a narrow range of accounts, of course, is they simply don’t have enough personnel. In fact, a general skills shortage also tends to limit the number of cloud platforms organizations might otherwise employ.

    Multiple cloud platforms also tend to exacerbate cybersecurity challenges. With the introduction of each additional cloud service, the overall size of the attack surface that needs to be defended expands. The Wiz report found 47% of organizations have at least one database or storage bucket publicly exposed to the internet. It can take less than 13 hours for cybercriminals to discover and access an exposed bucket with a guessable name, noted Piper.

    More challenging still are the number of application programming interfaces (APIs) that need to be secured as cloud service providers continue to add new services, he added.

    Ideally, organizations should be adopting a framework to harden privileges, encryption, authentication and connectivity and improve hygiene, otherwise known as PEACH, said Piper.

    Regardless of the approach to cloud computing, it’s apparent there’s still a long way to go before organizations are ready to embrace hybrid cloud computing spanning multiple clouds.

  • Appdome Integrates Mobile Security Platform With CircleCI CI/CD

    Appdome Integrates Mobile Security Platform With CircleCI CI/CD

    Appdome this week made available an integration for the continuous integration/continuous delivery (CI/CD) platform from CircleCI that promises to make it simpler to secure mobile applications before they are deployed.

    As a provider of a platform for securing mobile applications running on iOS and Android platforms, Appdome provides a runtime application self-protection (RASP) platform that, among other capabilities, provides code obfuscation, mobile data encryption, jailbreak detection, root detection, man-in-the-middle attack prevention, on-device anti-malware, anti-fraud, anti-cheat and anti-bot capabilities.

    The platform is now integrated with the Circle CI/CD platform via the Orb framework created by CircleCI to simplify integrations with third-party tools.

    Karen Hsu, senior vice president of mobile DevOps and security solutions for Appdome, said the Appdome Build_2Secure Orb for CircleCI is an example of a series of integrations the company plans to make involving DevOps tools and platform that will make it easier to apply DevSecOps best practices to the deployment of mobile applications. That’s critical because it’s not uncommon for teams using different DevOps platforms and tools to be involved in the development of the same application, she noted.

    A recent Appdome survey suggested consumers are about to force the DevSecOps issue for providers of mobile applications regardless of how mature their processes are. A full 94% of respondents said they would promote a brand if the mobile apps protected them versus 68% that said they’d abandon brands that offered no protection.

    Securing mobile applications is especially challenging because once an application is compromised, it’s relatively trivial for cybercriminals to also inject malicious code into other applications running on a mobile device. There are no automated remediation capabilities, so the best defense is to isolate applications in a way that prevents malware from executing in the first place, noted Hsu. At a time when it’s already clear cybercriminals will be using artificial intelligence (AI) platforms to launch attacks, organizations will not have the time required to remediate vulnerabilities before malware is activated, she added.

    That Appdome approach provides the added benefit of reducing tensions between developers and cybersecurity teams that otherwise would be requesting immediate fixes to mobile applications that have been compromised, noted Hsu. As more mobile applications are built and deployed, the overall goal should be to enable both teams to work collaboratively together without unnecessarily disrupting each other’s workflow, added Hsu.

    It’s not clear what percentage of the applications being built and deployed today are destined to run on mobile devices, but securing those applications clearly presents some unique challenges. Many of those applications are deployed on consumer-grade devices attached to wireless networks that are not especially secure. Cybercriminals are increasingly targeting these devices not only to access sensitive data but also because they often provide a gateway through which the rest of an IT environment can be compromised.

    The simple truth of the matter is, sadly, DevOps teams need to assume that most mobile applications are going to be running in the cybersecurity equivalent of a hostile environment where the odds are considerably stacked against them.

  • Voice.ai ‘Stole’ Code ¦ AWS Gets Filthier

    Voice.ai ‘Stole’ Code ¦ AWS Gets Filthier

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Alleged theft of GPL code, and Amazon will run its data centers on gas. (more…)

  • Cisco Bets on OpenTelemetry to Advance Observability

    Cisco Bets on OpenTelemetry to Advance Observability

    Cisco today announced a technology preview of a Cisco Full-Stack Observability Platform based on instances of open source OpenTelemetry agent software being advanced by the Cloud Native Computing Foundation (CNCF) to collect metrics, event, logs and distributed traces. The Cisco Full-Stack Observability platform will be available in June 2023.

    The platform, announced at a Cisco Live EMEA event in Amsterdam, Netherlands, will combine the capabilities of multiple Cisco platforms and technologies into a single offering.

    At the same time, the company also announced the bidirectional integration between its existing Cisco AppDynamics application life cycle management (ALM) tool and the Cisco ThousandEyes network monitoring platform beginning in April.

    Finally, Cisco is making available a Business Risk Observability offering to provide business risk scoring. Business Risk Observability combines capabilities of its Kenna Risk Meter tool—gained when Cisco acquired Kenna Security in 2021—with the ability to monitor business transactions through Cisco AppDynamics to provide better visibility into application security. In addition, Cisco has integrated its Panoptica application programming interface (API) management security tool and the Talos threat intelligence platform within the Business Risk Observability Platform.

    Carlos Pereira, a Cisco fellow and chief architect for strategy, incubation and applications at Cisco, said Cisco is moving to narrow the historic divide between application development and cybersecurity teams to enable organizations to adopt DevSecOps best practices and make it simpler to prioritize the remediation of vulnerabilities that are likely to have the most impact on the business.

    Like most providers of observability platforms, Cisco is betting that more applications will be instrumented as OpenTelemetry software continues to mature. Cisco is now the single largest contributor to this project, noted Pereira.

    OpenTelemetry will also play a critical role in improving application security as more applications become instrumented, he noted. In fact, a recent Cisco AppDynamics survey found more than three-quarters of respondents (76%) believed that DevSecOps is essential for organizations to effectively protect against a multi-stage security attack. However, only 43% reported their organization had started implementing DevSecOps workflows.

    Observability, of course, has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications, interest is rising in observability platforms that make it simple to investigate anomalies indicative of an issue that could disrupt an application environment. Most of those observability platforms are infusing those platforms with machine learning algorithms to surface those anomalies as part of an effort to augment the capabilities of a DevOps team.

    Regardless of the approach to observability, many organizations will soon be trying to determine whether to rely on existing monitoring tools that make it possible to track pre-defined metrics. In some cases, there may still be a need for that legacy approach to managing IT. Still, in other instances, it may be possible to rationalize some of those platforms in favor of a more advanced approach that relies on a more advanced approach to achieving observability.

  • Blameless Integrates Incident Management Platform With Opsgenie

    Blameless Integrates Incident Management Platform With Opsgenie

    Blameless this week announced it has integrated its namesake incident management solution with the Opsgenie alerting platform from Atlassian.

    Aaron Lober, director of product marketing for Blameless, said the Blameless platform is now integrated with both Opsgenie and PagerDuty, the two most widely used platforms for managing alerts.

    Blameless provides an incident management platform that normalizes data collected from a wide range of DevOps tools and platforms to determine how best to respond to different incident classes. Armed with those insights, it then becomes possible to quickly assemble the best team to respond to an event, said Lober.

    That capability reduces stress because Blameless also surfaces recommendations for resolving incidents based on the data it has collected, he added.

    The Blameless platform is tailored to organizations that have hired site reliability engineers (SREs) to manage IT operations using DevOps best practices, noted Lober. The overarching goal is to eliminate rote processes that, over time, conspire to burn out incident management teams that often experience high turnover rates, he added.

    Opsgenie has been connected to the Blameless platform via the service catalog and alerting functions. Blameless users responding to or managing an incident can escalate issues to any teams defined within Opsgenie. The service catalog and alerting data generated throughout the life cycle of an incident is automatically captured and stored on the Blameless Incident Timeline. That capability makes it possible to identify appropriate service owners and the escalation protocol that was followed by that team. Blameless can also display the actual user name of each responder that has been notified.

    When accessing Blameless via Slack or Microsoft Teams, Opsgenie can automate both when an incident channel is created and pre-select relevant services that should be made available. Alerts can also be manually triggered using commands from the Blameless chatbot for those who prefer to trigger alerts from within Slack or Teams themselves.

    As IT environments become increasingly more complex, more organizations are making a concerted effort to apply DevOps best  practices to incident management. The goal is to reduce downtime and increase overall resiliency at a time when organizations are more dependent on software than ever. As part of that effort, IT teams should identify the repetitive processes that span multiple incidents and then move to automate as many as possible.

    In the longer term, it’s not clear what impact artificial intelligence (AI) will have on incident management. At some point, though, IT teams should expect their efforts to be augmented by machine learning algorithms capable of identifying issues before they balloon into a major crisis. However, there will always be some human intervention required to manage incidents for the foreseeable future, noted Lober.

    In the meantime, most IT teams should continue to expect the unexpected at a time when IT environments have never been more dynamic and change multiple times a day.

  • OpenAI Hires 1,000 Low Wage Coders to Retrain Copilot ¦ Netflix Blocks Password Sharing

    OpenAI Hires 1,000 Low Wage Coders to Retrain Copilot ¦ Netflix Blocks Password Sharing

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: ChatGPT darling OpenAI wants people to write code in English, and the unintended consequences of blocking shared accounts. (more…)

  • Red Hat Brings Ansible Automation to Google Cloud

    Red Hat Brings Ansible Automation to Google Cloud

    Red Hat today announced that the Red Hat Ansible Automation Platform is now available on Google Cloud to simplify the management of yet another cloud platform.

    Using the Ansible Automation Platform, it’s now possible for IT teams that invoke Google Cloud to access pre-integrated services such as Google Virtual Private Cloud, security groups, load balancers and compute and instance groups.

    Pete Cruz, head of product and technical marketing for Red Hat Advanced Cluster Management for Red Hat, said Google Cloud—alongside existing support for rival cloud services—will make it simpler to consistently apply automation across multiple cloud and on-premises IT environments.

    In addition, IT teams can also count the consumption of the Ansible Automation Platform toward any existing enterprise spend agreements with Google.

    Ansible has emerged as a de facto standard for IT automation and is widely embraced by IT vendors and cloud service providers. That level of support has fostered the creation of a level of automation content that is now unrivaled by any other automation framework, noted Cruz.

    In the meantime, the pressure to automate IT processes is building during uncertain economic times. As IT environments continue to become more complex—thanks, in part, to the rise of cloud-native applications—many IT organizations are finding it more challenging to convince business executives to hire additional full-time employees. As a result, many of those IT organizations are now looking to automate as many processes as possible as more workloads are distributed from the network edge to the cloud.

    Rather than create a single playbook to automate every IT process on an end-to-end basis, organizations generally mix-and-match content created by others to automate workflows across highly distributed computing environments, noted Cruz.

    The biggest challenge when automating IT processes is simply overcoming inertia. Many processes are still manual simply because they always have been. In other cases, IT teams are still relying on undocumented scripts created by IT administrators who have left the organization. As the IT environment continues to evolve, it’s not likely those scripts will continue to scale.

    One way or another, IT is becoming more automated. The irony is that after using IT to automate almost every business process imaginable, it’s only recently that IT teams are getting around to automating their own workflows. Many of the rote tasks that used to be performed by entry-level personnel have been steadily disappearing thanks to automation.

    DevOps teams, of course, have always been ruthlessly committed to automating as many IT processes as possible in the name of efficiency. The rise of Ansible, however, makes it easier for every IT organization to achieve that same goal because they don’t have to wait for a specialist to create a playbook to automate a process. An Ansible playbook that can be easily customized or extended often already exists. The real issue may simply be knowing where to look for it.

  • Automation Challenges Holding DevOps Back

    Automation Challenges Holding DevOps Back

    A survey of 500 IT and engineering leaders in the U.S. published today finds organizations build an average of 6.7 internal applications per year themselves in addition to investing in 7.7 separate platforms to build applications.

    Commissioned by Internal, a provider of platforms for building application development environments, the survey also found organizations are spending 40% of their time building and maintaining these internal tools and workflows. While more than three-quarters (76%) of respondents said that this work is necessary, it distracts from building applications that drive business revenue. A total of 82% said a lack of true flexibility and customization is the top reason so much time is spent on building and managing internal tools and workflows.

    A full 94% of respondents said they want a more collaborative platform that enables technical and non-technical users to build internal tools/workflows faster together. The survey also found 91% of respondents believe a platform that encompasses application development and workflow automation would save development time.

    Internal CEO Arisa Amano said one thing that holds IT teams back is that managing the platforms used to build applications requires too much programming expertise. Internal is making a case for a graphical approach to building application development environments so IT administrators can easily construct them using a drag-and-drop interface on behalf of an application development team. That approach makes it possible to allocate more programming resources to building applications, she said.

    More organizations than ever are revisiting how applications are built as the number of projects increases despite an uncertain global economy, noted Amano. Organizations of all sizes are reluctant to hire additional full-time engineers even as digital transformation initiatives demand a growing number of custom applications, she added. The only way to effectively address those conflicting goals is to adopt a platform that automates much of the workflow associated with building an application development environment, said Amano.

    It’s not clear how willing DevOps teams are to replace the platforms they use today to build those environments, but many organizations are still relying on bespoke platforms they built and continue to maintain. Many of those platforms are made up of a collection of tools that DevOps teams cobbled together over the years. However, many of the software engineers that initially built those integrations may have since moved on and the documentation left behind is likely to be scant, noted Amano.

    Most DevOps teams in 2023 will continue investing in higher automation levels to accelerate application development. The quandary they all face is whether to continue to invest in the platforms they have already or migrate to a platform that makes it simpler to build and maintain an application environment using automated workflows built and maintained by a vendor. Regardless of what they choose, it’s certain the days when organizations could afford to throw engineers at every integration challenge have come to an end.