devopsy.kinsta.cloud

Tag: legacy applications

How eBPF and OpenTelemetry Have Simplified the Observability Function

While many IT and engineering leaders understand the benefits of a comprehensive observability practice, achieving full visibility still presents some challenges. For example, instrumentation for new applications or off-the-shelf software often can be a time-consuming and complex process. As a result, engineering teams can be led to avoid observability in certain parts of their environments. When hurdles to observability exist and subsequently halt these efforts, systems are in more danger of disruptions or going completely dark. This can lead to serious business consequences such as financial losses, legal issues, and damage to brand reputation.

OpenTelemetry eBPF Instrumentation (OBI) makes getting this data a cinch. It allows engineering teams to confidently lean into observability without any manual setup steps. Consequently, teams can rapidly gain visibility into their services and infrastructure.

The Challenges to Complete Visibility

There are several hurdles related to comprehensive observability, ranging from instrumentation effort to setting up the correct alerts, dashboards, and more. While automatic instrumentation solutions have existed for language runtimes like the JVM, .Net CLR, and others, traditional auto-instrumentation approaches usually have trouble with compiled languages such as Go, Rust, and C++. With certain legacy services, the source code may be so old that it is extremely difficult to modify. Furthermore, with commercial-off-the-shelf applications, the source may not be accessible at all.

Today’s IT environments are also more complex than they’ve ever been, which can lead to observability complications. In enterprise-level organizations, there is commonly a mix of apps that were heavily instrumented with proprietary observability vendor software development kits (SDKs) and some apps that lack instrumentation altogether. This complex mix results in duplicate metrics and fragmented or missing data, making it harder for organizations to translate observability into actionable insights.

Lastly, security concerns can slow the implementation of a proper observability practice. Many observability agents require high-level permissions to function, which can raise concerns if they are closed source and the organizations deploying them can’t validate their software supply chain.

While these challenges are real for many organizations, the combination of eBPF and OpenTelemetry equally presents real solutions to break through these barriers.

Why eBPF and OpenTelemetry Are a Great Match

Combined, eBPF and OpenTelemetry offer instrumentation that strategically pulls back the obstacles to full-scale observability. OBI removes the requirement for code updates or application configuration changes. Thanks to eBPF, instrumentation occurs at the kernel level and provides instant, zero-code, visibility into an organization’s Kubernetes cluster or Linux environment. Removing the need to touch existing code or introduce new code to the application itself removes a whole class of code-related issues that businesses encounter when instrumenting their applications.

OBI is language agnostic. Regardless of the language an application is using, network traffic observability takes place at the protocol layer. There, organizations can gain insights from traces and metrics for any application. This is even true for legacy applications and applications where the source is unavailable.

Through eBPF, OpenTelemetry can also help organizations navigate some of the complexity and black box nature existent within modern IT systems. If an organization leverages an SDK for instrumentation, OBI can identify the instrumentation and avoid re-instrumenting the application. This technology also works to combine the best parts of OpenTelemetry’s automatic language runtime instrumentation with OBI.

When it comes to third-party software, the eBPF and OpenTelemetry combination monitors network calls to applications that aren’t easily instrumented — including databases such as SQL, Redis, and MongoDB — at the kernel level. There, it can provide Rate, Errors, and Duration (RED) metrics, helping narrow down the source of performance problems to applications or dependencies.

OBI also works seamlessly alongside existing OpenTelemetry auto-instrumentation to make adoption simple and risk-free. It intelligently detects services that are already instrumented and avoids duplicating telemetry. This ensures clean, accurate data without extra configuration.

Removing the Final Barrier to Entry for OpenTelemetry

OpenTelemetry has become the industry standard for gathering machine data; any observability practice is incomplete without it. It offers a wide range of advantages. This includes a large set of integrations, freedom to customize your data and send it to any destinations of your choice, and a consistent data model and semantic conventions.

Recently, Splunk donated the OpenTelemetry Injector, which led to easier, less intrusive instrumentation for applications written in most programming languages. With OBI, developed by Splunk and Grafana Labs, practically any application can now be observed without instrumentation, language, or security complications. In turn, everyone can build a leading observability practice. The best advantage, however, is one that extends past simpler instrumentation. OBI lets organizations spend less time instrumenting and experimenting with getting data out of the observability system. Now, engineers have more time to develop new features and enhance their organization’s overall applications and services.

