Enable javascript in your browser for better experience. Need to know to enable it? Go here.


Adopt ?

Trial ?

  • As the focus on improving the developer experience and efficiency increases across organizations, we're seeing Backstage rise in popularity, alongside the adoption of developer portals. These organizations are looking to support and streamline their development environments. As the number of tools and technologies increases, some form of standardization is becoming increasingly important for consistency so that developers can focus on innovation and product development instead of getting bogged down with reinventing the wheel. Backstage is an open-source developer portal platform created by Spotify. It's based on software templates, unifying infrastructure tooling and consistent and centralized technical documentation. The plugin architecture allows for extensibility and adaptability into an organization's infrastructure ecosystem. We'll be watching the new Backstage Service Catalog, currently in alpha, which keeps track of ownership and metadata for all the software in an organization's ecosystem.

  • ClickHouse is an open-source, columnar online analytical processing (OLAP) database for real-time analytics. It started as an experimental project in 2009 and since has matured into a highly performant and linearly scalable analytical database. It's efficient query processing engine together with data compression makes it suitable to run interactive queries without pre-aggregation. We've used ClickHouse and are quite impressed with its performance.

  • Kafka is a common default for event-driven architectures, but adapting it to legacy environments introduces an impedance mismatch. In a few cases, we've had success minimizing the legacy complexity using Confluent Kafka REST Proxy. The proxy allows developers to access Kafka through an HTTP interface, which is useful in environments that make using the native Kafka protocol difficult. For example, we were able to consume events emitted through SAP simply by having the SAP team invoke an HTTP POST command through a preconfigured SAP remote function call, avoiding the need to spin up a Java abstraction around SAP (and a team to manage it). The proxy is quite full-featured, although, as with any such adapter tool, we recommend caution and a clear-eyed view of the trade-offs involved. We believe the proxy is valuable when it enables legacy producers to send events, but would be careful creating event consumers through the proxy as the abstraction gets more complex. The proxy doesn't change the fact that Kafka consumers are stateful, which means that consumer instances created through the REST API are tied to a specific proxy, and the need to make an HTTP call to consume messages from a topic changes the standard semantics of Kafka eventing.

  • Despite our cautionary advice when we last blipped it, we've seen continued enthusiasm for GitHub Actions. What we said before still holds true: GitHub Actions is not yet a full-fledged CI/CD replacement for complex workflows. It cannot, for example, re-trigger a single job of a workflow, call other actions inside a composite action or support a shared library. Furthermore, while the ecosystem in the GitHub Marketplace offers obvious advantages, giving third-party GitHub Actions access to your build pipeline risks sharing secrets in insecure ways (we recommend following GitHub's advice on security hardening). Despite those concerns, the convenience of creating your build workflow directly in GitHub next to your source code is a compelling option for some teams, and act helps you run GitHub Actions locally. As always, we recommend a clear-eyed assessment of the trade-offs, but some of our teams are happy with the simplicity of GitHub Actions.

  • K3s is a lightweight Kubernetes distribution built for IoT and edge computing. You get the benefits of a fully compliant Kubernetes but with reduced operational overhead. Its enhancements include lightweight storage backends (sqlite3 as default instead of etcd), a single binary package with minimal OS dependencies and reduced memory footprint, all of which make K3s suitable for resource-constrained environments. We've used K3s in point-of-sale machines, and we're quite happy with our decision.

  • Mambu is a SaaS cloud banking platform. It empowers customers to easily and flexibly build and change their banking and lending products. Unlike other out-of-box core banking platforms that you can only adapt with hard-coded integration, Mambu is designed for constantly changing financial offerings. It comes with an opinionated workflow, while also providing an API-driven approach to customize business logic, process and integrations. We currently have several projects using Mambu. With its cloud-based scalability and highly customizable capabilities, it's becoming one of the sensible default domain systems when building financial products.

  • MirrorMaker 2.0 (also known as MM2), built using the Kafka Connect framework, solves many tool shortcomings of previous Kafka replication approaches. It can successfully geo-replicate topic data and metadata across clusters, including offsets, consumer groups and authorization command lines (ACLs). MM2 preserves partitioning and detects new topics and partitions. We appreciated the ability to stage a cluster migration over time, an approach that can be useful in migrating from an on-prem cluster to a cloud cluster. After synchronizing the topics and consumer groups, we first migrated the clients to the new cluster location, then we migrated the producers to the new location and finally turned off MM2 and decommissioned the old cluster. We've also seen MM2 used in disaster recovery and high-availability scenarios.

  • OPA Gatekeeper for Kubernetes is a customizable admission webhook for Kubernetes that enforces policies executed by the Open Policy Agent (OPA). We're using this extension of the Kubernetes platform to add a security layer to clusters, providing automated governance mechanisms that ensure applications are compliant with defined policies. Our teams like it because of its customization capability; using CustomResourceDefinitions (CRD) allows us to define ConstraintTemplates and Constraints which make defining rules and the objects (e.g., deployments, jobs, cron jobs) and namespaces under evaluation an easy task.

  • We've been seeing an increase in teams using Pulumi in various organizations. Pulumi fills a gaping hole in the infrastructure coding world where Terraform maintains a firm hold. While Terraform is a tried-and-true standby, its declarative nature suffers from inadequate abstraction facilities and limited testability. Terraform is adequate when the infrastructure is entirely static, but dynamic infrastructure definitions call for a real programming language. Pulumi distinguishes itself by allowing configurations to be written in TypeScript/JavaScript, Python and Go — no markup language or templating required. Pulumi is tightly focused on cloud-native architectures — including containers, serverless functions and data services — and provides good support for Kubernetes. Recently, AWS CDK has mounted a challenge, but Pulumi remains the only cloud-neutral tool in this area.

  • Kubernetes natively supports a key-value object known as a secret. However, by default, Kubernetes secrets aren't really secret. They're handled separately from other key-value data so that precautions or access control can be applied separately. There is support for encrypting secrets before they are stored in etcd, but the secrets start out as plain text fields in configuration files. Sealed Secrets is a combination operator and command-line utility that uses asymmetric keys to encrypt secrets so that they can only be decrypted by the controller in the cluster. This process ensures that the secrets won't be compromised while they sit in the configuration files that define a Kubernetes deployment. Once encrypted, these files can be safely shared or stored alongside other deployment artifacts.

  • Since we first evaluated JAMstack, we've seen more and more web applications of this style. However, when the infrastructure for building traditional dynamic websites and back-end services is too heavy for JAMstack, our teams choose Vercel. Vercel is a cloud platform for static site hosting. More importantly, it provides a seamless workflow for developing, previewing and shipping JAMstack sites. The configuration for the deployment is quite simple. By integrating with GitHub, each code commit or pull request could trigger a new website deployment that has a URL for preview, which greatly accelerates development feedback. Vercel also uses CDN to scale and speed up production sites. It's worth mentioning that the team behind Vercel also supports another popular framework, Next.js.

  • Weights & Biases is a machine learning (ML) platform for building models faster through experiment tracking, data set versioning, visualizing model performance and model management. You can integrate it with existing ML code and quickly get live metrics, terminal logs and system statistics streamed to the dashboard for further analysis. Our teams have used Weights & Biases, and we like its collaborative approach to model building.

