Taxdoo Tech Radar Goes Public

We’re happy to announce that the Tech Radar we have been using internally is now publicly accessible! It can be found here.

So what is a Tech Radar? The concept was first popularised by the software consultancy Thoughtworks as a means to share knowledge between their teams working over a wide range of companies and projects. It quickly turned into an industry standard, with many engineers each quarter checking out what new technologies would be recommended or which no longer should be used.

Inside Taxdoo Engineering, we use our tech radar mainly as a tool of discussion and alignment. Any engineer can suggest an update, which naturally leads to discussions on what the collective wisdom is. We see it as important that any engineer can suggest changes, not just certain roles or titles, but of course our architect and lead engineer review the radar periodically to make sure it’s aligned with Taxdoo’s long term strategy as well.

The visualisation that can be seen on our website is based on the open source Zalando Tech Radar Github project with some minor additions to also be able to show our reasoning behind each decision. While we tried to add meaningful descriptions to each point, here are a few high-level trends we have been noticing:

AWS Serverless at Taxdoo

Taxdoo has always been heavily relying on AWS Serverless, in particular API Gateway + Lambda, and that’s a trend we foresee to continue. When we talk to people outside of Taxdoo, we are often met with two questions: Isn’t that quite expensive and why are you not using Kubernetes?

The simple answer is: because AWS Serverless just works for us! Of course, for a lot of the number crunching and heavy lifting we do use Docker + ECS, but the main parts of our applications our users are interacting with are almost completely serverless. This greatly simplifies our infrastructure and makes topics such as security or compliance much easier to handle. As an example, a recent recurring audit performed by one of our external data suppliers went much smoother because we have so few servers in our production environment. Less servers, less security updates and firewall settings to worry about.

Serverless also fits perfectly to the usage patterns our customers have. They need 100% reliability, but we do not see high loads over long stretches of time. Matching our motto “Taxdoo and done”, users jump into the application, are able to quickly perform their tasks, and then jump out again. Due to the nature of our business, we also see usage peaks around monthly filing deadlines as prescribed by the various countries’ tax authorities and a lower usage during the other days of the month, because things simply work. As a result, AWS Lambda + API Gateway is an almost negligible amount of our operational cost, especially comparing it to the storage cost of the large amounts of data we are processing every single month.

Speaking about Kubernetes, it is a great tool. However, we have so far not come across any use case that would warrant the additional complexity over basic API Gateway + Lambda. We are not only avoiding additional costs of operation and training required to properly use Kubernetes but are also completely avoiding a whole class of Kubernetes-specific issues. So while we are often met with a lot of enthusiasm for Kubernetes (for example while talking with potential recruiting candidates), for our use cases, it simply doesn’t add any value.

Increased Usage of Docker for Local Development & Testing Setups

We had been using docker as part of integration tests for a number of years, but often only to simulate individual parts like our product database. We have now reached a tipping point where so many of our services are also available in dockerized form that more and more projects start to build more complex e2e/integration test setups that can be run isolated for each MR or locally. Once a project is at this point, it is easy for it itself to offer a docker image, thus continuing to spread our coverage. We just recently reached the important milestones of being able to run our main user-facing application completely inside docker with only a few dependencies being mocked.

There are of course areas where a docker approach runs into issues. We have faced this in particular when using more AWS-specific features such as AWS AppSync or AWS Step Functions. In the case of App Sync, we had put it on hold for other reasons already and we use Step Functions mainly in our non-user facing parts of the application where we can use different testing approaches. Still, it is important for us to be conscious in which areas Docker will be able to help us and in which an overreliance on it might severely limit us.

AWS Step Functions & Consolidation

Speaking of AWS Step Functions: so far, we have had very good experiences using Step Functions in some of our production workflows and am excited to use it more whenever the matching use cases arise.

In a lot of other areas though, we see a trend of consolidation and simplification rather than one of adding new tools to our belt. We are for example actively pursuing removing the last remnants of our PHP code, not because modern PHP isn’t capable of doing what we need, but because removing it further simplifies our setup. Having one less language involved will make it easier to onboard new engineers to the project, especially for those of our teams that usually don’t work as much with UI and just want something where they can quickly jump in, add a few changes, and get back to their core tasks.

In a similar vein, AWS App Sync turned out to be enticing at first but not worth the added complexity of an additional AWS service in the long run for us. To fulfil our real world use cases, we had to add some custom code and we also ran into issues that were hard to diagnose. We had only used it in the limited context of a single micro service though and thus moving that functionality to our more traditional API approach will be possible during the next iteration of that part of our application.

Taxdoo Engineering

Article Navigation