Tools like the OpenTelemetry Injector and OBI underscore Splunk’s commitment to building an inclusive, resilient observability community. By enabling teams to more easily leverage OpenTelemetry, these tools help ensure data reaches its full potential while giving developers time back, reducing operational risk, and ultimately strengthening organizational resilience.

March 13, 2026
The Gift That Keeps On Giving

May 15, 2024
IBM LLM AI: COBOL to Java ASAP ¦ ARM IPO is GO!

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: Translating legacy COBOL code to a slightly more modern language, and Arm will go public (again) next month. (more…)

August 23, 2023
Developer Familiarity is Key to Digital Success

For some time, the goal of digital transformation was to replace legacy systems. It became a battle between all that was new and shiny and that which was old, outdated and “had to go.” However, this philosophy has since shifted as companies realized two crucial facts.

First, legacy systems are often too important to be phased out entirely for traditional organizations—given SQL’s flexibility and familiarity among developers, for example. As a result, many of these legacy applications and systems are instead being converted into virtual versions of their former selves.

Also, while it’s not impossible for some organizations to reinvent themselves as greenfield businesses that rely entirely on new, cutting-edge technologies, that is a route that is usually resource-intensive and time-consuming for many companies, at least for the foreseeable future.

Second, tossing out legacy systems disrupts existing skills—and not in a good way—especially given that 64% of digital architects report being locked into using them because they have invested heavily in the relevant skills. Furthermore, overtly focusing on new talent excludes many IT professionals with well-honed skills and considerable knowledge about business processes and systems relationships. And, at the same time, digital skills are expensive—not just to acquire but also to upskill. Even startups—which often have a literal “system blank check”—are facing skills constraints, and many are considering bringing more established skills into emerging tech environments.

The Developer Skills Problem

Digital transformation is now in the spotlight thanks to the COVID-19 pandemic, and project managers have consequently accrued valuable experience on what makes transformation projects successful. Recent surveys conducted by 451 Research revealed that 44% of companies are well into the execution stages of their transformation strategies and of that group, 66% are starting to see success. Another 10% declared their transformation projects to be a complete success.

Archimedes said he could move the planet with a sufficiently large lever. For digital transformation goals, skills are that tectonic lever. According to a report from WorldSkills UK, 60% of businesses believe that their reliance on advanced digital skills will increase. Pressure relating to skills requirements is not going anywhere, and the competition between legacy and new technologies only compounds it further.

As you might expect, developers are caught in the middle. As the world digitizes—witness the acceleration of digital projects over the past two years—developers have emerged as the heroes. Perhaps unsurprisingly, 92% of respondents to a Couchbase survey agreed with that statement. Around 63% also revealed that a proper development culture allowed them the flexibility to change their goals pertaining to digital transformation outcomes.

Yet whenever digital projects get stuck, developers are often blamed for the delays. According to the same research, at least one-fifth of developers do not have the skills or access to technology that they need. Many also aren’t given the support or space to deliver and an astounding 49% say they are being asked to do too much in too little time.

Digital transformation projects have been increasingly successful, and we can thank developers for much of that success. But those successes haven’t alleviated the pressures or problems surrounding skills, and many projects consequently still get stuck. Furthermore, a recent report by Gartner found that IT executives are struggling to source skills that enable cloud and edge adoption.

Legacy is Not the Enemy

If we combine these points (the need for continual support for legacy, emerging modernization demands, increasing developer skills shortages and the fate of established technology experts), they appear to be at odds with each other. Something must give, right?

Not necessarily. There is growing acknowledgment that orphaning legacy skills is a mistake. Doing so can cannibalize skill sets and business knowledge that should be retained. There’s also the realization that we don’t need to juxtapose legacy and newer technologies. Modern systems can incorporate and even absorb legacy environments, coding languages and processes.

Modern multi-model databases provide a good example. At a high level, we can group databases into relational (SQL) and non-relational (NoSQL) systems. SQL databases cannot provide the agility NoSQL systems are known for, yet it’s a technology approach that still delivers many benefits. Multi-model database systems, where a SQL developer can use SQL coding on a NoSQL system, accomplish both.

