Technology Radar November 2016 by ThoughtWorks

Last Tuesday, I rode on my bike through the Berlin rain to the ThoughtWorks Werkstatt. While I was riding, I asked myself constantly, why the hell I take all this effort for just visiting a meetup at such an ugly rainy November evening. Luckily, I got a fast answer. The Technology Radar November 2016 (pdf version) event was pretty solid organized. A collection of healthy food and drinks were provided, and for the next one hour I was able to join an excellent tech talk by Eric Dörnenburg.

At the beginning of the talk, Eric explained the history and the idea behind the Technology Radar. If you don’t know their Technology Radar yet, then I recommend to read the article Build your own Technology Radar by Neal Ford first. All the mentioned techniques, tools, languages, frameworks, and platforms are related to their business and enterprise applications. Therefore a little warning in the beginning, this blog post won’t be really interesting for readers with interests on media art, creative technology, game development, and so on. Furthermore, I visited this presentation with the intention to explore new methodologies & technologies from an Indie Web and decentralized web point of view.



The topic techniques is a collection of design and development processes.  Methods for organizing code and team structures are also a part of this collection.

Consumer-driven contract testing (for APIs) is kinda the counterpart of user-centered design for backend developers. It describes a method how a developer team can create a good and appropriate web service API. It starts that the consumers of the API write test code for this API. The test code is then an accurate description, how the consumers expect the API is supposed to work. In my opinion, this kind of methodology helps to make a web service better understandable and explorable. Moreover, it can have a positive influence on the code quality of decentralized infrastructures. The microservices idea and its distributed system movement is pretty similar to the decentralize web and indie web tooling. Therefore, why not adapting such established techniques from the enterprise field to our field?!

The next approach is related to organizing a group of developers. The idea dealing an API as a product defines the ownership of a service much more clear. Additional, the dedicated team for the service are all responsible to solve the problems and maintain a decent level of service quality.

Not to mention, that the team is also responsible to deliver Micro Frontends to their microservice. Especially, in the context of personal clouds (like Cozy Cloud & Sandstorm). Most of them run with an app or plugin infrastructure. At the moment, with Cozy Cloud and Sandstorm, developers have to implement multiple-times the same frontends, if they want to access their various running services. It would be very nice if those apps (running as a microservice) would provide additionally some related frontend UIs (for e.g. WebComponents). Such UI could be easily used for another private cloud app. Similar applications are currently and mostly solved with iframes (like YouTube, Vimeo, etc.). In some circumstance copy&paste HTML code is another offered alternative. In that context, the developers have to check if they don’t run into security sandbox issues or other library versioning problems (e.g. running two different versions of React on the same site). Even the file sizes of imported codes have to be considered! In a short conclusion, some issues exist with this approach, but it is possible to figure out some (good) workarounds in the future.

Beyond that mentioned coding practices, it seems privacy became the new luxury good. I agree that the analysis of user behavior is a critical tool for implementing a successful user interface. The approach of differential privacy enables such analytics without destroying the privacy of your users. The method is still very young and not yet well applied in the enterprise world. Now, it is a good time to change this and it is also the responsibility of developers to push that approach in the right direction.

In my opinion, ownership and control of your data will be one of the important topics in the next years. Identify and classify potential threats related to this topic is a critical process. The technique Thread Modelling can help you in that context. Microsoft used (or is still using) this technique very intensively. They even published their gamification approach of a card game. I think that techniques can help the decentralize web movement to define their strength better.



The tools section is much more shorter as the chapter before. It was pretty interesting part of the presentation, but I have to admit I don’t know each tool from the list. The tools Babel, Consul, Webpack, Let’s Encrypt and so on I know, and I totally agree with the described status quo. There is nothing to add from my side. Therefore, just a few very short thoughts.

At some talks, I heard that the most people secure the API Gateway, but not each mircroservice within their network. I am not an expert about this, but my inner feeling says I would like to secure each microservice. In that context, I have played around with JSON Web tokens some time ago. (Un)Fortunately, each service needs a secret token for interacting/talking with another microservice. Implementing token storage for each microservice, would produce pretty much redundant code on the whole microservice infrastructure. It seems HashiCorp Vault is a valid solution for storing such keys. Maybe it could be useful for managing the keys of decentralized web (backend) applications, too.

