Cloud providers know they're competing in a tight market, and to succeed, they need to sign up and retain long-term customers. Thus, to stay competitive, they race to add new features, and we see them reaching feature parity, which is reflected in our placing of AWS, GCP, and Azure in the Trial ring in this edition. However, once customers sign up, these providers tend to create as sticky a connection as possible with their customers to discourage roaming to another provider. Often this manifests in a strong dependency on their specific suite of services and tools, offering a better developer experience as long as customers stay with them. Some companies are taken by surprise when the stickiness becomes apparent, often at the time of making a choice to move parts or all of their workloads to another cloud or finding their cloud usage and payments spiraling out of control. We encourage our clients to use either the run cost as architecture fitness function technique to monitor the cost of operation as an indicator of stickiness or Kubernetes and containers to increase workload portability and reduce the cost of change to another cloud through infrastructure as code. In this Radar, we also introduce two new cloud infrastructure automation tools, Terragrunt and Pulumi. While we support assessing the new offerings of your cloud provider through the lens of stickiness, we caution against generic cloud usage. In our experience, the overhead of creating and maintaining cloud-agnostic abstraction layers outweigh the exit cost for a particular provider.
No matter how fast technology changes, enterprises still find ways to reimplement antipatterns from the past. Many of our Hold entries decry an old wolf hiding in new sheep's clothing: enterprise service bus (ESB) behavior implemented on event-streaming platforms—Recreating ESB antipatterns with Kafka, Layered microservices architecture, Data-hungry packages, Overambitious API gateways, Low-code platforms and other noxious old practices. The fundamental problem, as always, is the balance between isolation and coupling: we isolate things to make them manageable from a technical perspective, but then we need to add coordination to make them useful for solving business problems, resulting in some form of coupling. Thus, these old patterns keep re-emerging. New architectures and tools provide appropriate ways to solve these problems, but that requires deliberate effort to understand how to use them appropriately and how to avoid falling back to reimplementing old patterns with shiny new technology.
One side effect of the increased pace of technological innovation is a repeating expansion and contraction pattern. When an innovation appears that fundamentally changes how we think about some aspect of software development, the industry races to adopt it: containerization, reactive frontends, machine learning and so on. That's the expansion phase. However, to make this "new thing" truly effective requires figuring out how to apply enduring engineering practices to it: continuous delivery, testing, collaboration and so on. The contraction phase occurs as we ascertain how to use this new capability effectively, creating a firm foundation to allow the next explosive expansion. During this phase we learn how to apply practices such as comprehensive automated testing and the scripting of sequences of recurring steps within the context of the new technology. Often, this goes hand in hand with the creation of new development tools. While it may seem that the introduction of a new technological innovation alone advances our industry, it's the combination of innovation with enduring engineering practices that underpins our continued progress.
Our themes usually highlight a pattern we've seen over a handful of entries in the current Radar, but this one concerns all the entries over the lifetime of the Radar. We've noticed (and we've done some research to back it up) that the length of time our blips remain in the Radar is falling. When we started the Radar a decade ago, the default for entries was to remain for two Radar editions (approximately one year) with no movement before they fade away automatically. However, as indicated by the formula in this theme's title, pace = distance over time: change in the software development ecosystem continues to accelerate. Time has remained constant (we still create the Radar twice a year), but the distance traveled in terms of technology innovation has noticeably increased, providing yet more evidence of what's obvious to any astute observer: the pace of technology change continues to increase. We see increased pace in all our Radar quadrants and also in our client's appetite to adopt new and diverse technology choices. Consequently, we modified our traditional default for this Radar: now, each entry must appear in the Radar based on its current merit—we no longer allow them to stay by default. We made this change after careful consideration, feeling that it allows us to better capture the frenetic pace of change ever present in the technology ecosystem.
We publish articles related to the Technology Radar throughout the year. Subscribe to stay informed.
Vol.19
The Technology Radar is prepared by the ThoughtWorks Technology Advisory Board, comprised of:
Download the latest and past editions
ThoughtWorks ist ein Technologie-Unternehmen – und eine Gemeinschaft von engagierten, zielorientierten Menschen. Wir arbeiten disruptiv und entwickeln so Lösungen, die den höchsten Ansprüchen unserer Kunden gerecht werden. Unsere langfristige Mission ist es, die IT-Branche zu revolutionieren und die Gesellschaft positiv zu beeinflussen.
