Technical debt is often the unsung villain of the enterprise, crippling companies seeking to modernize as they realize just how much “legacy” lives in their stack. And as with most kinds of debt, there is usually interest to pay, too.
This is something that fledgling U.K. startup AppFactor is setting out to solve, with a platform that helps enterprises automatically re-architect their legacy applications, readying them for deployment into a new cloud-native home.
AppFactor was formally incorporated in mid-2021, however CEO and founder Keith Neilson has only been working on it fully since January, recently closing a pre-seed round of funding he says weighed in at north of £1 million ($1.3 million).
Presenting onstage today as part of the Startup Battlefield at TechCrunch Disrupt, Neilson showcased AppFactor’s technology and laid out his startup’s mission in a space ripe for change. TechCrunch caught up with Neilson ahead of time to get the lowdown on the scale of the problem as he sees it, and what — exactly — AppFactor is doing to address it.
AppFactor team. Image Credits: AppFactor
Visibility
To outsiders, some technical debt might be obvious through exposure to bugs or laggy systems. Or, perhaps, the amount of time it takes the company to improve existing products and introduce new features.
Those on the inside, meanwhile, might have a better idea of their technical debt when they see that their IT budget spend is weighted disproportionality toward maintenance versus building shiny new things. Data from consultancy McKinsey suggests that technical debt could account for as much as 40% of companies’ total IT budget, while a separate report from Stripe indicates that developers on average spend a third of their working week addressing existing technology issues rather than writing new code.
But it’s not always easy to get a clear picture of the level of technical debt a company has, due to the fact that it might span multiple areas and domains within an organization. This opaque underbelly may include things like overly complex, duplicate or downright bad code; a lack of automated testing; security vulnerabilities; and general poor design.
“The big challenge enterprises have is that they’ve built and architected enterprise-grade applications at a [specific] point in time, and business requirements and processes change the environments around these applications, and the applications and their dependencies evolve over time,” Neilson said.
Thus, technical debt — as McKinsey notes — can perhaps best be viewed as a sort of “tax” a company pays on all internal development that’s focused on fixing myriad legacy technology infrastructures. This includes new libraries and frameworks, or integration points and dependency changes as companies fine-tune their stack. Ultimately, it amounts to a whole mish-mash of complexity that snowballs over time to create an unwieldy mess.
A typical example of a legacy enterprise application might involve an older Microsoft SQL database; some middleware layer; and a .NET front end, requiring a mixture of physical and virtual infrastructure to function. The running processes, libraries, dependencies and general componentry permeating the application and infrastructure would require significant manual spadework just to figure out what is what, as they attempt a lift-and-shift transformation to a more cloud-native form.
And that, essentially, is what AppFactor is setting out to offer. It scans the company’s IT environment to identify all their apps and respective dependencies, “divorces” the virtual and physically-hosted apps from their current environment, and rebuilds each component and app layer into separate containers ready for their new home — be that a modern cloud architecture such as Kubernetes, or a managed database service.
“All of this is generated and driven by the product [AppFactor], so you can rapidly move your existing application estates over to the latest cloud technology within days, not months and years,” Neilson said.
AppFactor: App modernization module overview (due out in November). Image Credits: AppFactor
Under the hood
AppFactor consists of three core components, including a scanner/analyzer that’s deployed to servers to collect the data needed to unearth their applications and dependencies; an “orchestrator,” which essentially controls the scanner/analyzer’s behavior, including the IP range and target systems; and the overarching AppFactor SaaS platform that handles all the data analysis, machine learning (ML) processes and services that generate visual mappings, containerization tasks and more.
The company says it has been working with some commercial clients, including U.K.-based enterprise software company Civica. To date, only the “discover and assess” facet of its platform has been commercially available. However, the company is also gearing up to launch its “app modernization” module in November. So this means customers will have the ability not only to find suitable candidates for modernization, serving all the relevant reporting and analytics, but eventually enact the transformation itself.
Perhaps one of the more interesting features of the platform — from a slick bells-and-whistles perspective, at least — is a tool that enables users to visualize app dependencies through a 3D visualization engine. Eventually, this could be used to visualize entire environments.
“Currently it’s at more of an infrastructure and process level view, but clearly there is scope to go deeper down, which we plan on building out,” Neilson said.
Curiously, AppFactor is also making this available for VR headsets, with the company demoing this functionality via an Oculus at its TC Disrupt booth.
“One of the toughest activities upfront that can help de-risk any [app] changes is being able to account, view and understand dependencies — be it across infrastructure, architecture or code,” Neilson said. “This view is about being able to view and interact with the makeup and anatomy of our application estates in a granular and powerful way. Some of these systems are incredibly complex, with communications, libraries, files, services, processes and more happening in a magnitude of places, across multiple environments so this is a really powerful way of being able to intuitively understand, validate and reaffirm knowledge, which empowers any future evolution of the application and it’s attributes.”
AppFactor: Visualize app dependencies and entire environments through 3D visualization engine. Image Credits: AppFactor
State of play
Current app modernization tooling is substantively manual, and therefore resource-intensive. It might involve using a command-line tool like Docker, which requires significant continuous testing, and even then might not cover the full gamut of dependencies due to the manual nature of running the tool. And the likes of Google’s Migrate for Anthos, which resulted from its Velostrata acquisition five years ago, and AWS’s App2Container make it somewhat easier for enterprises to convert virtual machines (VMs) to containers. However, these are still very manual and command-line based, don’t necessarily provide extensive visibility into dependencies and don’t support physical infrastructure-based apps.
There are other similar-ish services out there too focused on helping companies transition from monolithic software to microservices, such as venture-backed Vfunction.
The ultimate goal of each of these services is to help companies reduce their technical debt and “get with the times,” albeit adopting slightly different approaches en route.
“We believe there are four pillars of technical debt — infrastructure, architecture, code and dependencies,” Neilson said. “We also believe that there are many applications that do not suit microservices, so our vision is to allow the attributes of an enterprise app dictate the optimum architecture pattern.”
The AI factor
To achieve this, AppFactor says it’s developing machine learning classifications to help generate the patterns necessary to transform more complex, “multi-host” apps. Essentially, it’s about creating “fingerprinting” techniques to identify what complex or bespoke apps are made of.
“We are using a trained data model to build this, and it employs a number of attributes and datapoints that can help identify application patterns,” Neilson said.
Additionally, Neilson said that they’re experimenting with a number of other AI use-cases, including large language models (LLMs) to generate the YAML (a human-readable data serialization language for creating configuration files) for Kubernetes deployments
“We have some [other] future use cases around code generation, but we’re not there yet,” Neilson added.
