devopsy.kinsta.cloud

Category: DevOps Toolbox

  • CloudNativeDay: WASM to Drive Next IT Epoch

    CloudNativeDay: WASM to Drive Next IT Epoch

    WebAssembly (WASM) is poised to drive the next era of development of cloud-native applications that can truly run anywhere.

    Liam Randall, CEO of Cosmonic, a provider of a platform for building and deploying WASM applications, told attendees at a virtual CloudNativeDay event that WASM will be at the core of a new IT epoch that will enable organizations to more quickly build highly portable applications that are not tied to any IT infrastructure platform and more secure.

    WASM, at its core, is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. The World Wide Web Consortium (W3C) drove the development of WASM as part of an effort to create a common format for browsers executing JavaScript code. Wasm is now being extended beyond browsers and JavaScript to enable developers to create a set of universal binaries that could work on any platform without modification.

    That approach replaces the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct boundaries between them. One of the issues of that approach is that it becomes relatively simple for malware to infect all the components of an application.

    The Cloud Native Computing Foundation (CNCF) is now trying to advance the adoption of a Cosmonic’s WASM runtime that makes it possible to run WASM applications on any platform versus being constricted to building applications that can only run, for example, on Windows or Linux.

    That level of portability will prove crucial as more organizations look to drive application deployments on a wide range of edge computing platforms, noted Randall.

    It may be some time before WASM becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are finally starting to crumble. Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. That’s not only critical in terms of overall application developer productivity, it has major implications in terms of streamlining the management of DevOps workflows as it becomes easier to both initially deploy applications and continuously update them.

    In the meantime, as organizations continue to review their application development practices to better secure software supply chains, it’s become clearer that legacy approaches to building applications are fundamentally flawed. Rather than attempting to reengineer processes to encourage developers to better secure applications, it may be more effective to change the way applications are built. After all, considering all the processes required to secure legacy approaches to application development, it may be cheaper and easier to adopt a new app development method.

    The challenge, of course, is, as always, taking that first initial step away from the inertia of legacy application development approaches.

  • IBM Unveils Simulation Tool for Attacking SCM Platforms

    IBM Unveils Simulation Tool for Attacking SCM Platforms

    At the Black Hat USA 2022 conference, IBM today revealed it is making available a toolkit for launching simulated attacks against source code management (SCM) platforms. The toolkit was launched as a proof-of-concept.

    Brett Hawkins, head of adversary simulation for the X-Force Red arm of IBM Security, said the SCMKit takes advantage of the REST application programming interface (API) functionality in most SCM platforms to launch various types of attack modules using validated SCM platform credentials. IBM also described a series of attack scenarios that the simulation tool can be used to launch.

    The SCMKit can currently launch simulated attacks against GitHub Enterprise, GitLab Enterprise and Bitbucket Server. The kit can support reconnaissance, privilege escalation and persistence attack module capabilities for creating personal access tokens or secure socket shell (SSH) keys. The SCMKit is based on a modular framework that makes it possible to add additional modules in the future, added Hawkins.

    IBM created the SCMKit to focus more attention on an attack vector that can be exploited to compromise a software supply chain, said Hawkins. In the wake of a series of high-profile security breaches, the Biden administration issued an executive order that required federal agencies to review the security of their software supply chains. While there is more awareness of the issue than ever, Hawkins noted there has not been nearly as much focus on identifying specific attack vectors against SCM platforms that cybercriminals are able to exploit.

    It’s not clear to what degree organizations are launching penetration tests against their preferred SCM platform as they work to secure software supply chains. However, it won’t be long before testing the security integrity of those platforms becomes more commonplace. In some instances, organizations will launch those tests themselves. In other cases, third-party IT services firms will be tasked with launching those tests.

    Of course, the challenge is that penetration testing techniques are also often used by cybercriminals to conduct reconnaissance. The SCMKit doesn’t uncover any new techniques, but it does provide cybercriminals with a guide for launching attacks against SCM platforms. As such, IT organizations should assume these types of attacks will increase in frequency in the months ahead.

    Regardless of the tool employed, it’s clear that cybercriminals have come to appreciate the fact that software supply chains are the soft underbelly of IT. Organizations today have typically focused most of their security efforts on production environments. However, malware inserted into, say, a software repository could easily find its way into multiple downstream applications. At some future date, the malware then reaches out to a command-and-control system that then enables cybercriminals to, for example, launch a ransomware attack or simply exfiltrate data. That malware could also move laterally across an application environment to wreak additional havoc.

    It may be a while before the full extent of the threat to application security is fully appreciated, but as more organizations embrace DevSecOps best practices to secure their software supply chain, it’s all but certain that penetration testing will become much more pervasive in DevOps environments.

  • Armory Extends Scope of Spinnaker CD Distribution

    Armory Extends Scope of Spinnaker CD Distribution

    Armory today updated both the self-hosted and managed editions of its distribution of the open source Spinnaker continuous delivery (CD) platform. The updates support concurrent pipelines and provide tighter integration with open source Terraform infrastructure-as-code (IaC) to better enforce policies.

    Previously, the two platforms were known as Armory Enterprise and Armory Enterprise Managed. They are now being rechristened; Armory Continuous Deployment Self-Hosted becomes Armory Continuous Deployment Managed in part to provide more differentiation from a CD cloud service the company rolled out last month that is not based on Spinnaker.

    Adam Frank, vice president of product for Armory, said other capabilities added to the platform include additional testing tools for contributions to the Spinnaker platform as well as enhanced plug-ins and remediation capabilities for Common Vulnerabilities and Exposures (CVEs) that might impact the Spinnaker platform.

    Despite launching a declarative CD-as-a-service platform that is not based on Spinnaker, Armory remains committed to supporting organizations that prefer to continue to rely on the open source platform, said Frank.

    The number of organizations that routinely make use of a dedicated CD platform is still relatively small. While organizations have been employing continuous integration (CI) within a CI/CD platform, making use of the CD element of those platforms has proven challenging. Each platform used to run applications has been unique, so automating delivery has been problematic. CI platforms, in some cases, have been extended using custom scripts to automate application delivery, but those efforts don’t typically scale across an extended enterprise. Many organizations that attempted to extend the open source Jenkins CI/CD platform, for example, are now looking to more loosely couple CI and CD processes to make DevOps workflows less brittle, noted Frank.

    Armory is making a case for a distinct CD platform at a time when more organizations are starting to build microservices-based applications on Kubernetes clusters that expose a standard set of application programming interfaces (APIs) regardless of what infrastructure they are deployed on. In many cases, those organizations now need to manage multiple pipelines in parallel as application environments become more complex rather than relying on a single pipeline, noted Frank.

    There’s no doubt that as the pace of application development continues to accelerate, the need to automate CD will become a more pressing issue. DevOps teams are releasing a larger number of smaller updates to applications and there’s also a need to be able to easily roll back those updates in case an unexpected issue is encountered, said Frank.

    It’s not clear yet how many organizations will be adopting dedicated CD platforms, but as application development continues to evolve many DevOps teams will, at the very least, be revisiting their existing processes. At the same time, there are also many organizations that are just beginning their DevOps journey. Most of those organizations are not committed to one CI/CD approach versus another.

    Regardless of approach, however, the expectation in the era of digital business transformation is organizations will be able to deliver software updates in a timely manner. The only way to achieve that goal, however, will be to have some type of CD capability that reliably operates at the scale required by organizations that need to operate like a true software company.

  • Continuous Delivery Advances Come at Cost of Testing

    Continuous Delivery Advances Come at Cost of Testing

    A survey of 820 application development professionals conducted by Applitools, a provider of an application testing platform, found well over a third of respondents (38%) working for organizations that now deploy daily changes to production environments.

    The challenge is that application testing is not able to keep pace with that rate of continuous deployment (CD). The survey found organizations are seeing test suites covering less than 50% of applications.

    Applitools COO Moshe Milman said a major reason test coverage is so low is that more than 40% of respondents said their continuous integration (CI) test suites can take more than an hour to run, which often resulted in tests either being postponed or possibly not run at all, he noted.

    Most organizations are also still relying on manual testing processes that can’t keep pace with the accelerated rate of application deployment and subsequent updates, added Milman. More than half of organizations (55%) automated less than half of their testing, according to the survey. More than two-thirds of respondents (67%) are embracing test automation to improve their test coverage, the survey found.

    In general, the percentage of organizations that are now employing CD processes to accelerate the pace at which applications are deployed is steadily increasing, said Milman. Manual testing processes, however, slow down the rate at which organizations deploy code. Many organizations routinely make trade-offs between application quality and a need to deploy code faster. Inevitably, there will be issues that can be traced back to decisions to not adequately test code prior to deployment, noted Milman.

    Overall, the survey found 90% of respondents building and deploying web applications, followed by 52% that were building and deploying mobile applications. Only 30% are building desktop applications. Testing of the applications, however, tends to vary widely. Nearly two-thirds of respondents (65%) said they tested applications on an end-to-end basis, with 55% testing integration followed by unit testing (53%) and application programming interface (API) testing (51%).

    However, only 26% tested application performance, followed by 13% that tested security and 12% that tested load, the survey found.

    Part of the issue, of course, is that it’s not always clear who is responsible for application testing. In theory, developers are accepting more responsibility for application testing as they take more responsibility for managing applications on an end-to-end basis. In practice, developers are often rushing to make application development deadlines. It’s not uncommon for developers to skip or limit testing in the name of productivity. Many of them have also embraced agile development methodologies that, at least theoretically, allow them to address any issues that might arise via the next application update.

    The issue that arises is that end users have become less tolerant of experimentation. If an application doesn’t initially work as expected, it’s exceedingly difficult to regain user confidence. Many will simply evaluate another similar application. The irony, of course, is that in the race to deliver code faster, application experience winds up being sacrificed because of the lack of time to properly test an application before deploying it.

  • 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.

  • 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.

  • 3 Ways API Analytics Can Help Application Owners

    3 Ways API Analytics Can Help Application Owners

    Software development is fraught with risk that can run projects aground like a ship against a rocky beach. Whether it is misunderstood requirements, rapidly evolving marketplaces or old-fashioned bugs and schedule slippage, all can derail otherwise well-resourced and managed software development projects.

    Even when software development teams eventually ship their product and collect payment from their customers, there is no guarantee that the product will be used. A 2022 study found that among those paying for SaaS software, 29% of their software is either underutilized or wasted. This study also noted that only 33% of IT professionals track SaaS software usage. The takeaway here is stark: As an industry, most of our labor is not going to productive ends. 

    This is not a new trend in software; an entire ecosystem of tooling exists to help software development companies collect user engagement metrics to drive development decisions. In fact, out of the top 10 million websites in the world, nearly two-thirds have an analytics solution in place. By contrast, however, API applications lag far behind in adoption of this practice. It is difficult to get market penetration data for API analytics, but a report from API management vendor Apigee revealed that even among its customers (that is, those who were already paying for a service that included API analytics), only 26% made use of the analytics functionality. This gives credence to the belief that most features go unused.

    API application owners who are not integrating real-world analytics usage data into their decision-making process are leaving time and money on the table. Despite not having immediate access to user behavior, API analytics can be quite valuable in helping API application owners make better decisions about application development and maintenance. 

    API application owners should look to the following three ways to make better product development decisions.

    Prioritize Feature Development in the Most Actively Used Areas of the Application

    One of the best lessons I learned from working at a bike shop is “stock what sells.” In other words, there’s no point in filling your shelves with products that your customers aren’t buying. The same goes for stocking your API product catalog with endpoints that your customer isn’t using. 

    API analytics allow API product owners to measure the use of features and evaluate their effectiveness. Product owners can use this valuable information to prioritize extending popular features or developing new features, with a clear yardstick for measuring usage. Further, this data enables development teams to “maximize the amount of work not done,” by shipping preliminary feature sets and evaluating usage metrics before a full implementation. Likewise, if the real-world feedback is not encouraging, it allows you to pivot to another opportunity within the product.

    Deprecate or Sunset Unused Application Features

    Unused code and features are a liability to an API product organization and can carry bugs, create performance problems and introduce security risks. I’ve seen situations as a software developer where these older features were written by developers who have long since left the organization. These unused sections often harbor serious security flaws and vulnerabilities (such as software dependencies that go unpatched for years) and dubious authorization logic that no one at the company fully understands.

    Unused, extraneous features also contribute to a bloated product that can distract end users from the core value of your API. It can be difficult to advocate for the removal of “working product features,” but API analytics data can help make a strong case that certain features are nothing but an expensive distraction. Removing old, unused parts of your application also frees developers to focus on the parts that users love. 

    Prioritize Performance Improvements

    Performance is often a fine balance between implementation time/costs and product requirements.

    It’s a well-understood maxim in software development that premature optimization is the root of all evil. Yet in the absence of real-world performance data, determining what represents premature optimization versus totally-necessary-and-prudent optimization often comes down to a subjective argument among engineers or worse, a risk-averse software development culture that contributes to slow time-to-market.

    Having an objective measure of performance impact, like the number of instances in which clients are impacted by suboptimal performance, can help application owners decide how to allocate their budget to improving performance versus developing new features or fixing bugs. Moreover, having this feedback loop in place can empower development teams to take a nimble “go fast, release often and evaluate” approach to development. Rather than optimizing performance up front out of fear that invisible problems will lead to bad performance and dissatisfied users, performance can be tracked and reviewed over time. 

    Selecting API Analytics Solutions

    API product owners operating a single application have a variety of choices when it comes to deciding which analytics tool to use for their product. Many specialized solutions exist for individual API development languages and frameworks. However, security teams have a unique problem: They need all the data, across all applications and across all the tech platforms within the organization. In that case, I recommend an API protection vendor with strong API analytics capabilities that not only protects against threats but also gives you the visibility you need to prioritize efforts. 

    API analytics should be a tool that powers innovation. Don’t leave it unused in your toolbox. 

  • 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.

  • 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…)

  • Red Hat CEO: Out | Blind Users: Revolt | ARM: Google Joins Party

    Red Hat CEO: Out | Blind Users: Revolt | ARM: Google Joins Party

    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: Matt Hicks is the new Red Hat CEO, visual accessibility is in focus, and Google Cloud rolls out ARM instances. (more…)