A New Place for Established Developer Skills

Creating this familiarity is essential for successful digital projects. Focusing exclusively on broad reskilling or continually hunting for new talent aren’t the only ways to meet the demands required by modern enterprises. Instead of asking if developers can go to the mountain, vendors should ask: Can we bring the mountain to the developers?

Deploying new technologies that can leverage existing developer skills is becoming increasingly popular. Besides certain databases, we also see this with mainframes connected to web services via APIs and using microservices to accentuate specific parts of legacy environments.

Consider Lehman’s famous laws of software evolution, among which are familiarity and organizational stability. Most modernization projects ignore these two laws in favor of brute force progress. But digital modernization is a journey, and every successful journey needs all hands on deck—not dead weight and stowaways. Providing developers that which they already know best in a new environment is the key to digital success.

November 9, 2021
Are ERP-Centric Enterprises Being Left Behind?

Many large enterprise companies are rife with departments that depend on customized ERP software applications. These systems accommodate vital business tasks ranging from inventory management to ordering capabilities to accounting programs to CRM platforms—all of which were custom-built to fit the enterprise’s specific needs and meet the KPIs of each unique organization. These applications tend to sustain grades, patches and reworks, sometimes resulting in multiple redesigns over the course of decades, and these often are not properly documented. To make matters worse, these ERP software systems also tend to be written in outdated programming languages such as ABAP for SAP and PL/SQL for Oracle, making them a challenge to update.

For example, 91% of respondents in a recent ASUG survey of 110 SAP companies said they use custom code, and 41% of those applications were created at least six years ago. The majority of these companies said that the existence of these custom code environments has become a hindrance to digital transformation and is holding back innovation.

These conditions create the bloated and overly complex legacy environments that are now commonplace in the enterprise market. Widespread, customized core business systems have made digital transformation particularly daunting for enterprise companies. They require significant developer resources, excessive time commitment and ample expense to strip down and redesign these custom systems for the cloud.

A Lack of Developers—and of Developer Interest

U.S. Department of Labor statistics from December 2020 indicated that there will be a shortage of 40 million skilled workers worldwide, amplifying these issues further. That figure is predicted to grow to 85.2 million by 2030. What’s more, new developers entering the marketplace gravitate to more contemporary programming languages such as JavaScript and Python, as opposed to wanting to revamp archaic code used in most ERP solutions, such as ABAP.

For this reason, large enterprise companies in a range of verticals are lagging behind when it comes to upgrading mission-critical software applications to the cloud or to a more modern architecture. These organizations are well aware they stand to gain significant productivity benefits from digitally transforming their systems so that, for example, inventory data can be accessed via a mobile device or shared from anywhere on a cloud-based platform. Yet these large organizations are stalled in their efforts to modernize. Some companies have gone as far as to scrap their current systems and start reprogramming their software applications from scratch—a hugely expensive, lengthy and laborious endeavor that’s also full of risk.

Leveraging Low-Code to Simplify Enterprise IT Environments

One method that has shown progress in unraveling these overwrought environments is to apply automation through low-code integration. Ideally, an effective low-code development solution will automatically convert existing business processes to modern, cloud-native applications, allowing the organization to maintain the business logic it has built into those applications over the years, while drastically reducing the time commitment, costs and potential disruption associated with traditional, long-form integration. In SAP environments, for example, using a low-code rapid application development solution can separate the application layer from the core SAP system, automating a large portion of the migration while preserving a “clean” SAP core.

With many organizations under pressure to keep budgets under control in what continues to be an uncertain economy, these large-scale companies are looking for ways to modernize their operations on a more controlled schedule. When enterprises use low-code solutions—and furthermore, don’t have to search for developers of these more archaic languages—they’re free to approach digital transformation in a far more incremental and cost-effective way.

For instance, the 12 million users of SAP’s solutions are being compelled to upgrade to the modernized version of its product, S/4HANA. Yet the American SAP User Group (ASUG) research shows that only 33% of these organizations have taken on the challenge so far despite the looming end-of-life of the current prevalent version. This is because lacking a low-code development solution, companies are being pressured to convert and rebuild all their business processes in one fell swoop. Few organizations have the resources to absorb such a drastic and risk-prone undertaking.