A tool for instrumenting microservices is ZipKin. Their distributed tracing system helps to troubleshoot latency problems in microservice architectures. Accordingly to Eric from ThoughtWorks, they made some good experiences with this tool. I think this tool is pretty cool for debugging selfhosted microservices.



A lot of things are happening in this platform category. We discussed during the presentation a few times about the intersections of OpenVR, Unity and HoloLens. I am not a big fan of VR and that session doesn’t change my opinion about that. I am still waiting for AR/VR glasses as describe in this Anime TV Show Dennō Coil. Before, I won’t be interested and amazed with VR at all.

The topic Electron is known in the Web Developers community, but has not reached the mainstream yet. That confirms my feelings about it. It is a nice tool for creating cross-platform desktop clients and has definitely a value for every (indie/decentralize) web developer. In that context I like also the competitor NW.js very much. It seems an easier start for inexperienced developers.

The hype about Docker is pretty present in the microservice community. I think everyone is excited about the approach of containerize complex infrastructures. Docker provides such a containerization platform with a great community and a more and more mature eco-system. Especially, everyone with interests on selfhosting is the big winner. Docker makes the installations process (see also the term PaaS) much more accessible for them. For instance, apps like FreshRSS, LessPass, Etherpad  could be easily installed on your managed server, Raspberry Pi, or on your NAS with a Docker image. The private cloud Protonet has already started to jump onto the Docker ship. Sandstorm decided to apply a virtualization approach to their system, though they support Vagrant instead of Docker. However, everything develops in the right direction for a better indie / decentralized web.

Authorization and Authentication are not simple task to solve for developers. Auth0 provides a pretty solid service and several SDKs for this. From Social Logins (e.g. Facebook, Twitter) to OAuth2 infrastructure, everything is offered by them. Eric mentioned during the presentation, that it might not be the best idea to outsource such an important part from your applications. From an decentralized web point of view, Auth0 is no alternative for me, even I agree that they are really good in what they are doing. IndieAuth and PassportJS could be an alternative. In my opinion, the overhead work is worth to stay independent.

Alternative currencies are a big topic (or hype) in the decentralized web community. Me, as an Ex-Banker, doesn’t get so excited about it. In my opinion, it is just a question of time until the full (old) power forces take over this market. Then we will experience again the same market mechanisms (or even worse turbo-capitalism oriented mechanisms). However, the most interesting feature of Ethereum is the built-in programming language for smart contracts. That could be another approach for implementing autonomous trades within a complete digital/electronic ecosystem (similar to the algorithmic trading applied to the stock market Xetra). However, that platform could be interesting for exchanging data items or  IoT resources within the decentralized web community.

The last point of this chapter is about setting Superficial Private Cloud on hold. That means in-house productions seam to struggle with an inefficient way of deployment and development. Selfhosting a cloud causes to much costs and obstacles for in-house developers. It makes sense to observe this topic in detail for every in-house application or decentralized web app. The objective should be to improve the situation and don’t make it worse. Failures or obstacles are always a great opportunity to learn and improve things. Solving those problems can help the indie/decentralize web to avoid the same pitfalls.


Languages and Frameworks

Discussions about programming languages and frameworks on conference end mostly with a bad fight. Some developers see them as a belief system or a religion. Therefore, I won’t make any statement here. Choosing the right language and the appropriate framework for your use case depends so much on your context, that it makes no sense to do a discussion here.

At least it seems ThoughtWorks prefers EmberJS and React against Angular2. Eric mentioned the great community behind EmberJS as one of their driving forces. For me and my past with Adobe/Apache Flex, it is easier to work with Angular 2. And jucheee here I can experience the classical context issue. However, I recommend reading the list of statements by ThoughtWorks on that category. They articulated some very valid and interesting points, which helped me to understand their bigger picture of this field.



I am pretty thankful that a company like ThoughtWorks opens up their technology research for the community. The meetings at ThoughtWorks Werkstatt in Berlin are always surrounded by a very welcoming atmosphere, thanks a lot for this! And thanks for the opportunity to compare my own knowledge & opinions with the others.




Share Post :

More Posts

Leave a Reply