devopsy.kinsta.cloud

Author: Mike Vizard

  • vFunction Automates Conversion of Java Apps to Microservices

    vFunction Automates Conversion of Java Apps to Microservices

    vFunction has developed an eponymous platform capable of automatically converting a monolithic application written in Java into a set of microservices. The startup is emerging from stealth mode today.

    Fresh from raising $12.2 million in seed funding, vFunction CEO Moti Rafalin said the company’s platform employs dynamic analysis, static analysis, data science and automation to enable IT teams to reengineer, in a repeatable fashion, the source code used to create monolithic Java applications.

    As part of that process, vFunction also detects and eliminates code that is no longer executed to reduce the footprint of an application, minimize security risks and overall maintenance tasks.

    The vFunction platform is deployed as a server that communicates with agent software injected into the legacy monolithic application. The server then creates a microservice that is scanned by additional tools to determine how best to optimize it to run on, for example, a Kubernetes cluster based on the Red Hat OpenShift platform, said Rafalin.

    IT teams can also employ vFunction to determine which monolithic applications are better suited to being converted into a set of microservices that can be automatically extracted into separate compilable projects. Each project comes with an estimated timetable for completion that can be accessed via a Modernization Factory Dashboard and Application Complexity Assessment tool provided by the platform.

    Rafalin said most monolithic applications are made up of large amounts of ‘spaghetti code’ that was added over multiple generations by different development teams. Manually analyzing that code as part of an effort to refactor a legacy application would require weeks of effort, Rafalin said. As such, the rate at which most organizations are re-engineering applications is extremely slow, he said.

    In fact, it’s not unheard of for IT organizations to to start, but quickly abandon such because the time and effort required proved too costly. vFunction claims its automated, domain-driven processes accelerate manual refactoring by a factor of ten, resulting in a savings of anywhere from $300,000 to $500,000 per application.

    Pricing for vFunction is based on a per-application model. The company has also established alliances with system integrators such as HCL Technologies, Tata Consulting Services and Wipro that are regularly contracted by IT organizations to refactor their applications.

    Of course, not every monolithic application needs to be converted into a set of microservices. However, most monolithic applications have components that would be easier to maintain and support as a distinct microservice. Organizations, in general, are embracing microservices to build applications that are more resilient. In the event a microservice becomes unavailable, requests for services are rerouted to another microservice to make sure the application degrades gracefully, rather than crashes altogether. The challenge is that, over time, the dependencies that can exist between hundreds of microservices can be more challenging to manage than those of the monolithic application being replaced.

  • OpenTelemetry Project Gains Log Agent Software from observIQ

    OpenTelemetry Project Gains Log Agent Software from observIQ

    Stanza, an open source log agent developed by observIQ, a provider of an observability platform, has become part of the OpenTelemetry Project for collecting telemetry data.

    Mike Kelly, CTO and co-founder, observIQ, said Stanza will make it possible to collect log data alongside other telemetry data using a common application programming interface (API) and software development kit (SDK).

    OpenTelemetry is currently a sandbox-level project being developed under the auspices of the Cloud Native Computing Foundation (CNCF); it provides a set of open source libraries, agents and other components for collecting the telemetry data consumed by observability and IT monitoring tools.

    Contributors to the OpenTelemetry Project include Amazon Web Services (AWS), Elastic, Google, Honeycomb, Lightstep, New Relic and Splunk. After Kubernetes, Kelly said the OpenTelemetry Project is now the most popular open source initiative being advanced by the CNCF.

    The OpenTelemetry Project is still a long way from delivering agent software that will be widely employed on an IT production environment. However, the potential implications of the project are already being widely noticed. Rather than having to deploy, manage and update agent software for individual IT management tools, it will soon be possible to deploy a single set of agent software to generate data that can be consumed by multiple platforms.

    That shift will enable providers of these platforms to focus more of their effort on enhancing their analytics capabilities rather than developing proprietary agent software that typically doesn’t provide much differentiated value, Kelly said.

    Stanza is part of an IT observability platform developed by observIQ when it was previously known as Blue Medora. After selling its platform for integrating monitoring tools to VMware, Blue Medora changed its name to observIQ. Now, it is making an effort to advance adoption of an observability platform that it makes available as a software-as-a-service (SaaS) application.

    Will DevOps teams roll out elements of OpenTelemetry themselves, or wait for the observability and monitoring tool and platform providers to support open source agents that would automatically be deployed? That remains to be seen. Regardless, the total cost of observability should decline, as open source agent software replaces the proprietary agent software strewn across enterprise IT environments today. The expectation for vendors is that more applications will be consuming analytics data surfaced by the observability and monitoring platforms they provide.

    Of course, it will be a while before that dream is fully realized. In the meantime, IT organizations will need to carefully evaluate the total cost of observability against the business value of the application deployed. Cost is one of the reasons application performance management (APM) tools are not widely employed today. Of course, as IT environments become more complex, thanks to the rise of microservices and serverless computing frameworks, it’s also become increasingly apparent that observability will soon be a capability IT teams can’t afford to do without.

  • ARMO Aims to Simplify Microservices Security

    ARMO Aims to Simplify Microservices Security

    ARMO this week emerged from stealth to launch a platform to secure cloud-native workloads and improve visibility. The ARMO Workload Fabric technology attaches code within the memory invoked by a microservice to enable cybersecurity policies to be applied via a cloud service.

    Company CEO Shauli Rozen said the ARMO Workload Fabric is designed to enable IT organizations to implement a zero-trust architecture more easily within the context of a DevSecOps workflow.

    Fresh from raising $4.5 million in seed funding, Rozen said ARMO’s approach eliminates the need to deploy and manage agent software, container sidecars or runtime application self-protection (RASP) software to enforce security policies across what inevitably will become thousands of microservices distributed across an enterprise IT environment.

    That leaner approach then allows for a centralized management platform that can be deployed on a cloud or on-premises IT environment to apply policies that restrict which microservices can communicate with one another, Rozen said. The approach would ensure that only microservices developed using a continuous integration/continuous delivery (CI/CD) platform are allowed to communicate with other microservices, Rozen said.

    Integration with multiple CI/CD platforms is already provided, added Rozen.

    That approach allows policies to be applied to microservices regardless of how they are constructed, Rozen said. That capability is critical, because developers are building microservices using everything from Python and Java to containers, he said. Many of those microservices are also frequently replaced, Rozen said, which can make updating any associated agent software a significant DevOps challenge. Given all the existing dependencies between microservices, overall application environment security is only as strong as the proverbial weakest link. The ARMO Workload Fabric enables developers to add a small amount of code to implement security policies each time a microservice is rolled out into a production environment.

    As part of an effort to make it simpler for IT organizations to apply those policies, ARMO provides a pre-built set of policies that organizations can immediately apply, in addition to creating their own polices over time, Rozen said. In many cases, IT teams simply don’t have the time or expertise required to build those policies, Rozen added.

    Microservices are being built and deployed at such a breakneck pace that it’s nearly impossible for cybersecurity teams to keep up. The ARMO Workload Fabric provides cybersecurity teams a means to centrally manage security policies that would otherwise be implemented as code by developers. It provides a level of observability for how those cybersecurity policies are being implemented across microservices that typically have a lot of dependencies on one another, Rozen said.

    Most organizations today recognize there is a clear need to shift responsibility for application security further left toward developers. The challenge is finding a practical way to achieve that goal, and in a way that doesn’t adversely impact the rate at which applications are being developed. The key to achieving that goal is finding a way to apply microservice security polices that causes the least amount of friction possible to existing DevOps workflows.

  • Esri Unveils PaaS Environment for Calling Geospatial Data via APIs

    Esri Unveils PaaS Environment for Calling Geospatial Data via APIs

    Esri today unveiled a platform-as-a-service (PaaS) environment through which developers can embed geospatial capabilities into their applications by making an application programming interface (API) call to a cloud service.

    Euan Cameron, CTO for developer technology at Esri, said the ArcGIS Platform will make it simpler for developers to incorporate mapping capabilities enabled by a geographic information system (GIS) system with, for example, a mobile application. The entire ArcGIS software stack can be accessed by those applications by making an API call. Previously, IT teams would have to stand up the entire Esri platform on their own to provide development teams with access to the Esri geospatial platform.

    The PaaS environment also makes it possible for developers to access professional-grade geospatial content that can be plugged directly into their applications, Cameron said.

    Geospatial platforms gained prominence with the popularity of mobile applications that require mapping capabilities. With the expansion of 5G wireless networks, the number of applications that require similar capabilities will continue to grow, Cameron said. A PaaS environment that abstracts the complexity of managing a geospatial platform behind a set of APIs will make it easier to build those applications at scale, Cameron said.

    There are, of course, other approaches to making geospatial databases available as a service. However, Cameron said Esri has long history of providing these capabilities alongside content it curates across a wide range of consumer and business applications. Those capabilities are now an API call away from any application, Cameron said.

    Of course, DevOps teams will need to integrate a PaaS environment that can be invoked as a cloud service within their overall workflow. Esri is committing to making its PaaS offering available on a global network of data centers to minimize latency for applications making API calls to its platform.

    These days, it’s hard to imagine an application that doesn’t require at least some degree of geospatial capabilities. Time and place have become critical elements of any application experience. The total cost of providing those capabilities drops considerably when the geospatial platform required to enable them is managed by its provider. In fact, as application development continues to evolve, DevOps teams often find themselves orchestrating a broad range of API calls to external services. Each one of those calls is simple enough, but over time, the sheer number becomes challenging to manage. Nor is the quality of the APIs surfaced by each service always of the same quality.

    Regardless of how geospatial capabilities are integrated into an application, the days when dedicated teams managed complex GIS platforms may finally be coming to an end.

  • Sentry Updates Tool for Monitoring JavaScript Apps

    Sentry Updates Tool for Monitoring JavaScript Apps

    Sentry today announced it has updated its JavaScript SDK tool for monitoring applications to provide a more comprehensive view of application health.

    Previously, Sentry’s JavaScript SDK enabled JavaScript developers to insert lines of code that would tell them, for example, how many times an application failed. A new release health capability now also identifies what percentage those fail instances represent of the total number of times that application was successfully launched.

    Developers can, in effect, better gauge adoption of a JavaScript application by tracking the percentage of crash-free sessions and crash-free users over the application’s life cycle.

    Ben Vinegar, vice president of engineering for Sentry, said the JavaScript SDK is designed to provide developers with a monitoring capability that doesn’t require an IT operations teams to stand up and manage an entire application performance management (APM) platform. That approach also eliminates the need to instrument JavaScript applications with agent software, Vinegar said.

    The JavaScript SDK consumes tens of kilobytes of memory after it is embedded directly within a JavaScript application, said Vinegar.

    In general, JavaScript is increasingly being used to build complex applications, using frameworks such as React, as an alternative to Java. Over the years, IT organizations have developed a certain amount of bias around how Java applications should be monitored and managed using APM platforms. However, as JavaScript developers assume more responsibility for their applications after deployment, they need real-time monitoring tools that can consume JavaScript application metrics and are built in to existing APM platforms, .

    Of course, APM platforms are managing more than just JavaScript applications, so they’ll remain useful for the forseeable future. However, ease of observation and monitoring is a significant factor when application developers choose a language in which to build an application, and it’s up to individuals to remediate issues that might arise in production. Developers, therefore, have a vested interest in discovering potential issues before that application is deployed.

    Historically, developers have not had access to JavaScript application monitoring tools that they could easily implement on their own. Sentry’s tools makes it possible for developers to identify performance issues, including calls to application programming interfaces (APIs) and other common errors, and address those before an application crashes.

    It’s possible, as performance and security issues shift left and developers become more accountable for user experience, that developers might one day instrument and monitor applications on their own – if for no other reason than self-preservation. Every minute a developer spends remediating a production issue in an existing application is one less minute they will have to write new code.

  • OpsRamp Extends AIOps Reach to the Network

    OpsRamp Extends AIOps Reach to the Network

    OpsRamp today announced its AI-enabled IT operations management (AIOps) platform now has the ability to analyze network flows and communications traffic.

    Ciaran Byrne, vice president of product management for OpsRamp, said the new analytics capabilities will make it possible for IT teams to correlate the IT events OpsRamp already tracks on servers and storage systems against multiple types of traffic moving across a corporate network.

    OpsRamp is based on a software-as-a-service (SaaS) platform that simplifies IT adoption of AIOps without having to build and maintain their own management platform or install an AIOps platform on their own infrastructure.

    Rather than acquiring a separate platform to analyze network traffic, OpsRamp is adding an OpsRamp NetFlow monitoring module, for analyzing packets using the NetFlow protocol developed by Cisco, and an OpsRamp Unified Communications monitoring module, for analyzing voice and collaboration data.

    OpsRamp NetFlow provides real-time diagnosis of network latency across wide area networks (WANs). It generates alerts based on network traffic utilization, and delivers insights into network utilization patterns by identifying source, destination, protocols and applications that impact services.

    OpsRamp Unified Communications works in a similar way, surfacing alerts and insights about traffic patterns impacting, for example, Zoom or Microsoft Teams.

    With more employees working remotely, the need to analyze network traffic has become more acute, said Byrne. Network performance degradations can have a major impact on overall application experience, Byrne said.

    Communications and collaboration platforms like Microsoft Teams pose particularly stubborn challenges, because they offer IT teams little to no visibility into that traffic, Byrne said.

    It’s unclear whether – and to what degree – networking and other IT operations will converge, but as AIOps platforms become more accessible, the ability to correlate IT events across multiple infrastructure classes as they transpire will steadily improve. While that may not lead to IT role consolidation anytime soon, it should enhance the level of collaboration teams can achieve.

    In the meantime, AI is poised to have a profound impact on how IT environments are managed. The amount of time spent in “war rooms” performing root cause analysis can be sharply reduced through the use of machine learning. As algorithms surface insights, IT teams will be better able to proactively address issues before they have a major impact on application performance and user experience. It may take time for IT teams to fully trust AIOps platforms, but in the near future, IT professionals will avoid working for organizations that don’t have such platforms in place. For IT professionals, keeping complex application environments running without AIOps platforms will be nearly impossible.

    Of course, transitioning to any type of new IT management platform is no small undertaking. However, as AIOps platforms continue to evolve, the overall cost of managing IT should also decline as leadership justifies the costs of these tools.

  • HAProxy Updates Data Plane API to Simplify Service Discovery

    HAProxy Updates Data Plane API to Simplify Service Discovery

    HAProxy has updated the open source HAProxy Data Plane application programing interface (API) to include service discovery capabilities alongside native support for the Consul service mesh being developed by HashiCorp.

    Version 2.2 of the HAProxy Data Plane API also adds support for file handling, SSL certificates, map files and configuration files for its Stream Processing Offload Engine (SPOE).

    HAProxy is best known for the open source load balancing software of the same name that is widely deployed by DevOps teams. As an extension of that platform, HAProxy Data Plane makes it possible to dynamically add and configure front ends and back ends and then route application traffic between them.

    Daniel Corbett, director of product and marketing for HAProxy, said the HAProxy load balancing software coupled with the Data Plane allows IT organizations to create a gateway through which they can manage their APIs.

    Corbett said the company is currently rounding out a suite of offerings, dubbed HAProxyOne, that are extensions to its load balancing software and that add a control plane and a service mesh to its portfolio. The company has already added a Kubernetes ingress controller to its portfolio.

    At the same time, however, HAProxy Data Plane will make it simpler for DevOps teams to integrate other offerings, such as Consul, within the control plane being developed by HAProxy, Corbett says.

    Corbett said, collectively, HAProxy will provide a suite of tools through which DevOps teams will be able to more easily manage application delivery across IT environments that span multiple platforms.

    HAProxy is not the only load balancing software provider with similar ambitions. The issue that HAProxy will address is the need for a framework that can apply equally well to both monolithic applications and microservices-based applications, Corbett says.

    In 2021, a major battle is brewing for control over the infrastructure that DevOps teams use to deploy applications at scale. Alongside proxy servers and load balancing software, IT organizations are starting to use API gateways, service meshes and ingress controllers as the number of APIs through which data flows rapidly increases. In effect, these technologies provide the connectivity infrastructure required to route data between the applications that make up a distributed computing environment.

    It’s still early days, though, as advocates for competing open source projects make their cases for the hearts and minds of developers. However, given the profound impact these decisions are likely to have on IT operations, it’s likely many organizations will soon standardize on one suite of offerings to minimize complexity.

    Whatever the result, applications environments are, in fact, becoming more complex. IT organizations will soon find themselves running monolithic applications alongside a raft of microservices-based applications, all of which need to use APIs to integrate with each other. Decisions made today about how best to integrate those APIs will have a profound impact for years to come.

  • Red Hat Expands RHEL Subscription Program for Developers

    Red Hat Expands RHEL Subscription Program for Developers

    Red Hat is extending its developer program to make it simpler for both individual developers and small teams to access a free Red Hat Enterprise Linux (RHEL) operating system subscription.

    These programs are launched in the wake of Red Hat’s decision to no longer invest in an open source CentOS Linux distribution project. Many developers employ CentOS to build applications that are later deployed on RHEL in a production environment.

    Starting in February, an existing no-cost Individual Developer subscription for RHEL can be used in production for up to 16 systems in an on-premises environment or in the cloud. Previously, developers were limited to using the subscription on a single machine. Red Hat is also making it easier for teams of developers to join this program at no additional cost via an existing subscription their organization may already have.

    In place of CentOS, Red Hat is positioning the CentOS Stream as a hub through which development teams will gain access to a continuously updated Linux distribution that will become the next minor update to RHEL. The Fedora project, managed by Red Hat, will continue to exist as the vehicle through which the RHEL community experiments with major innovations.

    Brian Exelbierd, head of RHEL community projects, said these changes should ultimately prove to be a boon to DevOps teams, as they will better align the instances of applications being developed with existing instances of RHEL running in production environments. Historically, there was a significant amount of effort required on the part of DevOps teams to move an application developed on CentOS to RHEL, said Exelbierd.

    At least two other entities have rushed to fill the perceived CentOS gap. Gregory Kurtzer, one of the co-founders of CentOS, along with the support of more than 650 contributors, has launched Rocky Linux to make sure IT organizations have access to a fork of RHEL without a subscription. At the same time, CloudLinux is pledging to spend $1 million annually to create a distribution of Linux, dubbed Project Lenix, that is also based on a fork of RHEL. CloudLinux previously provided a hardened edition of CentOS that has been installed more than 200,000 times by 4,000-plus customers.

    Exelbierd said Red Hat is not trying to subvert those efforts, but it does have a vested interest in making it simpler for developers to build applications that eventually get deployed on production systems. Red Hat only generates revenue when organizations pay to subscribe to an instance of RHEL that gets deployed in a production environment.

    Regardless of what operating system developers employ, unless organizations decide to deploy CentOS in production environments, all paths eventually lead to RHEL. It will be interesting to see how far organizations will go in supporting a fork of RHEL that, in many cases, was employed simply because a developer didn’t want to pay for full subscription.

  • Rookout Tool now Debugs Third-Party Code

    Rookout Tool now Debugs Third-Party Code

    Rookout revealed today it has extended its eponymous debugging tools to include third-party applications.

    Shahar Fogel, Rookout’s CEO, says most organizations today are building applications that rely heavily on code or modules developed by a third party. Rookout now makes it possible to analyze and debug that code before it is incorporated within a larger application environment, Fogel said.

    That’s crucial, because many of the operational issues a DevOps team is likely to encounter can be traced to flawed code written by someone outside of the IT organization, Fogel said. This new capability will reduce the amount of time DevOps teams spend trying to deduce the root cause of an issue, he said.

    Many IT organizations erroneously assume that all the code running in their environments has passed through a continuous integration/continuous deployment (CI/CD) environment, Fogel said. In reality, it’s not uncommon for developers to deploy code directly into a production environment in the name of expediency. Not all of that code, however, may have been written by the developer. Many developers wrongly assume the code they download from a repository was properly vetted and debugged.

    Rookout now makes it possible to debug both open source code and proprietary code written by a third party or present on an application deployment platform, said Fogel. Rookout collects the local variables, function arguments, tracing data, call stack and other relevant data, and can identify issues down to specific lines of code. Support for third-party code has been extended to the call stack level to enable developers to see how code execution flows across their own and third-party code.

    As more responsibility for applications shifts left toward developers, organizations need to provide them with tools to analyze applications and the platforms they run on. Beside building applications faster, one of the primary theoretical benefits of DevOps is the notion that developers can build more resilient applications, because it’s ultimately their responsibility to remediate any issues that arise after an application is deployed in production. In practice, that’s difficult to achieve when developers have no visibility into code that they didn’t write themselves.

    Going forward, there’s going to be a lot more third-party code running in production, as developers reuse application code encapsulated in containers downloaded directly from registries, Fogel said.

    The degree of accountability developers have for their appliations’ code currently varies widely by organization. However, given the right tools, and enough time, most developers would prefer to debug both the code they write and any they have incorporated, even if it were written by someone else. That desire, however, requires more time to build and test applications. Of course, it’s worth the tradeoff if developers encounter fewer incidents that require developers to debug applications after they are deployed in a production environment.

  • Internal Makes On-Premises Edition of No-Code Tool Available

    Internal Makes On-Premises Edition of No-Code Tool Available

    Internal today launched an on-premises edition of its eponymous no-code development platform that promises to simplify application development backlog reduction for enterprise IT organizations.

    Arisa Amano, CEO of Internal, said many professional developers regularly find themselves building simple applications that, if given access to the right tools, could be built instead by end users. Internal was created to provide that capability either through a cloud service or, now, through an on-premises edition.

    The on-premises edition makes it simpler for developers to work with databases, application programming interfaces (APIs) and applications that reside behind a corporate firewall, Amano said.

    As organizations accelerate digital business transformation initiatives, professional developers are pressed to build and deploy more complex applications faster. Many lower-priority application development projects are sidelined simply because developers don’t have time to take them on. Internal, and other no-code and low-code application development tool providers, are making a strong case for enabling end users to build their own applications using graphical tools, or encouraging professional developers to use these tools to build less complex applications more quickly.

    A survey published by Internal finds 62% of respondents report their developers spend more than 25% of their time fulfilling requests to build internal tools. More than three-quarters of respondents (79%) said engineers use any extra time they can find to develop customer-facing features or other applications.

    Most of the projects filling application backlogs tend to involve workflows that span multiple applications running in a data center. The challenge organizations face is low-code and no-code tools that reside in the cloud can’t easily access that data. As such, Amano said there’s a clear need for a no-code tool that can be deployed in an on-premises IT environment.

    Of course, regardless of who builds the application, it still must be deployed. Challenges arise as developers build more applications, which must be concurrently deployed in production environments. The addition of no-code and low-code tools, and the applications created with those tools, will require organizations to rethink and refine their DevOps processes.

    Historically, professional developers have tended to view no-code and low-code tools as the application development equivalent of a black box preventing them from building reliable, robust applications that can scale. Many low-code and no-code applications that organizations build, however, are meant to used internally by a finite number of end users. At the same time, no-code and low-code tools become more robust with each major update.

    Whatever bias may exist, the current application development backlog in most organizations is only going to increase. Professional developers may prefer to write code at a lower level than a no-code or low-code tool allows; however, most business executives are more interested in application performance than in how it was constructed.