Tradeshift Engineering Intro Part 3— Stack, Architecture and Engineering Processes
This is part 3 of the Tradeshift Engineering Intro Series.
When you operate at certain scale, having deep understanding of your stack becomes crucial (and difficult). We limit the number of runtimes we support, mostly to the JVM and Node.js.
Drafts of this post features a list of technologies we use, with some light commentary. I decided instead to turn it into a mind map, I think it’s more interesting to view. Enjoy! The nodes that are emphasized in blue are the technologies we rely on the most.
I’d like to highlight some of the choices and why they make sense for us. There are two main parts of our stack — backend RESTful services, written mostly in Java, and the user-facing stack — single page apps written in Angular.js which have their own server-side component in node.js. The node.js layer interacts with the backend services. The latter allows our front-end developers to be fully in charge of user experience. When our users interact with the platform, they seamlessly navigate from one application to another.
On persistence side, we are heavy users of PostgreSQL (aggressively upgrading to the goodies in 9.5!), and use ElasticSearch whenever we need search. A big part of what we do is sending business documents, such as invoices, purchase orders, goods receipts (in UBL standard) around, we use Riak as our document store. Riak has worked great for us. We also have Redis and Cassandra in a few specific places.
Architecture, Process and Techniques
I also wanted to highlight some of the architecture and process we use. Here is a second mind map showing those:
There are several things we do to help us deliver software faster. As I mentioned on a previous post, we use service-oriented architecture to separate our stack into manageable parts. The services expose APIs that are consumed by our front end application, and many APIs are also available to third-party developers. I mentioned above that we write our UIs as a series of small applications, which makes it easier to work on in small teams and iterate quickly.
Our architecture and a lot of the things we do are architected to support third-party developer ecosystem, and we use the same tools internally. For example, for both our own purposes and to ensure UI consistency with third-party apps, we have a UI component toolkit, along with design guidelines to guide the development.
We have a good culture of automated testing, done on several levels — unit testing, integration and end to end testing. Like many shops, we are not quite at a point where we have a Test Pyramid, but trying to get there. If Testing = Checking + Exploring, automated tests are good at the checking, but we also have dedicated QA professionals for exploratory testing.
We have some interesting experiments with event-driven architectures for some newer services, and are doing a lot of work on making our platform work in multiple data centers, which is a challenging problem. Our tenant isolation model was built from the ground up to support that use case by keeping all companies on our network separate from each other.
In terms of process, we are an Agile shop, with most teams using scrum, but some operating more in a scrumban mode. We also have a strong code review process based on github’s pull requests, including making sure there is good unit test coverage.
We also have a lot of interesting things happening on the operations side, that will be a separate post.
In case you are wondering if we are hiring, yes we are.