devopsy.kinsta.cloud

Category: News

  • RapidAPI Adds Tool to Make Building APIs Simpler

    RapidAPI Adds Tool to Make Building APIs Simpler

    RapidAPI today added a free RapidAPI Studio offering to its portfolio that makes it easier for developers to build, consume, manage and monetize application programming interfaces (APIs).

    Wade Wegner, senior vice president and head of product at RapidAPI, said RapidAPI Studio, available in beta, makes it simpler for developers to move between design and development, testing and management without losing context.

    It is also designed to be slipstreamed into developer workflows by either being accessed via a browser, as a desktop application, a macOS-native application or as an extension to the VS Code tools provided by Microsoft, added Wegner.

    That approach also makes it easier for teams of developers to collaboratively work on API projects, he noted.

    APIs are foundational to every modern application development initiative. Each microservice included in a modern application has its own API. As a result, the number of APIs—internal and external—that organizations are building and exposing has increased exponentially, especially as the number of digital business transformation initiatives continues to expand. While the bulk of APIs employed today are internally facing, the number of external-facing APIs being employed tends to rise sharply as more business processes become digitized.

    Less clear is who within the organization is responsible for managing those APIs after they have been deployed. In some cases, developers assume responsibility for them along with every other component of an application. Developers, however, tend to move on to other projects; DevOps and cybersecurity teams are being tasked with managing, securing and updating APIs. This is part of a larger effort to better secure software supply chains in the wake of a series of high-profile breaches.

    Unfortunately, documentation of those APIs has been somewhat lax within many organizations. In many cases, organizations are not even sure how many APIs have been deployed. Many organizations also discover, to their chagrin, that so-called zombie APIs previously abandoned by developers can still be exploited by cybercriminals to exfiltrate data.

    At the same time, the management of APIs is becoming more complex. Along with existing REST APIs and legacy web services based on XML, organizations are now deploying GraphQL APIs. The result is a mix of API schemas that require different levels of expertise to manage and secure.

    It’s not clear how the increased focus on securing software supply chains might impact API management. However, it’s apparent that cybercriminals are becoming more adept at discovering insecure APIs through which they can exfiltrate data. The challenge organizations face is that it’s not feasible to secure those APIs without first having a framework in place for managing them.
    One way or another, an API management crisis will soon come to a head as it becomes even simpler to build and deploy APIs. The only thing that remains to be seen is to what degree organizations will get ahead of that issue before it spins out of control altogether.

  • CircleCI Integrates CI/CD Platform With GitLab

    CircleCI Integrates CI/CD Platform With GitLab

    CircleCI today announced it has integrated its continuous integration/continuous delivery (CI/CD) platform with a rival software-as-a-service (SaaS) offering from GitLab.

    DevOps teams can now, for example, trigger pipelines in CircleCI from GitLab forked merge requests in addition to merging requests and making commits for specific branches. Other capabilities include the ability to access testing capabilities on the CircleCI platform and integrate permissions to ensure security.

    CircleCI CEO Jim Rose said the company routinely integrates its CI/CD platform with other offerings because organizations typically have multiple teams using different version control platforms at different times. The goal is to give those teams access to capabilities and best practices regardless of which specific platform they are using.

    In general, Rose said organizations are trying to strike a balance between the standardization of DevOps platforms and the need to enable development teams to innovate by adding new tools. Standardization tends to create more opportunities to automate more tasks in ways that reduce costs. However, developers will eventually rebel against any effort to limit the choice of tools they use to improve productivity, noted Rose. Too many senior IT leaders are quick to assume that a plethora of tools is an indication of a problem rather than the result of ongoing experimentation, he added.

    In the wake of the global economic downturn, many organizations are also revisiting their existing DevOps workflows to try to increase overall efficiency by automating more tasks. Those organizations realize they can’t afford to continue throwing labor at manual DevOps tasks, Rose added.

    The challenge, of course, is that building and deploying modern software is becoming more complex. Organizations are embracing microservices to make applications more resilient as they realize how dependent they are on software. The issue is that as the number of microservices continues to expand, it becomes apparent that legacy manual processes will not scale, said Rose. As a result, the impetus to automate DevOps processes becomes that much greater, he added. Less clear is to what degree organizations that have already embraced DevOps platforms might be willing to swap out their current CI/CD platform to achieve that goal.

    In the meantime, more organizations are embracing DevOps to manage software development projects that drive a wide range of digital business transformation initiatives. The applications driving those processes typically need to be continuously updated as business requirements change. That becomes much easier to achieve when using processes optimized around continuous development and deployment.

    Regardless of which underlying CI/CD platform organizations choose, they should assume that, eventually, some level of integration between those platforms will be necessary. After all, in the event of an acquisition, for example, it’s not likely both companies will have standardized on the same DevOps platform. Given the amount of time required to migrate from one DevOps platform to another the amount of time required for interoperability is inevitably going to be measured in months if not years.

  • VW CEO Fired for Dev Fails | Fiber Shortage Hits | Google Fires Blake Lemoine

    VW CEO Fired for Dev Fails | Fiber Shortage Hits | Google Fires Blake Lemoine

    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: Herbert Diess is out at VW because software is hard (yo), fiber optic cable is hard to find, and the guy who said LaMDA was sentient is dumped by Google. (more…)

  • Dynatrace Embeds DX Monitoring in Observability Platform

    Dynatrace Embeds DX Monitoring in Observability Platform

    Dynatrace has enhanced its analytics capabilities to enable digital experience monitoring, including session replays, based on the logs, metrics and traces it collects via its observability platform.

    Steve Tack, senior vice president of product management at Dynatrace, said this update makes it simpler for DevOps teams to track user journeys across the multiple components and microservices that make up a modern application environment. Rather than trying to, for example, determine the impact of an issue by parsing through log data without any context, Tack said Dynatrace’s analytics capabilities will automatically fire up a session replay to enable DevOps teams to view the exact nature of the application issue being experienced.

    Previously, DevOps teams would have needed to deploy the Dynatrace session replay offering separately. The overall goal is to remove much of the friction DevOps teams encounter when trying to fix an application issue by providing context in a way that is more accessible, he added.

    In general, as observability continues to advance, it’s now become much less about the amount and types of data that can be collected, said Tack. The data is table stakes for achieving observability, he added. The focus now needs to be on the richness of the actionable analytics being surfaced once that data is collected, he said.

    In fact, as more organizations start to build and deploy applications based on highly interdependent microservices, the richness of the analytics is now more critical than ever, noted Tack. While microservices-based applications are more resilient than monolithic applications, troubleshooting them is more challenging whenever application performance degrades, he added.

    It’s not clear at what rate DevOps teams are embracing observability. The concept has always been a core DevOps principle, but, for the most part, more mature DevOps teams have only been able to achieve what amounts to continuous monitoring of pre-defined metrics. Observability platforms promise to surface anomalies indicative of IT issues before they escalate; DevOps teams can then launch queries to better determine their root cause and potential severity.

    Dynatrace is making a case for an observability platform, accessed as a cloud service, that employs the company’s Davis AI engine and machine learning algorithms to surface the root cause of application issues.

    As observability platforms continue to evolve, the days when IT teams determined the root cause of an IT issue by process of elimination are finally coming to an end. DevOps teams will be gaining more visibility into their application environments in ways that surface more meaningful actionable intelligence. That intelligence is especially critical for externally-facing applications driving digital business transformation initiatives.

    There is, of course, no shortage of options when it comes to observability platforms. In some cases, IT organizations are opting to rely on cloud services while others are extending DevOps platforms they built themselves and continue to maintain. Regardless of the approach, the issue will no longer be how to collect data as much as what to do with it once it’s collected.

  • Oracle’s Free Managed Service Integrates With Microsoft Azure

    Oracle’s Free Managed Service Integrates With Microsoft Azure

    Oracle today extended its alliance with Microsoft to include a managed service that makes it simpler for IT organizations to embrace hybrid cloud computing. Oracle Database Service for Microsoft Azure integrates Windows applications with Oracle databases running on Oracle Cloud Infrastructure.

    Leo Leung, vice president of products and strategy for Oracle, said the managed service is an extension of an existing capability that was rolled out in 2019. However, many IT organizations found it too difficult to provision hybrid cloud computing environments themselves. The managed service makes it easier to access Oracle databases across a high-speed network spanning 11 global regions, Leung said.

    There is no charge for the Oracle Database Service for Microsoft Azure, the Oracle Interconnect for Microsoft Azure, data egress or ingress when moving data between OCI and Azure, said Leung. Organizations will pay only for the other Azure or Oracle services they consume.

    DevOps teams have often spent significant amounts of time trying to integrate diverse cloud computing environments. Now, with just a few clicks, Oracle is making it possible to connect Azure subscriptions to OCI. The service automatically configures OCI and Azure environments, federates Azure Active Directory identities and enables monitoring with Azure Application Insights.

    Oracle and Microsoft, of course, are locked in a fierce database contest as Microsoft looks to drive adoption of SQL Server as an alternative to the Oracle relational database. However, there are many organizations that today run Oracle databases on Windows servers in on-premises IT environments. Oracle is looking to make it easier to migrate those environments to the cloud with minimal disruption, noted Leung.

    Theoretically, organizations are embracing multi-cloud computing to ensure they don’t find themselves locked into a single provider. The challenge is that each cloud computing environment has its own set of management tools that need to be mastered. As organizations add additional clouds, the actual total cost of IT rises as more specialists are brought on board to manage those environments. Oracle’s approach addresses that issue by enabling IT teams to manage Oracle databases via a single pane of glass that resides on the Azure cloud, said Leung.

    Oracle has been trying to gain market share in the cloud by reducing the total cost of cloud services. A free managed service for integrating Azure cloud with OCI also reduces the incentive any existing Oracle customer might have to replace Oracle databases as they migrate to the cloud.

    It’s not clear how far the Oracle service will advance hybrid and multi-cloud computing, but it does set a new benchmark for what IT organizations should expect. The days when cloud service providers largely ignored each other are coming to an end. In this day and age, IT teams should not have to devote resources to integrating low-level APIs simply because cloud service providers don’t want to acknowledge the fact that application workloads are routinely deployed on multiple clouds.

  • Poor App Remediation Creates a Vicious Vulnerability Cycle

    Poor App Remediation Creates a Vicious Vulnerability Cycle

    A survey of 200 security professionals found nearly 83% of respondents reported that an increase in the rate at which applications are being deployed has led to an increase in the reintroduction of previously remediated vulnerabilities.

    The survey, conducted by Waratek, a provider of tools for managing security-as-code, found 93% of the security professionals polled currently work for organizations that have embraced DevOps or Agile development methodologies. Half of the respondents (50%) described maintaining security in those environments as challenging, with a slightly higher percentage (58%) noting that implementing security within DevOps process does slow down the rate at which applications are deployed. A full 85% also noted that manual security work slows the rate at which applications can be deployed as well.

    Surprisingly, more than two-thirds (67%) of security professionals also said they would be willing to sacrifice security to allow applications to be delivered on time.

    Nearly three-quarters (71%) also said they expected that keeping pace with DevOps teams would only become more difficult, with 61% also noting that keeping pace with DevOps teams resulted in delays to other critical security projects.

    Waratek CEO Doug Ennis said the root cause of the application security challenge can be traced back to continued reliance on manual processes. It’s too easy for developers, for example, to reuse code that contains vulnerabilities that were fixed in one version of an artifact but not another, he noted.

    That lack of automation also conspires to increase overall cybersecurity fatigue, added Ennis. More than 50% of survey respondents reported they spend days or weeks each year investigating false positives. There simply are not enough cybersecurity professionals available to make sure applications are secure without relying more on automation, said Ennis.

    In the wake of a series of high-profile security breaches, there is more focus on software supply chain security than ever. However, it’s not clear to what degree organizations are embracing automation and DevSecOps best practices to secure those software supply chains. The challenge is finding a way to build more secure applications without slowing down the rate at which those applications are built and deployed.

    Many organizations are clearly already shifting more responsibility for application security left toward developers and DevOps teams with hopes of achieving that goal. However, it’s still the cybersecurity team that get the call whenever there is a breach, noted Ennis. There must be workflows in place that enable automatic remediation in ways that don’t always require organizations to wait on a developer to build and deploy a manually-applied patch that is usually inconsistent, he added.

    The Log4Shell vulnerability is a perfect example of how flawed the current process for building and deploying patches is, Ennis explained.

    In fact, as more applications are deployed, developers often find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building and deploying secure applications that leverages automation is clearly required. The challenge is creating automation that consistently achieves that goal each and every time required in a way that doesn’t break any of the applications that need to be fixed.

  • 3 New WFH and Hybrid Work Trends That YOU Need to Grok

    3 New WFH and Hybrid Work Trends That YOU Need to Grok

    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, a remote/hybrid work special: Bribes to relocate you, Fridays are forgotten, and big tech firms stop building offices. (more…)

  • Atlassian Bitbucket CI/CD Cloud Service Aims for the Enterprise

    Atlassian Bitbucket CI/CD Cloud Service Aims for the Enterprise

    Atlassian today outlined its strategy to increase the appeal of the Bitbucket continuous integration/continuous delivery (CI/CD) cloud service among enterprise IT organizations. Atlassian said it plans to focus on four core pillars: Performance, management, extensibility and security and compliance, starting with an update scheduled for the third quarter.

    Dan Tao, head of engineering for Bitbucket Cloud and Compass at Atlassian, said the overall goal is to make it simpler to use the Bitbucket Cloud service running on the Amazon Web Services (AWS) cloud at scale as organizations increase the rate at which they build and deploy software.

    Atlassian is still supporting the Bitbucket Server and Data Center editions of the platform, but it’s apparent more organizations are shifting software development to the cloud, he noted. Atlassian is now moving to not only simplify migrations to the cloud by, for example, providing a Bitbucket Cloud Migration Assistant tool, but it is also moving to ensure applications can be developed at scale.

    Achieving that goal includes making use of a more advanced diff algorithm that is four times faster in larger DevOps environments, he added.

    Other planned enhancements include the ability to execute CI/CD workflows via Bitbucket pipelines, the ability to reuse multi-step pipelines across repositories, tighter administration integration with other Atlassian applications, the ability to encrypt data at rest and integration with the Snyk tool for discovering vulnerabilities in software to improve security.

    Finally, the Bitbucket Cloud service will also soon support Bitbucket Mesh, a distributed storage capability that is already employed in Bitbucket Data Center.

    Overall, Atlassian sees the migration to the cloud as a means to not only make DevOps workflows more accessible to a wider range of organizations, but also give organizations that have already invested in DevOps the opportunity to streamline those processes, said Tao.

    Many DevOps teams today maintain complex platforms with custom integrations that they need to maintain and support. Atlassian provides DevOps teams the option to either employ an integrated platform or use connectors it has created as part of the Atlassian Open DevOps framework to make it simpler for teams to use whatever mix of tools they prefer, he added. In either case, the total cost of maintaining a DevOps environment can be significantly reduced, said Tao.

    It’s not clear to what degree organizations that have already invested in DevOps are considering replacing their existing CI/CD platforms. However, as the pressure to accelerate the rate at which software is built and deployed steadily increases, the pressure to further automate DevOps workflows also builds. At the same time, DevOps teams are now being asked to integrate security gateways that require additional custom integrations within legacy platforms that they would need to support alongside existing integrations.

    At the very least, more organizations than ever are weighing their DevOps options. The issue, of course, is that the total cost of switching out DevOps platforms is not inconsequential given the current dependency on existing workflows.

  • Survey Warns of Looming Software Testing Crisis

    Survey Warns of Looming Software Testing Crisis

    A survey of CEOs and IT professionals involved in application testing finds a significant gap in terms of how acceptable it is to release software that has not been properly tested.

    The survey, conducted by the market research firm Censuswide on behalf of Leapwork, a test automation platform provider, polled 480 CEOs in the U.S. and the United Kingdom (UK) from organizations with more than 500 employees and 480 heads of quality assurance, testers, release and delivery managers and site reliability engineers (SREs).

    A full 85% of the CEOs in the U.S. and 69% in the UK said it’s acceptable to release software that hasn’t been properly tested, as long as patches are tested and applied later. Less than half of the IT professionals surveyed (49%) agreed. A full 94% of CEOs also said they’re confident the software released is tested regularly.

    However, 79% of the IT professionals admitted that as much as 40% of software goes to market without sufficient testing. As a result, 68% of UK and 52% of U.S. IT professionals said their teams spend five to 10 days per year patching software.

    The survey also made it clear that everyone involved is well aware of the risks that lack of testing creates. Nearly every CEO (95%) is concerned about losing their job in the wake of a software failure. Slightly more than three-quarters of the IT professionals (76%) surveyed have the same fear.

    More than three-quarters of CEOs (77%) also noted that software failures have harmed their company’s reputation in the last five years.

    Many organizations today assume that Agile development and DevOps best practices will enable them to apply patches quickly in the event an issue arises. The trouble is, in the absence of sufficient testing many of those organizations are essentially experimenting on end users.

    Leapwork CEO Christian Brink Frederiksen said the primary reason so much software is not being properly tested is that most organizations continue to rely on manual testing processes that can’t keep pace with the rate at which applications are now being developed; one major factor is the use of low-code and no-code tools.

    Of the IT professionals at organizations that release insufficiently-tested software, a full 40% cited underinvestment in test automation as a factor, with only 43% of respondents using some type of automation. Other reasons cited for the lack of appropriate testing included lack of time (34%) and increased rates of deployment (29%).

    Just over a third of CEOs (34%) and about four in 10 testers (42%) whose companies use or develop in-house software that goes to market without being tested also cited a lack of available skilled developers. More than a third of CEOs (34%) also cited underinvestment in testing personnel.

    At a time when more organizations than ever are dependent on software to drive digital business transformation initiatives, it’s apparent that an application testing crisis is imminent. The only thing left to be determined is how catastrophic the fallout will be because existing processes don’t scale to meet the challenge.

  • Deloitte Aligns with Dynatrace for Observability

    Deloitte Aligns with Dynatrace for Observability

    Deloitte has expanded its cloud observability practice to include the Dynatrace Software Intelligence platform.

    Jay McDonald, managing director and co-chair for modern delivery at Deloitte, said the IT services provider will now provide traditional DevOps and observability consulting expertise along with a set of instances of the Dynatrace Software Intelligence Platform that it will manage on behalf of organizations.

    Deloitte opted for the Dynatrace platform because it employs a single agent for collecting metrics, logs and traces that are then analyzed by its Davis artificial intelligence (AI) engine to enable observability, said McDonald.

    While there is a growing appreciation for observability to enable DevOps teams to identify the root causes of IT issues before they become major problems, deploying an observability platform requires a lot of specialized expertise. Many organizations are opting to rely on third-party organizations such as Deloitte to manage that task within the context of a larger DevOps workflow, said McDonald.

    Managing those workflows has become especially challenging for many organizations to deploy and maintain as they move to build and deploy microservices-based applications, he added.

    Michael Allen, vice president of worldwide partners for Dynatrace, said there are now already more than 4,000 organizations using the Dynatrace Software Intelligence Platform, a number that will continue to increase as observability platforms are consumed as a service.

    It’s not clear at what rate DevOps teams are embracing observability. The concept has always been a core DevOps principle, but, for the most part, more mature DevOps teams have only been able to achieve what amounts to continuous monitoring of pre-defined metrics. Observability platforms promise to surface anomalies indicative of IT issues before they escalate; DevOps teams can then launch queries to better determine their root cause and potential severity.

    One of the benefits of the Davis AI engine is that machine learning algorithms surface the root cause of many of those issues without requiring DevOps teams to know exactly how to construct the right query, noted Allen.

    However, the biggest challenge many DevOps teams encounter is they lack the skills required to deploy and manage observability platforms. In fact, many of them are now relying on third parties to manage a wide range of DevOps platforms so they can concentrate their efforts on actual workflows. Hiring and retaining DevOps professionals also has become more challenging as the total number of applications being built and deployed expands beyond DevOps teams’ abilities to effectively manage.

    One way or another, the days when IT teams determined the root cause of an IT issue by process of elimination are finally coming to an end. DevOps teams are gaining more visibility into their application environments in ways that surface more meaningful actionable intelligence, regardless of who sets and manages the observability platform. The opportunity to employ that intelligence to improve overall application resiliency and drive a wide range of digital business transformation initiatives is well within DevOps teams’ reach.