cloudweed
Published in

cloudweed

Technology Radar May 2018 review — Part 2

Every six months or so, ThoughtWorks publishes Technology Radar, which provides the Software Engineering community, a very good glimpse of what technologies, techniques, patterns, tools, languages, frameworks are recommended for Adopt, Trial, Assess and Hold in four quadrants.

These are, however, only guidelines as they stand, based on the research performed by ThoughtWorks. Needless to say, these recommendations doesn’t suit every one / organisations depending upon your needs. What you are encouraged to do though, is to create your own Technology Radar; see thoughtworks.com for more details.

Photo by Bernard Hermant on Unsplash

This article, which is the second part of the Technology Radar review, gives you my perspective of the Tools that I identified as ready to be adopted and fit into the current architectural/system design needs of many organisations; no matter the size/team.

I intend to do this in multiple parts, due to the risk of reader’s bewilderment. See below links for the other parts in this review series.

Part 1: Introduction to Technology Radar & Techniques review

Photo by Lachlan Donald on Unsplash

Tools

Interactive radar: https://www.thoughtworks.com/radar/tools

TRIAL: Appium

Testing automation frameworks are key to any software product that is being offered in any hand held devices and now, more than ever this modern way of reaching out to the Customers have increased in the value proposition. At the same time, the delivery of feature sets needs to be fast hence testing those features are crucial.

Automation for Apps; one of the most popular mobile test automation frameworks — it is an open source test automation framework for use with native, hybrid and mobile web apps.

Features include:

  • Supports Native and hybrid mobile apps
  • Mobile tests using any language or framework
  • Open source
  • Facilitates mobile continuous integration
  • Mobile test automation tool
  • Cross-platform (iOS, Android)
  • Framework based on Selenium

Sample code:

TRIAL: Kong API Gateway

Simply put, an API gateway is the single entry point for all clients. The API gateway handles requests in one of two ways. Some requests are simply proxied/routed to the appropriate service. It handles other requests by fanning out to multiple services. Rather than provide a one-size-fits-all style API, the API gateway can expose a different API for each client. For example, the Netflix API gateway runs client-specific adapter code that provides each client with an API that’s best suited to its requirements — if you are watching any streaming content either on Laptop or Mobile or Tablet, the API gateway routes your request accordingly to give you the best / optimized experience. Most of the times, the API gateway might also implement security, e.g. verify that the client is authorized to perform the request.

Kong is a scalable, open source API Layer (also known as an API Gateway, or API Middleware). Kong runs in front of any RESTful API and is extended through Plugins, which provide extra functionality and services beyond the core platform. Kong was originally built at Mashape to secure, manage and extend over 15,000 APIs & Microservices for its API Marketplace, which generates billions of requests per month for over 200,000 developers. Today Kong is used in mission critical deployments at small and large organizations.

Kong is built on top of reliable technologies like NGINX and Apache Cassandra or PostgreSQL, and provides you with an easy-to-use RESTful API to operate and configure the system.

Request Workflow

Once Kong is running, every request being made to the API will hit Kong first, and then it will be proxied to the final API. In between requests and responses Kong will execute any plugin that you decided to install, empowering your APIs. Kong effectively becomes the entry point for every API request.

Find out how Kong works:

Netflix API Gateway example:

Read more about the API Gateway pattern, here:

TRIAL: Helm

With so many frameworks being created every day and floating around us with subtle capabilities which could be a differentiator, the packages have to be maintained to manage the dependencies, which is the sole function of a Package Manager.

Helm is a package manager for Kubernetes, an open-source container-orchestration system for automating deployment, scaling and management of containerized applications.

Find out more about Helm charts, here:

ASSESS: Parcel

Parcel is a web application bundler similar to Webpack or Browserify. It is a fast, zero configuration web application bundler.

How does it work : Parcel transforms a tree of assets to a tree of bundles. Many other bundlers are fundamentally based around JavaScript assets, with other formats tacked on — e.g. inlined as strings into JS files. Parcel is file-type agnostic — it will work with any type of assets the way you’d expect, with no configuration. There are three steps to Parcel’s bundling process.

Parcel Benchmark

ASSESS: Swashbuckle for .NET Core

In many ways, this is a no brainer. Swashbuckle creates API documentation in Swagger. Swagger is a set of open-source tools built around the OpenAPI Specification that can help you design, build, document and consume REST APIs. It enables teams to automatically generate documentation for RESTful APIs including the option to try/test out.

Swagger is a standard way to describe a RESTful API so that human-readable documentation and client examples can be generated automatically. The update to version 2.0 provides some significant flexibility enhancements and the list of tools for generating documentation continues to expand. There are also several alternatives to Swagger emerging from the vendor community, most significantly RAML and API Blueprint.

Take a look at the example here: http://petstore.swagger.io/

More info, here:

Create Your Radar

You can create your own technology radar and see where the blips are compared to the ones published by Thoughtworks. It is important for you to understand the differentiator and what makes sense for you and why. There is also constant review needed in order adjust your radar when there is a need for a new framework or techniques that your team want to adopt and they have a credible reason / business case for it. Also, be mindful that you’d also need to create some artefacts including a light weight Proof of concept to ensure that you are not leaving it too far to figure out any major constraints with the items from our Radar and perform durable Market scan(s).

Part 1: Introduction to Technology Radar & Techniques

Have you created and used your own Technology Radar for your project / organisation? It’d be great to hear you feedback and experience (comments welcome)!

--

--

--

Technology News, Software how-to, Architecture guidance

Recommended from Medium

GOING SERVERLESS WITH AWS LAMBDA

Creating a Simple Reversal Trading Strategy in Python.

Staking Update: Week 50! April 19, 2021 🚀

Personal Passion Project

Basic setup

Macroservices vs. Microservices vs. Serverless: the story of a modern solution architect

Top features of Pandas 1.0

Designing the Data Locality System

Terraform on GoogleCloud — impersonating with short-lived AccessTokens & ServiceAccounts

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Karthick Thoppe

Karthick Thoppe

Technology thinker, Realistic Modern Enterprise Software Architect, Avid Jogger/Runner, Software Elixir maker

More from Medium

Applying test-driven development to your database

Automating Planetscale Deploy Requests into our CI/CD

Managing Data in Containers

Ballerina Collections: Tables