We’ve been trying to use the technology radar concept as a way to document both what technologies we have in use as well as our current thinking on direction. It’s viewed as documentation and not speculation, so our tech radar should never have stuff in it that’s not actually in production.
We’ve recently updated it and I thought it would be interesting to highlight some of the changes.
Pact & Consumer-driven Contracts
We’ve seen wider adoption of PACT and Consumer-driven contracts across our teams as the way to test service consumption. Nicola, one of our engineers, wrote a blog post a while back outlining what it is and why it’s good, and most of our teams are now using this technique.
We’ve completely eliminated the “stand up the entire world to run tests” mechanism. We do have some use of VCR to test internal services, but this is not the way forward, since it still requires the ability to actually consume services during tests, in order to refresh the cassettes.
This isn’t to say VCR isn’t useful—we use it for testing external services.
The general pattern we’ve settled on is to always have a service wrapper that provides a use-case-specific API over top of a thin API client, which just does HTTP and object serialization. Application code is tested by mocking the service wrapper. For internal services, the service wrapper is tested with PACTs (which are then executed by the consumed service during its build). For external services, the service wrapper is tested with VCR.
Infrastructure & AWS
We’re getting more serious about running our applications in AWS, and have been using Docker as the means to do that. Our current experiments around deployment are using Docker images deployed to Amazon’s EC2 Container Service (ECS). This means we can use AWS’s Elasticache for Redis (and also connect to S3 without per-app access keys).
So far, the results are encouraging. We’ve been managing some infrastructure with Terraform, and others with our internal deployment pipeline. Terraform has been a great tool to transparently and cleanly manage cross-cutting infrastructure.
Churn in Issue and Task Management
Our teams are continuing to diverge on issue and task management. I don’t personally see this as a bad thing, as we don’t tend to be managed in the top-down fashion a single tool would foster, but we are looking at more complex systems than spreadsheets.
Our Platform and Styling teams are looking into the oft-maligned JIRA and having some success. Our Warehouse team is having a lot of success with Asana, and our Merchandising team is still plugging away with waffle.io and GitHub issues. GitHub Projects hasn’t turned out to be very useful, but maybe it will be in the future. Our Consumer team is continuing to get value out of Pivotal Tracker.
Application Performance Monitoring
Another fun topic is Application Performance Monitoring aka APM. NewRelic is the gold standard here, but it’s incredibly expensive and has a billing model that makes it hard to plan for with both ECS and Heroku. But it’s a damn good tool.
We’ve been using Skylight for some applications, but it’s not as insightful as NewRelic, and has had hiccups in compatibility with Linux.
Both Datadog and Librato have up-and-coming products, but these have yet to be vetted or deeply examined. We’re looking into Datadog now. APM is super important for understanding our applications and, to be honest, it’s New Relic’s game to lose. Their product is really great, which is probably why they can charge so much for it :)
The Ever-changing Front-end
Angular 1 is pretty much at end-of-life, though we have a fair bit of code using it in our Warehouse software. We don’t expect to start any new project using it and since Angular 2 is a totally new framework, this puts us in the position of re-evaluating what makes the most sense for us. React is the most talked-about replacement, but there is interest in Angular 2 as well. We have very little of either in production.
We’ve also been trying to get away from Bootstrap and our home-grown HumbleKit, in favor of a more ambitious internal CSS framework called Weave. We haven’t rolled it out widely, but new applications are encouraged to look into it. Not sure if we’ll open source it or not, but it should do what all CSS frameworks do—keep designers from re-building the same front-end components over and over again and empower developers to do the right thing.
Where to Go From Here
I’d like to update our radar quarterly instead of “when I realize it’s way out of date”, so hopefully I can revisit where we are in a few months and check in. With the impending release of rails 5.1, which uses Webpack, it’ll be interesting to see how the front-end pans out, as we have some upcoming projects that will need some level of JavaScript beyond jQuery.