A rapid application development program acts as a bridge for companies that are looking to modernize their businesses, allowing them to upgrade their applications incrementally, according to their own schedules. Low-code can be a catalyst for technical debt-ridden enterprises, allowing them to simplify complicated legacy environments and get down to the business of innovating their systems.

October 6, 2021
Moving Legacy Applications to the Cloud

Even in 2021, many companies still run business-critical, legacy applications on-premises, just as they have for the last 20 to 30 years. The midrange server hardware, and their unique architecture, on which many of these applications run is both their biggest drawback and biggest advantage; the benefits of being able to vertically scale a platform were measured against the drawbacks of the necessary custom hardware. Migrating the workloads running on these types of systems to the cloud, which can potentially offer huge benefits, presents some unique challenges – here are four strategies for doing this, with pros and cons for each.

Option 1: Lift and Shift

The “lift and shift” option means you’re simply representing the on-premises network within a cloud service provider. This is the easiest and quickest option.

Until recently, this was not an option for most legacy applications. This was because the main hyperscale clouds did not offer dedicated infrastructure as-a-service (IaaS) implementations for several common data center operating systems. The process required purchasing a vast amount of dedicated hardware to offer as-a-service to customers, and it wasn’t clear if the demand warranted that cash outlay.

Recently, however, it’s clear that the only way for organizations can leave behind the data center is by moving business-critical applications to the cloud. There are now hyperscale cloud providers that offer lift and shift options for even the most demanding workloads.

Despite these benefits, it’s important that a lift and shift approach is carefully planned before executing. Even a couple of seconds of downtime in traditional application workloads can cost businesses thousands of dollars. Finally, organizations should understand that they won’t be using the cloud to its full potential simply by recreating their on-premises environment.

Option 2: Rewriting or Refactoring

Refactoring a traditional application into a cloud native application has been the de facto migration option for many years. It provides greater long-term cost savings than other options, because previously underprovisioned data center resources can now be consumed on-demand in the native FaaS offerings of hyperscale cloud providers. The compute capacity is nearly limitless, and only scales as resources are being used.

However, refactoring to cloud native services does have major risks, such as high short-term costs. Refactoring an existing business-critical application is typically much more complex than a simple lift and shift. Also, an application that has been part of the core business stack will have likely accrued many dependencies and interfaces with other systems and added modules that must be accounted for.

Another consideration is that legacy interfaces must appear identical to other systems post-migration, otherwise you must expand the scope — including other systems in the migration project that originally weren’t planned. Many of the hyperscale cloud providers do not support legacy interfaces in their cloud native services. Scope creep can become a real issue in this scenario, and your organization could lose sight of the migration timeline.

An enterprise service bus (ESB) is one potential solution to the problem of legacy interfaces. An ESB is typically deployed as a “bus” between various business applications, ensuring that all those interfaces use a common interface. The ESB handles the network, transport, routing and delivery of messages and content. However, ESBs add yet another layer of complexity, increasing the risk of failure for the overall refactoring project.

Option 3: Dynamic Lift and Shift (Reshape)

Reshaping an application to the cloud typically lies somewhere between the lift and shift and the refactoring strategies. It’s similar to lift and shift, but usually involves some minor modification to the application to take advantage of native tools within the cloud infrastructure. An example is adding automated launch and tear down of development and test environments.

One of the main advantages of a reshaping is that it is cost-effective. An organization will see significant cost savings over a simple lift and shift, for example, by only having to pay for the hours that the development and testing machines are powered up and running.

It also means that the development teams are free to experiment with refactoring certain applications without a hard deadline (such as a data center exit.) Finally, a dynamic lift and shift strategy allows development teams to leverage cloud native functionality, such as infrastructure as code, to automate traditional workloads without retraining on a whole new development stack.

Option 4: Drop and Replace with COTS

Another option is to replace your custom application for one that is commercial off the shelf (COTS). For example, replacing a custom-built customer relationship management (CRM) system with a vendor’s product.

