Themes for this edition
The Shifting Shape of Data
A decade ago, data was synonymous with relational databases. Now, data can take on a staggering variety of shapes, including NoSQL, time series, SQL stores such as CockroachDB and Spanner that offer global consistency as well as event streams that offer querying capabilities to aggregated log files. This is driven by businesses' desires for ever more real-time responses to increasingly larger, more varied and faster data sources. For developers, understanding the trade-offs inherent with each flavor of data usage can pose challenges. Architects and developers should be on the lookout for new capabilities offered by tools and paradigms while remaining diligent that they don't misuse new tools by treating them too much like familiar ones. We should embrace the fact that we're in the middle of a major shift in the data landscape and still searching for the proper strategies and tools.
Terraforming an Ecosystem
Developers love abstraction layers, for obvious reasons: by encapsulating complexity into an abstraction they can focus on higher-level concerns. We've seen this evolution across several editions of the Radar in the way teams deal with the intersections of clouds and containers. First, the action focused on Docker and its ecosystem. Then, focus shifted down the stack to Kubernetes. Now, the main activity we see is on infrastructure as code in general and the Terraform ecosystem in particular. Although we've recommended tools beyond Terraform, its adoption in the community of providers has been impressive. Highlights in this Radar include Terratest for testing infrastructure code, and GoCD's new Provider, which lets you configure GoCD using Terraform.
Kotlin Klimbing
Kotlin, the open-source language, continues to receive strong representation in our Radar as it expands beyond its Android stronghold. Created internally at JetBrains, because they didn't like the options available in the existing language landscape, and subsequently released under an open-source license, Kotlin seems to resonate with developers across a wide spectrum. It keeps appearing across platforms and tools as a general and special purpose development language, and increasingly also in our Radar and on our project teams (e.g., Ktor, MockK, Detekt, HTTP4K). It's refreshing to see that pragmatic design, state-of-the-art tooling, and a burgeoning ecosystem allow an upstart language to succeed.
Leaking Encapsulation Boundaries
With the advent of "everything as code," almost everything — infrastructure, security, compliance and operations — formerly difficult to change becomes programmatically addressable, meaning that developers could apply good engineering practices; yet all too often we see either highly complex configuration subsystems or over-reliance on visual orchestration tools — logic creeping into configuration files, horrible syntax for conditionals in YAML, and the many orchestration frameworks we saw across a wide variety of technologies. With the advent of polyglot programming, infrastructure as code and x-as-a-service, teams end up with varying components that merge into a single cohesive system. Thus, logic that should reside within a system boundary leaks out into orchestration tools, configuration files, and other plumbing. While this is sometimes necessary, we encourage teams to carefully consider keeping such code in places where developers adhere to testing, version control, continuous integration, and other good engineering practices. Avoid adding business logic in configuration files (and avoid tools that require it), and try to keep necessary orchestration to a minimum rather than a dominant feature of your system.
Selected Insights
We publish articles related to the Technology Radar throughout the year. Subscribe to stay informed.
Contributors
Vol.20
The Technology Radar is prepared by the ThoughtWorks Technology Advisory Board, comprised of:
Downloads
Download the latest and past editions
