ThoughtWorks Technology Radar: Istio, Knative, WebAssembly & Flutter are worth exploring
The latest edition of ThoughtWorks’ Technology Radar has highlighted what a lot of commentators already know: Istio and Knative are worth exploring but so are WebAssembly and Flutter. What’s even more interesting is that there are no languages, tools or platforms on the ‘adopt’ list so it’s safe to say that no one is missing out on anything.
The latest edition of the biannual Technology Radar from ThoughtWorks once again takes it upon itself to assess the major trends in software development. Central themes this time around include
- Sticky clouds: Once engaged with a cloud provider, customers may find that their relationship becomes stickier over time because of custom features and enticing offers.
- Lingering enterprise antipatterns: Technology changes fast, no one can deny that but the problems remain the same; organizations find it difficult to avoid typical enterprise antipatterns.
- Enduring engineering practices: This is the best long-term strategy to incorporate the variety and scope of technology innovation into teams effectively.
- Pace = Distance / Time: The pace of technology innovation has not slowed down and this can be seen in how long blips remain on the Radar. Therefore, the Radar creation process has been modified to reflect the ever-increasing pace of technology change.
As with every issue, the technologies, platforms, tools and languages are classified into one of four categories: The “Hold” category means that you should proceed with caution, whereas technologies falling under the “Assess” tag should go through a more detailed evaluation. Every technology, platform, tool and language that’s in the “Trial” category can or should be sampled in the corporate sector. Finally, when you see “Adopt,” you know that technology can and should be adopted.
Items which are either new or have gone through changes are represented as triangles and items that have not changed are represented as circles. The radar analyzes the trends in techniques, platforms, tools, and languages and frameworks.
Platforms: Say no to low-code platforms
It’s interesting that the ‘platforms’ category doesn’t include anything that needs to be adopted right away so you’re really not missing out on anything. Seven platforms are worth exploring, including Apache Atlas, GCP, and Azure.
Fun fact (not for AWS though): ThoughtWorks placed AWS in Adopt seven years ago but they have decided to move it back into Trial. Although there’s nothing wrong with it, let’s just say its competitors, GCP and Azure have matured considerably. That being said, the team feels that organizations should make a balanced selection across cloud providers that takes into account their geographic and regulatory footprint, their strategic alignment (or lack thereof) with the providers, and, of course, the fit between their most important needs and the cloud providers’ differentiating products.
CockroachDB is in Assess, along with Istio, Knative, and Pulumi, to name a few. Why Istio and not Linkerd, for example? Although the team is keeping a close eye on the progress of different open source service mesh projects, they have successfully used Istio in production and loved it. As far as Knative is concerned, this open source serverless platform integrates well with the popular Kubernetes ecosystem. Plus, vendor lock-in is not something you should be worried about so there are a lot of benefits to using it.
We’re also glad to see Quorum on the Assess list. Originally developed by J.P. Morgan, Quorum positions itself as “an enterprise-focused version of Ethereum.”
If there’s something you should really stay away from, that’s low-code platforms. Users are under the impression that you no longer need skilled development teams and, as ThoughtWorks explains in their PDF, “such suggestions ignore the fact that writing code is just a small part of what needs to happen to create high-quality software—practices such as source control, testing and careful design of solutions are just as important.” This doesn’t mean you can’t use them, just pay extra attention.
Languages & frameworks: Give WebAssembly a try
Again, nothing included in Adopt so you’re not missing out on anything. The Trial list contains four languages and frameworks, namely Jepsen, MMKV, MockK, and TypeScript. The latter is particularly important as ThoughtWorks’ browser-based code base continues to grow.
Flutter has also been included in Adopt thanks to the fact that it offers fast visual feedback when editing code. Plus, its hot-reload feature is impressive. Proceed with caution though, as Flutter is still in beta.
What makes Ktor special is the fact that it is written in Kotlin so it uses language features such as coroutines which allow for an asynchronous non-blocking implementation. Furthermore, its flexibility to incorporate different tools for logging, DI or a templates engine makes Ktor an interesting option for the ThoughtWorks team for creating RESTful services.
WebAssembly is supported by all major browsers and is backward compatible, and it’s designed to run in the browser at near-native speeds so what’s not to love about it? It opens up the range of languages you can use to write front-end functionality, with early focus on C, C++ and Rust, and it’s also an LLVM compilation target. WebAssembly is still in its early days but you should definitely give it a try.
WebFlux managed to impress the ThoughtWorks team and scored a spot on the Assess list. However, adopting
it requires a significant shift in thinking and you should factor this into the decision to choose WebFlux over Spring MVC.
Tools: Visual Studio Code won’t give you headaches
This section is really interesting so you should have a closer look at it.
Visual Studio Code has been included in Assess given the team’s good experience using this for front-end development using React and TypeScript, and back-end languages such as GoLang, without having to switch between different editors.
Plus, the tooling, language support and extensions are only getting bigger and better so you should definitely give it a try.
We’re also interested in Heptio Ark, a tool for managing disaster recovery for Kubernetes clusters and persistent volumes. It’s easy to use and configure and lets you back up and restore your clusters through a series of checkpoints. Plus, it will help you significantly reduce recovery time in case of an infrastructure failure, easily migrate Kubernetes resources from one cluster to another and replicate the production environment for testing and troubleshooting.
Techniques: Service meshes are worth exploring
We certainly saved the best for last as this category includes a lot of goodies. First of all, the Adopt list is not empty; you should seriously consider event storming. The microservices dream becomes a nightmare when you realize that the hope for faster time to market can only happen when services are cleanly sliced along long-lived business domain boundaries. The solution is event storming, thanks to its ability to rapidly identify and align a variety of stakeholders in the best way to slice potential solutions.
One technique that should be pursued is observability as code.
ThoughtWorks highly recommends treating your observability ecosystem configurations as code and adopt infrastructure as code for your monitoring and alerting infrastructure.
Although observability as code is an often-forgotten aspect of infrastructure as code, they believe it is crucial enough to be called out.
We’re big fans of HashiCorp’s Vault so we were pleasantly surprised to see secrets as a service on the Trial list. With this approach, applications retrieve secrets from a separate process (rather than hardwiring or configuring them as part of the environment). Vault, for example, allows you to manage secrets separately from the application and enforce policies such as frequent rotation externally.
Security chaos engineering is also worth pursuing. It has been moved to Trial because the teams using this technique are confident that the security policies they have in place are robust enough to handle common security failure modes.
You should also explore Chaos Katas, a technique the ThoughtWorks teams have developed to train and upskill infrastructure and platform engineers. In short, it combines Chaos Engineering techniques with the systematic teaching and training approach of Kata (which refers to code patterns that trigger controlled failures, allowing engineers to discover the problem, recover from the failure, run postmortem and find the root cause). Repeated execution of Katas helps engineers to internalize their new skills, as explained in ThoughtWorks’ PDF.
Service meshes are also worth exploring, especially since open source projects such as Linkerd and Istio will continue to mature and make service meshes even easier to implement.
The list of Hold is actually pretty long but we’ll only focus on one technique and that is generic cloud usage. A lot of organizations are prepared to use “any cloud” and to avoid vendor lock-in at all costs, which inevitably leads to generic cloud usage. The problem is that once you limit your use of the cloud to only the features that are common across all cloud providers, you miss out on the providers’ unique benefits. The lock-in problem is real so you should choose a multi-cloud strategy which evaluates the migration cost and effort of capabilities from one cloud to another against the benefits of using cloud-specific features.