This is not feasible for some organizations because of their business environment constraints, but it is recommended when possible. COTS products (that are typically SaaS) usually have a repository for various connectors to different legacy applications; however, this is largely dependent on the size and maturity of the COTS product.

It’s important to note that one of the largest risks of considering a COTS application is the skills within the organization. If the current development team’s skillset lies with custom, traditional applications, they will need extra time to retrain and develop the extensions to integrate the COTS product with their existing environment.

Migrating any application to the cloud is a large undertaking. There will always be risks when moving existing on-premises applications to the cloud, but in general, the overall positive impact of moving legacy applications far outweigh any risks, regardless of the approach you decide to take.

January 22, 2021
Application Modernization Video with IBM’s Rosalind Radcliffe

Application modernization is the process of updating existing legacy applications and modernizing their infrastructure, architecture and features, by using modern technology stacks. Monolithic applications are difficult to update and expensive to scale.

In response to today’s business requirements of growth and innovation, enterprises must deliver new applications in an agile fashion while minimizing risk. Many have turned to a hybrid or multicloud strategy where choice and flexibility are foundational.

In this interview, Rosalind Radcliffe, distinguished engineer at IBM, explains the benefits of modernizing applications and how IBM provides all essential components to update your legacy applications.

Rosalind will take a deeper look at application modernization during her session at IBM DevOps Virtual Summit. During the virtual event, attendees will learn how to keep their applications running smoothly with automation and data-driven solutions that can reduce mean time to resolution and explore IBM solutions to help innovate hybrid environments, disrupt cloud native development and transform existing mainframe infrastructures. The free virtual event will take place on Oct. 29 at 10 a.m. ET.

For more information and to register, please visit the IBM DevOps Virtual Summit website.

October 27, 2020
Best of 2019: Five Microservices Worst Practices

As we close out 2019, we at devopsy.kinsta.cloud wanted to highlight the five most popular articles of the year. Following is the first in our weeklong series of the Best of 2019.

Microservices are moving to the mainstream. The IDC FutureScape: Worldwide IT Industry 2019 Predictions states that by 2022, 90% of all new apps will feature microservices architecture that “improve the ability to design, debug, update and leverage third-party code.”

With so many organizations adopting or about to adopt microservices, they must be doing something right. In fact, just considering the model is a positive step toward delivering quality software, faster. However, many companies are leaving microservices benefits on the table because there are many pitfalls on the road to success. It’s about so much more than just a technology choice and starting to code microservices.

Indeed, breaking your apps into microservices isn’t enough—you have to manage them, orchestrate them and deal with the data they create and modify. Before you even touch the keyboard it’s a good idea to think about a few points of strategy to ensure success.

Here are five microservices worst practices and how to turn them around.

Implementing Microservices Without the Prerequisites

You can’t take Calculus II without taking Calculus I. Similarly, you can’t roll out microservices without the proper prerequisites. To fully leverage microservices, companies must consider modularity and domain boundaries, and the fundamental distributed systems theory should be considered and established. In addition, while each service is independent, there are operational requirements that must be met. These include DevOps; PaaS; containers or immutable VMs; service replication, registry and discovery; and proactive monitoring and alerts.

Implementing Microservices Without Making Changes to the Development Culture

The biggest mistake organizations make when moving to a microservices architecture model is underestimating how it’s changing the way they need to think about applications and especially the way they think about the teams developing those applications. Traditionally, there are many people involved in the development of an application, with each coming at it from his or her own perspective—the UI specialist, the middleware specialist, DBAs, sysadmins and so on. What worked for one might not work for the other when it gets thrown over the wall, and it often takes a lot of time and frustration to make everything work for everyone. Trying to do microservices without changing that model and mindset will almost certainly set your team up for failure. Instead, think in terms of cohesive, cross-functional teams, each fully responsible for its own unique services and its own set of customers for those services. Each team’s working with other teams as if it’s a business-to-business (B2B) relationship. It’s not an easy cultural transition, but it’s one that is essential for microservices to work.

Going Too Big and Broad Out of the Gate

An organization that goes all-in on microservices all at once is almost certain to run into problems that could completely derail the initiative altogether. Pick a small project, and staff it with people who see the potential of microservices and are excited to work with the technology. Once that project has been successfully completed, use it as a proof point to promote the further use of microservices across the organization and to get others on board.

