ThoughtWorks Tech Radar: May 2020 Goodies
The Radar is a document that sets out the changes that we at ThoughtWorks think are currently interesting in software development — things in motion that we think you should pay attention to and consider using in your projects. It reflects the idiosyncratic opinion of a bunch of senior technologists and is based on our day-to-day work and experiences (Source)
Disclaimer: This post is an opinionated distillation from the already opinionated Tech Radar. It does not reflect the views of my employer, ThoughtWorks.
I have deliberately divided the items in horizontal buckets rather than vertical ones. I won’t be describing in detail what the tool or technique does, but only my opinion about it. I mean, you can always Google to find what it does, no?
ADOPT
Pipelines as Code (PaC):
Infrastructure as code (IaC) created quite a stir in the tech community upon its inception a few years ago. Once tech teams became more serious about it, they started versioning and storing configs for the CI/CD pipelines too. (Jenkin, GoCD etc.) . But not all CI/CD systems supported the PaC model. Tool creators clearly saw the writing on the wall and were quick to provide support for PaC. I hardly know of projects who don’t at least partially do PaC. It’s a mature practice in most engineering oriented orgs and the rest of the industry is catching up fast. (* as Code all the things!!)
Istio:
This entrant is my favorite. We are aware of the impact Google’s Kubernetes platform had on the container ecosystem. Istio is the cherry on the top; alleviates pain of many of the auxiliary activities (certs, observe, control etc.). Istio has had a breakneck rise in the Radar since Nov 2018 (Assess) through Apr 2019 (Trial) to now (Adopt). Sidecars FTW. It’s been ready for the prime time since long. Just use it already!
Microfrontends:
I’ll be honest. I considered the Microfrontend concept as a crude attempt of front end engineers to be taken seriously in the age of Microservices. But I couldn’t have been more wrong. If decentralized and ownership driven concept of Microservices is so effective, why let such an important part of the system (aka frontend) remain monolithic? . It makes sense for individual teams to own the frontend for their domain too and then have an aggregator compose the UI. (Alert: It requires tech maturity to effectively implement it)
TRIAL
Rust:
Rust has had a meteoric rise in systems programming community due to its type safe, garbage collection free and zero cost abstraction language model. And indeed it’s great! Although the learning curve is quite steep, once the concepts click, the productivity and safety it provides is amazing.
Google, Microsoft etc. are betting on the language and I won’t be surprised to find it in ‘Adopt’ quadrant within a year. ThoughtWorks used Rust in one of the open source projects called Epirust. It is a simulation framework for modelling epidemics and has very high performance requirements.
But be wary of using Rust in run of the mill enterprise ecosystem, as in this context, Rust does not provide any more value than Kotlin, Java or C#.
Firebase
I don’t agree with the ‘Trial’ tag for Firebasee. It is very mature and has been ready for the prime time since long. Google got on the BaaS bandwagon with acquisition of Firebase in 2014. Since then I have only heard good things about it, mostly around its generous free tier and services like realtime sync and cloud functions. It makes mobile backend development a breeze.
Mural:
With permanent WFH fast becoming the new reality, the interactivity of physical collaboration with actual stickies is greatly missed. Google’s Jamboard tried to address it, but I never liked it.
Behold Mural. I have been using it since two weeks and it’s a DELIGHFUL experience. The larger than life digital wall and the fluid and real time interactivity is something Google and Microsoft should try to emulate. It just rocks. (Alert: little expensive license).
ASSESS
MeilSearch:
This is my biased opinion (tautology?) but search has always fascinated me. And let’s be honest, most use cases don’t need Google or DuckDuckGo level search engines. ElasticSearch, Solr etc are good enough. The issue occurs when the tools have to be fine tuned for use cases. MeilSearch is like Algolia that aims to address the user driven search (and not advanced analysis that ElasticSearch enables). In essence, it has a very limited use case, but it works pretty well for that case.
AsyncAPI:
OpenAPI like standard for the event driven universe. Enough said.
ConfigCat
It’s a feature toggle management as a service. Read Martin Fowler’s article for details.
The core competency aside, what impressed me about ConfigCat is the sheer number of languages/frameworks its SDK supports. Also, it supports many integrations (Slack, GitHub etc.). Although a competitive space, ConfigCat’s edge lies in their pricing and compatibility with existing tools.
Sizzy
This is an impressive entrant to address the user interface viewport hell. Google and AWS have pretty good services for this use case, but Sizzy seems promising with novel use cases. However, being very new, the enterprise risk-o-meter may go wild.
HOLD
Long Lived Branches with GitFlow
ThoughtWorks has been quite vocal in its disapproval of the branching model (GitFlow or otherwise). There is nothing inherently wrong with the model, except its applicability to the context. Open source unequivocally needs a branching/PR based model. But a team of developers following XP principles and working on a product in the same company are better off using trunk based development. My thumb rule is that if your commit team size is more than 30 and distributed, GitFlow may help. In any case, I recommend starting with the Trunk/master based development to begin with and then switch to GitFlow if possible.
That’s it! Those were some tools that caught my attention. The Radar of course is a much more comprehensive guide. Urge everyone to check it out. You can download the PDF here.
