• HTTP Strict Transport Security (HSTS) is a now widely supported policy that allows websites to protect themselves from downgrade attacks. A downgrade attack in the context of HTTPS is one that can cause users of your site to fall back to HTTP rather than HTTPS, allowing for further attacks such as man-in-the-middle attacks. With HSTS, the server sends a header that informs the browser that it should only use HTTPS to access the website. Browser support is now widespread enough that this easy-to-implement feature should be added to any site using HTTPS. Mozilla's Observatory can help identify this and other useful headers and configuration options that improve security and privacy. When implementing HSTS, it is critical to verify that all resources load properly over HTTPS, because once HSTS is turned on, there is (almost) no turning back until the expiry time. The directive to include subdomains should be added but, again, a thorough verification that all subdomains support secure transport is required.

  • The Principle of Least Privilege encourages us to restrict software components to access only the resources that they need. By default, however, a Linux process can do anything its running user can do—from binding to arbitrary ports to spawning new shells. The Linux Security Modules (LSM) framework, which allows for security extensions to be plugged into the kernel, has been used to implement MAC on Linux. SELinux and AppArmor are the predominant and best-known LSM-compatible implementations that ship with the kernel. We recommend that teams learn to use one of these security frameworks (which is why we placed it in the Adopt ring). They help teams assess questions about who has access to what resources on shared hosts, including contained services. This conservative approach to access management will help teams build security into their SDLC processes.


  • We've continued to have positive experiences deploying the Apache Mesos platform to manage cluster resources for highly distributed systems. Mesos abstracts out underlying computing resources such as CPU and storage, aiming to provide efficient utilization while maintaining isolation. Mesos includes Chronos for distributed and fault-tolerant execution of scheduled jobs, and Marathon for orchestrating long-running processes in containers.

  • We have a growing belief that for most scenarios it is rarely worth rolling your own authentication code. Outsourced identity management speeds up delivery, reduces mistakes and tends to enable a faster response to newly discovered vulnerabilities. Auth0 has particularly impressed us in this field for its ease of integration, range of protocols and connectors supported, and rich management API.

  • The huge number of mobile devices makes it almost impossible for companies to test their mobile apps on all of them. Enter AWS Device Farm, an app-testing service that enables you to run and interact with your Android, iOS and web apps on a wide variety of physical devices that are hosted in the cloud simultaneously. Detailed logs, performance graphs and screenshots are generated during each run to provide general and device-specific feedback. The service offers a lot of flexibility by allowing the state and configuration of each device to be altered in order to reproduce very specific test scenarios. Our teams are using AWS Device Farm to run end-to-end tests on devices with the largest install base for their apps.

  • Our teams continue to enjoy using AWS Lambda and are beginning to use it to experiment with serverless architectures, combining Lambda with the API Gateway. We do recommend that Lambda functions contain only a moderate amount of code. Ensuring the quality of a solution based on a tangle of many large Lambda functions is difficult, and such a solution may not be cost-effective. For more complex needs, deployments based on containers or VMs are still preferable. In addition, we have run into significant problems using Java for Lambda functions, with erratic latencies up to several seconds as the Lambda container is started. Of course, you can sidestep this issue by using JavaScript or Python, and if Lambda functions do not contain a lot of code, the choice of programming language should not matter too much.

  • As monolithic applications are being replaced with more complex (micro)service ecosystems, tracing requests across multiple services is becoming the norm. With majority contribution from LightStep and Uber OpenTracing is rapidly becoming the de facto standard for distributed tracing. There is a growing number of tracers supporting OpenTracing standard, including Zipkin, Instana, and Jaeger. OpenTracing currently provides vendor-neutral implementation in multiple languages including: Go, JavaScript, Java, Python, Objective-C, C#, C++, Ruby and PHP.

  • After experiencing years of growth as a platform for game development, Unity has recently become the platform of choice for VR and AR application development. Whether you're creating a fully immersive world for the Oculus or HTC Vive headsets, a holographic layer for your newly spatial enterprise application or an AR feature set for your mobile app, Unity likely provides what you need to both prototype it and get it ready for prime time. Many of us at ThoughtWorks believe that VR and AR represent the next significant shift in the computing platform, and for now, Unity is the single most important tool in the toolbox we use to develop for this change. We've used Unity to develop all our VR prototypes, as well as AR functionality for headsets and phone/tablet applications.


  • .NET Core is an open source modular product for creating applications that can be easily deployed in Windows, macOS and Linux. .NET Core makes it possible to build cross-platform web applications using ASP.NET Core with a set of tools, libraries and frameworks—another choice for microservices architecture. The community around .NET Core and other related projects has been growing. New tools have appeared and evolved quickly, such as Visual Studio Code. There are Docker images based on both Linux and Windows (Nano Server) with .NET Core that simplify applying a microservice architecture. CoreCLR and CoreFX appeared in the Radar in the past. However, a few months ago Microsoft announced the release of .NET Core 1.0, the first stable version. We see good new opportunities, changes and a vibrant community as reasons to keep assessing this product.

  • Amazon API Gateway enables developers to expose API services to Internet clients. It offers the usual API gateway features including traffic management, monitoring, authentication and authorization. Our teams have had positive experiences using this service to front AWS Lambda as part of serverless architectures. On the other hand, we have had more challenges using it as a more general purpose gateway to front HTTP/HTTPS endpoints running on EC2—where we have been stymied by a lack of interoperability with VPCs and difficulty in establishing client cert authentication with the gateway. Due to this mixed experience, we would like to advise teams to trial using AWS API Gateway with Lambda but assess suitability when using it in a more general setting.

  • In parallel with the recent surge of chatbots and voice platforms, we've seen a proliferation of tools and platforms such as that provide a service to extract intent from text and management of conversational flow that you can hook into. Recently acquired by Google, this "natural-language-understanding as a service" offering competes with other players in this space such as and Amazon's Lex.

  • Apache's Cassandra database is a powerful, scalable Big Data solution for storing and processing large amounts of data, often using hundreds of nodes split over multiple worldwide locations. It's a great tool and we like it, but too often we see teams run into trouble using it. We recommend using Cassandra carefully. Teams often misunderstand the use case for Cassandra, attempting to use it as a general-purpose data store when in fact it is optimized for fast reads on large data sets based on predefined keys or indexes. Its dependence on the storage schema can also make it difficult to evolve over time. Cassandra also has significant operational complexity and some rough edges, so unless you absolutely need the scaling it provides, a simpler solution is usually better. If you don't need Cassandra's specific use-case and scaling characteristics, you might just be choosing it out of Big Data envy. Careful use of Cassandra will include extensive automated testing, and we're happy to recommend CassandraUnit as part of your testing strategy.

  • Image comprehension used to be a dark art and required a team of onsite data scientists. In recent years, however, we've come closer to solving problems such as image and facial classification/categorization, facial comparisons, facial landmark identification, and facial recognition. Cloud-based image comprehension provides access to machine-learning capabilities through services such as Amazon Rekognition, Microsoft Computer Vision API and Google Cloud Vision API which can supplement AR applications and anything involving photo tagging and classification.

  • We've had some early successes with DataStax Enterprise Graph (DSE Graph) for handling large graph databases. Built on top of Cassandra, DSE Graph targets the type of large data sets where our longtime favorite Neo4j begins to show some limitations. This scale has its trade-offs; for example, you lose the ACID transactions and run-time schema-free nature of Neo4j, but access to the underlying Cassandra tables, the integration of Spark for analytical workloads, and the powerful TinkerPop/Gremlin query language make this an option worth considering.

  • Electron is a solid framework for building native desktop clients using web technologies such as HTML, CSS and JavaScript. Teams can leverage their web know-how to deliver polished cross-platform desktop clients without spending time learning another set of technologies.

  • The hype seems to have peaked for blockchains and cryptocurrencies, as evidenced by the slowdown of previous firehose-scale announcements in this area, and we expect some of the more speculative efforts to die out over time. One of the blockchains, Ethereum, while not universally popular among diehard blockchain aficionados, appears in increasing numbers in new initiatives. Ethereum is a public blockchain with a built-in programming language allowing developers to build "smart contracts", which are algorithmic movements of ether (the Ethereum cryptocurrency) in response to activity happening on the blockchain. R3CEV, the consortium building blockchain tech for banks, built its first proofs of concept on Ethereum. Ethereum has been used to build a distributed autonomous organization (DAO)—one of the first "algorithmic corporations"—although a recent heist of $150 million in the ether demonstrates that the blockchains and cryptocurrencies are still the Wild West of the technology world.

  • Hyperledger is a platform built around blockchain technologies. It consists of a blockchain implementation named Fabric and other associated tools. Disregarding the hype surrounding blockchain, our teams have found it easy to get started with these tools. The fact that it is an open source platform supported by the Linux Foundation also adds to our excitement about Hyperledger.

  • IndiaStack is a set of Open APIs designed with the goal of transforming India from a data-poor to a data-rich country. The stack emphasizes layered innovation by specifying a minimal set of APIs and encourages the rest of the ecosystem to build custom applications on top of these APIs. Aadhaar serves as one of the foundation layers, providing authentication services for more than a billion Indian citizens. In addition, there are services to provide paperless transactions through digital signatures (eSign), unified online payment (UPI) and an electronic consent layer (e-KYC) to securely provide Aadhaar details to service providers. We believe in the Open API–driven initiative to bring digital innovation, and the design principles behind IndiaStack could be used as a change agent for other regions/countries.

  • Kafka Streams is a lightweight library for building streaming applications. It's been designed with the goal of simplifying stream processing enough to make it easily accessible as a mainstream application programming model for asynchronous services. It can be a good alternative in scenarios where you want to apply a stream processing model to your problem without embracing the complexity of running a cluster (usually introduced by full-fledged stream processing frameworks).

  • In a microservices or any other distributed architecture, one of the most common needs is to secure the services or APIs through authentication and authorization features. This is where Keycloak comes in. Keycloak is an open source identity and access management solution that makes it easy to secure applications or microservices with little to no code. Out of the box, it supports single sign-on, social login, and standard protocols such as OpenID Connect, OAuth2 and SAML.

  • Mesosphere DCOS is a platform built on top of Mesos that abstracts away your underlying infrastructure for containerized applications as well as for applications you don't want to run inside Docker. This may be overkill for more modest deployments, but we're beginning to see successes with both the commercial and open source versions. We particularly like that it facilitates portability between different cloud providers as well as dedicated hardware, and that for containerized workloads you're not tied into one container orchestration framework. Although upgrades can be a little more complex than we would like, the overall stack is stabilizing nicely.

  • In our experience—for Internet of Things (IoT) solutions where a lot of devices communicate with each other and/or a central data hub—the MQTT connectivity protocol has proven itself. We've also come to like the Mosquitto MQTT broker. It might not satisfy all demands, particularly with regard to scalability, but its compact nature and easy setup makes it ideal for development and testing purposes.

  • Nuance Mix is a framework for natural language processing from the company that created the speech-to-text technology behind Dragon Speaking and the first roll-out of Siri. This framework supports the creation of grammars that allow for free-form user interaction via voice. The developer defines a domain-specific grammar that the framework can train itself to understand. The outcomes are responses to user input that identify the user's intents and interaction concepts. At first, it is limited to phrases close to the ones used to train it, but over time it can start to identify meaning from more divergent phrasing. Though it is still in beta, the accuracy from early exploration has been compelling, and the eventual product is one to watch for application forms that could benefit from hands-free user interaction—including mobile, IoT, AR, VR and interactive spaces.

  • OpenVR is the underlying SDK in making many of the VR head-mounted displays (HMDs) work with Unity and will likely keep growing in importance. Much of the VR work at ThoughtWorks was built on top of OpenVR, because it will run on any HMD, unlike the other SDKs. Though it is not open source, it is free via the license. The Oculus SDK is more restrictive in its licensing and only works on Oculus devices. OSVR, while truly open source, doesn't seem to have as much adoption yet. If you're going to develop a VR application and target as many devices as possible—and not use Unity or Unreal to develop them—OpenVR is the most concrete and pragmatic solution right now.

  • PlatformIO provides a rich ecosystem for IoT development by providing cross-platform builds, library management and good integration with existing IDEs. The intelligent code completion and Smart Code Linter with built-in terminal and serial port monitor greatly enhances the developer experience. It also organizes and maintains thousands of libraries and provides a clean dependency manager with semantic versioning to ease IoT development. We've started using PlatformIO in a few IoT projects and we really like it for its simplicity and wide support of platforms and boards.

  • Alongside virtual reality (VR), which has a relatively high bar to entry due to hardware requirements and the effort to create virtual worlds, alternate reality (AR) and mixed reality (MR) also entered into the mainstream last year. Pokémon Go provided evidence that regular smartphones are sufficient to create compelling AR/MR experiences. Tango is a new hardware sensor technology for mobile phones that further enhances the possibilities for AR/MR on phones. It allows apps to acquire detailed 3-D measurements of the user's surroundings so that virtual objects can be placed and rendered more convincingly on the camera feed. The first phones with Tango technology are now available.

  • Voice platforms such as Amazon Alexa and Google Home are riding high on the hype cycle; some even herald the ubiquity of the conversational voice interface. We're already integrating conversational UIs into products and seeing the impact of this new interaction in how we design interfaces. Alexa specifically was built from the ground up without a screen and treats the conversational UI as first-class. But it's still too early to believe the hype, and we expect more big players to get in the game.

  • WebVR is an experimental JavaScript API that enables you to access VR devices through your browser. It has garnered support from the community and is available through nightly builds as well as in some release versions. If you are looking to build VR experiences in your browser, then this is a great place to start. This technology alongside complementary tools such Three.js, A-Frame, ReactVR, Argon.js and Awe.js brings AR experiences to the browser. The flurry of tools in this space, alongside Internet commission standards, could help promote stronger adoption of AR and VR.

  • Hype surrounding machine intelligence has reached a crescendo, but as with Big Data, useful frameworks and tools are waiting to be discovered among all the hot air. One such tool is, a SaaS platform that allows developers to create conversational interfaces using natural language processing (NLP). Wit works with either text or speech inputs, helps developers manage conversational intent and allows custom business logic to be implemented using JavaScript. The system is free for commercial and noncommercial use and encourages the creation of open applications. Be aware that you must agree to let Wit use your data in order to improve the service and for its own analysis, so read the terms and conditions carefully. Another contender in this space is the Microsoft Bot Framework, but it's available only in limited preview form as of this writing. As with most things Microsoft, we expect the Bot Framework to evolve quickly, so it's worth keeping an eye on.


  • We are seeing too many organizations run into trouble as they attempt to use their CMS as a platform for delivering large and complex digital applications. This is often driven by the vendor-fueled hope of bypassing unresponsive IT organizations and enabling the business to drag and drop changes directly to production. While we are very supportive of providing content producers with the right tools and workflows, for applications with complex business logic we tend to recommend treating your CMS as a component of your platform (often in a hybrid or headless mode) cooperating cleanly with other services, rather than attempting to implement all of your functionality in the CMS itself.

  • One of our regular complaints is about business smarts implemented in middleware, resulting in transport software with ambitions to run critical application logic. Vendors in the highly competitive API gateway market continue to add features that differentiate their products. This results in overambitious API gateway products whose functionality—on top of what is essentially a reverse proxy—encourages designs that are difficult to test and deploy. API gateways can provide utility in dealing with some generic concerns—for example, authentication and rate-limiting—but any domain smarts such as data transformation or rule processing should live in applications or services where they can be controlled by product teams working closely with the domains they support.

Unable to find something you expected to see? Your item may have been on a previous radar

Learn more about our approach to assessing technology & build your own radar Get StartedNo thanks