Misplaced Expectations

Organizations are right to question the performance impact that microservices will have when migrating an existing monolithic application to a microservices model. But their concerns—and expectations—are often misplaced. Yes, there can be a performance hit when decomposing existing monolithic applications in favor of microservices. But what organizations need to understand is the goal of microservices is deployment speed over API invocation speed.

Isolating the development of a service within a team (as mentioned earlier) means the service can be updated as needed—whether that’s weekly, daily or even hourly—in response to business, competitive and security demands. In its Worldwide IT Industry 2019 Predictions report, IDC notes it is “already seeing enterprises that have shifted fully to these new approaches (and supporting tools and technologies) that dramatically accelerate their ability to push out digital innovation through their organization at 50-100 times (or more) the frequency of their traditional approaches.”

Picking the Wrong Applications to Microservice-ize

This worst practice is linked closely to the previous one. Organizations that pick the wrong applications to split into microservices or decompose an entire monolith without thinking about which parts might be best as microservices (and which would fail miserably as microservices) will have the odds stacked against them from the get-go. A financial application or a high-volume application that makes multiple calls may not be good candidates for microservices. Or, it may be that parts of these applications would work well in the microservices model even if the monolith as a whole doesn’t. The idea is to examine each legacy application carefully and to build new applications with microservices in mind from the beginning.

If you’re thinking that it takes a lot to establish a microservices foundation, you’re right. It’s a big investment, and it may take some time before there is a return on that investment. But organizations that move toward microservices in a thoughtful, purposeful way—exploiting the best practices of those that have gone before them—will likely find themselves more agile, more secure and more competitive.

— Eric Schabell

December 26, 2019
App Mobility Is the New Use Case

Selling increased investment in DevOps is not always easy. It takes time to implement, resource away from other projects and inevitably there is cash outlay. If not done carefully, it also appears to introduce chaos, something most of us in IT strive to avoid.

But the benefits, at this point, are easy to document. Plenty of companies have tried and succeeded in moving to a more agile/DevOps approach to deployment. Yes, companies have failed, but the publicly acknowledged failures have also been dissected for lessons learned, which can help in your transformation.

Every advice site suggests tying DevOps/digital transformation to business goals, which is a good idea, but is harder to do most of the time.

Not any more. The truth is the future is mobile. Not as in mobile phones or cross platform (though both have a place in the future), but in the ability to run an app where it makes the most sense today with the knowledge that tomorrow there might be a better place to run it.

Historically, the architectural choices of yesterday’s teams become a burden on today’s teams. I’ve worked at a major insurer where a mainframe flat file DB system was keeping an application from moving. I’ve worked at a power company where we were not allowed to modify a system running on OS/2 because no one quite knew how to maintain it. I’ve worked at an energy services company where I spent a year trying to re-create Novell IPX solutions in an Ethernet environment…The list goes on.

What if we could avoid leaving such a legacy to future teams, and be more responsive to business needs/profitability in the future? That is, in a nutshell, what containers offer you. Today, you are running your app internally in a container management system. Tomorrow you’re running it on AWS in a container management system.

There are things to watch out for–most vendor-sponsored container management makes it very easy to use containers on their platform of choice, but difficult to move containers. IBM, as one of the least intrusive examples, offers integration with their proprietary tools. Once you’ve taken those integrations, your mobility/options are more limited. As I mentioned, IBM is one of the more open companies out there. They offer value for tying you down, but if you don’t need those services, it’s better not to use them so you can move the application at will.

Situations change, and containers allow for those changes. You may have a huge budget for external cloud apps today, but reasons ranging from internal cost decisions to regulatory changes could force your organization to reconsider options in just a few short months.

That makes mobility important to business. So does cost management. No matter what the cheapest architecture to deploy on tomorrow is, wherever makes the most sense is going to be a hit.

But how portable are they? Depends upon the app, and the implementation. An application that is developed as a group, able to run in a single pod (or multiple exact copies in multiple pods) is an easy thing to move about. One with containers spread across a variety of platforms, each doing what it is best at, will be more difficult to move. Persistent storage kind of guarantees that most enterprise apps have limited mobility–at least for the time being.