Assess ?

  • Azure Cognitive Search provides search as a service for applications that require text search over heterogeneous content. It provides push or pull-based APIs to upload and index images, unstructured text or structured document content, with limitations on supported pull-based data source types. It provides APIs over REST and .NET SDK to execute search queries, either using a simple query language or more powerful Apache Lucene queries with field-scoped queries, fuzzy search, infix and suffix wildcard search and regular expression search, among other features. We've successfully used Azure Cognitive Search alongside other Azure services, including searching content uploaded from Cosmos DB.

  • Even today, considering all the development and infrastructure tools at our disposal, we often reach a point where we need a script to glue several things together or to automate a recurring task. Current favorites for writing these scripts are bash and Python, but we're happy to report that there's a new, exciting option: Clojure. This is made possible with Babashka, a complete Clojure run time implemented with GraalVM. Babashka ships with libraries that cover most of the use cases for which you'd use a scripting tool, and loading of further libraries is possible, too. The use of GraalVM brings startup times within range of native tools, and it also makes Babashka one of the few options for a multithreaded scripting environment, for those rare cases when it's needed.

  • ExternalDNS synchronizes Kubernetes ingresses and services with external DNS providers, filling a hole previously filled by kops dns-controller, Zalando's Mate or route53-kubernetes — the last two of which have been deprecated in favor of ExternalDNS. The tool makes internal Kubernetes resources discoverable via public DNS servers, removing a sometimes manual step to update DNS records when an ingress host or service's IP address changes. It supports a huge list of DNS service providers out of the box with more being added via community support. As the old joke goes, it's always DNS.

  • Konga is an open-source UI for administering the Kong API Gateway, previously featured in the Radar in Trial. Our teams liked the quick setup and rich feature set that allowed them to experiment with and try out configurations easily. And the fact it's open-source software eases concerns about licensing costs.

  • Milvus 2.0 is a cloud-native, open-source vector database built to search and manage embedding vectors generated by machine-learning models and neural networks. It supports several vector indexes for approximate nearest neighbors (ANN) search across embedding vectors of audio, video, image or any unstructured data. Milvus 2.0 is a relatively new database, and we recommend you assess it for your similarity search needs.

  • It's rare for us to feature commercial, off-the-shelf software in the Radar, much less a core banking platform. However, Thought Machine Vault (no connection to Thoughtworks) is an example of a product in this class designed to support good software engineering practices such as test-driven development, continuous delivery and infrastructure as code. Developers define banking products in Vault by writing smart contracts in Python code. This is distinctly different from the standard no-code approach where customization is done through graphical interfaces or proprietary configuration files or both. Because products are defined in regular Python code, developers have access to a range of tools such as test frameworks and version control to ensure that their work is safe and accurate. We wish more financial services platforms were designed with developer effectiveness in mind.

  • XTDB is an open-source document database with bitemporal graph queries. It natively supports two time axes for each record: valid time, when a fact occurs, and transaction time, when a fact is processed and recorded by the database. Support for bitemporality is beneficial in numerous scenarios, including analytical use cases executing time-aware queries; auditing historical changes to facts; supporting distributed data architectures that must guarantee globally consistent point-in-time queries such as data mesh; and preserving data immutability. XTDB takes information in document form, expressed in the Extensible Data Notation (EDN) format, a subset of the Clojure language. XTDB supports graph as well as SQL queries and is extensible through a REST API layer and Kafka Connect, among other modules. We're excited to see a growth in adoption of XTDB and the addition of features such as support for transactions and SQL.

Hold ?

Moved in/out
No change

Unable to find something you expected to see?


Each edition of the Radar features blips reflecting what we came across during the previous six months. We might have covered what you are looking for on a previous Radar already. We sometimes cull things just because there are too many to talk about. A blip might also be missing because the Radar reflects our experience, it is not based on a comprehensive market analysis.

Unable to find something you expected to see?


Each edition of the Radar features blips reflecting what we came across during the previous six months. We might have covered what you are looking for on a previous Radar already. We sometimes cull things just because there are too many to talk about. A blip might also be missing because the Radar reflects our experience, it is not based on a comprehensive market analysis.


Download Technology Radar Volume 25

English | Español | Português | 中文


Stay informed about technology


Subscribe now

Visit our archive to read previous volumes