Any app that can be moved to the cloud can be containerized first, granting mobility that means no need for massive conversion efforts if the cloud doesn’t work out. Any app pulled back from the cloud to the DC has the same potential, the issue of where the data lives is real no matter what architecture is chosen for implementation. But for any app that can be moved, it can be put into containers and moved far more easily in the future. For many apps, it is simply dropping it into the new environment and configuring networking to route traffic to the new location.

We’re already going to leave future teams with a hodge-podge of databases, programming languages and networking tools such as WAF/load balancing. Let’s make life a little easier on them, and help increase the use of DevOps, by deploying with containers and targeting whatever makes sense for the org today, secure that tomorrow that can change and our burden will be less than it might have been.

— Don Macvittie

December 19, 2019
Investing in a Mobile Device Testing Lab

It will likely come as no surprise that app downloads are on the rise, with no signs of slowing down. Today’s consumers use apps for everything from ordering food, to shopping for clothes, to managing money and more.

In fact, according to a recent report by App Annie, consumers downloaded a total of 194 billion apps in 2018, up from 178 billion apps in 2017.

Yet, the same report shows that app retention rates after 90 days are low–ranging from 32% to a meager 4%.

Reasons for app deletion vary, but far too many apps, in a burgeoning sea of apps, are either hastily and incompletely tested or aren’t even tested at all. This can lead to poor consumer experience, deleted apps and even negative feelings about a brand itself.

Therefore, it’s critical for mobile app developers and practitioners to button up their testing practices before release. Otherwise, you run the risk that all the work you put into your app will only lead to the dreaded and overcrowded app graveyard.

Overcoming Today’s App Testing Limitations

The primary challenge prohibiting companies from properly testing their apps is access to real-time devices in the same instantaneous, maintainable and scalable infrastructure. The expectations around continuous testing in desktop, web and packaged applications is difficult to achieve in mobile testing without a device cloud, which delivers seamless access to real devices in an on-demand infrastructure and brings order to the chaos of managing multiple mobile devices in a test lab.

A cloud-based mobile testing lab provides a comprehensive solution that solves issues around mobile app testing, including too many device types and operating systems to test, as well as a lack of people and time to test. It offers real-time, continuous access to real devices for all mobile testing needs, resulting in higher quality apps and increased customer satisfaction and retention.

An added bonus is a cloud-based mobile testing lab frees app testers from initiating and monitoring automated tests. Basically, testers can automate their automation. This, in turn, allows them to perform other significant tasks that can increase user acceptance, engagement and experience.

Failure Looms with Little or No Testing

That being said, some organizations, in a rush to go to market, release an app with little to no mobile testing at all. They believe testing is too difficult, too time-intensive or too costly to be worth their while. Some think minimal web testing will keep them out of trouble when it comes to mobile. And although we all like to think that we write bug-free code, unfortunately this isn’t always the case.

Furthermore, there are those who will test their app and then release it before fixing all the bugs, thinking they can test and improve along the way. However, that way of thinking can be detrimental to a company and its brand. Localytics found technical failure as simple as an image not loading can lead to a 29% loss of customers.

Mobile App Testing Helps Ensure a Thumbs Up

The average U.S. adult, according to an eMarketer study, spends 3.75 hours on mobile devices each day, with nearly three of those hours using apps. Further, Statista estimates app downloads to grow to 258.2 billion in 2022. Clearly, the app market is thriving, but so is the competition. You’ll have a better chance of standing out in the crowd if your app works–flawlessly.

A mobile device testing lab could be one of the key solutions that will help separate the proverbial app wheat from the chaff. By testing apps in real time, you understand which types of devices are most affected should a crash occur. Analytics show what app features are used most, allowing you to prioritize what should be fixed first during the testing process.

The future of apps is in mobile, which is why mobile testing will continue converging with legacy applications such as web and desktop. Forward-looking companies need an approach that allows top-of-line technologies to work together as if provided by a single solution provider.

A mobile device testing lab helps you break through the barriers of app development. In doing so, your app has a better chance of doing what you say it will do–without crashes–hopefully earning your app a coveted spot on users’ home screens instead of the trash.

— Dan McFall

November 18, 2019