For some engineers, the tools they’ll get to use on a project can be just as exciting as the end product itself. When picking out languages, frameworks and technologies, tech teams must be careful to balance a project’s needs, the capabilities of its engineers and the support ecosystem around those technologies. At the same time, many engineers love using challenging projects as an opportunity to learn new skills.
Here, we talked to engineering leaders at four Seattle tech companies to learn what their tech stack currently looks like, and how they choose from (or add to) their arsenal when approaching new projects.
When businesses solicit feedback from customers, they walk a fine line between being overbearing, which can turn users off, or too standoffish, which doesn’t get them the information they need. Apptentive’s customer feedback software integrates with existing apps to gather data on ratings, notes, chat box conversations and surveys, then applies machine learning and semantic analysis to identify broader trends.
Tech Ops Manager Andre Rojas said the startup is headed down a decidedly cloud-native path for its core infrastructure.
What does your tech stack look like? What are your favorite aspects of it?
My favorite aspect of working at Apptentive is the wide scope of technologies that we use. The core stack could be summarized as NodeJS and React for the front end, and a mix of Ruby on Rails and Scala for our back end. If you dig in though, you’ll find that we also depend heavily on tools and services we’ve written in Python, Golang and whatever else our team has determined is the best tool for the job. The data layer is similarly wide-ranging. We deploy, maintain, and make use of MongoDB, Cassandra, PostgreSQL, Redis, Elasticsearch and Kafka clusters.
Our infrastructure is hosted entirely in the cloud, with workloads hosted in our self-managed Kubernetes clusters and directly on AWS EC2 instances. Moving forward, we’re committed to defining our infrastructure as code with tools such as Terraform and Helm. This has led us down a more cloud-native path of immutable infrastructure, and we have shifted to using Ansible to account for the gaps in automation that aren’t already covered by our other tooling.
It always ends up being a balance between leveraging the technology we know and adopting the best-of-breed tool at the time we tackle the problem.”
How do you choose what tech to use to complete a project?
There is no simple answer to this one, as it always ends up being a balance between leveraging the technology we know and adopting the best-of-breed tool at the time we tackle the problem. With some of the newer projects that we’ve been working on, we have had the opportunity to lean forward a bit more.
This has allowed us to build with an eye toward what we feel is the future of our tech stack. It’s also served as a great proving ground for figuring out what combination of tools and implementation patterns work best, so we can then bring those lessons back to our core services and infrastructure.
OpenMarket takes the work out of text-based marketing campaigns through automation. The Seattle company’s APIs integrate RCS, MMS and SMS campaigns, while its drag-and-drop software allows users to build campaigns without the need for writing a single line of code. OpenMarket’s technology has a wide range of applications, including soliciting customer feedback and integrating with IoT devices to send alerts if devices detect system problems.
Senior Software Development Manager Lita Monaghan said her team tends to focus on microservice architecture.
What does your tech stack look like? What are some of your favorite facets of it?
OpenMarket's tech stack is whatever is best to get the job done, but we use Java and Spring at the core of everything. For example, our services can use SQL or NoSQL solutions and can be deployed to on-premises or cloud technologies environments — whichever solution is best-suited for a given scenario.
Our approach is simplicity, scalability and maintainability, and we achieve this with the flexibility of being technology agnostic.”
How do you choose what tech to use to complete a project?
As engineers, we prefer breaking down our complex business requirements into small, manageable modules and as such, have a strong focus on microservice architecture. We are an international organization that processes billions of messages a month for some of the world’s top brands, making high availability key to our success. Our approach is simplicity, scalability and maintainability, and we achieve this with the flexibility of being technology agnostic.
Postmates’ “Urban Logistics” platform connects users with its network of couriers, ready and willing to deliver meals and goods from a huge array of stores and restaurants throughout 20 cities across the country. The San Francisco-based company is also working on a delivery robot called “Serve”, which uses Lidar and an advanced array of sensors to help it safely navigate city sidewalks.
Director of Engineering Aabhas Sharma enjoys his team’s utilization and contribution to a variety of open source projects.
What does your tech stack look like? What are some of your favorite facets of it?
Our tech stack is developed primarily in Python, Go and Erlang, and deployed on Kubernetes. We utilize Prometheus, OpenCensus and Grafana for monitoring and request tracing. My favorite facets of the tech stack are: self-service tools for deploying new services and resources via code; end-to-end introspection and request tracing with span propagation; utilization of several open source projects (Vault, Kubernetes, Drone and Prometheus, to name a few) as well as a lot of open source contributions when the projects don’t fit our needs.
We also make an effort to give back to the community by contributing upstream or open-sourcing in-house frameworks as much as possible.”
How do you choose what tech to use to complete a project?
Postmates has always chosen to use the technology that works best for a project or problem at hand, while making sure that we don’t introduce too many new languages or technologies that require a specialized team to maintain. We always try using open source libraries and frameworks to solve our problems first, and we only implement them in-house if they don’t meet the requirements or exist at all. We also make an effort to give back to the community by contributing upstream or open-sourcing in-house frameworks as much as possible.
Quantcast helps publishers and website owners figure out who their audience is and how to win their attention by measuring the behavior of users as they move through the internet. The San Francisco-based company applies machine learning technology to offer what it calls a “real-time pulse” on users and the wider web, and works on more than 100 million apps and websites.
Head of Engineering for Quantcast’s Seattle office Durban Frazer loves the speed with which his company’s tech stack allows his team to ingest and act on web traffic data.
What does your tech stack look like? What are some of your favorite facets of it?
Our customers need fast, interactive queries across some 1 billion entities over 100,000 attributes, and we need to modify how those attributes are combined and compare them against all other attributes. For this problem, the best solution was to build our own distributed query engine in Golang.
Another example is our real-time bidding stack, for which we’ve built a fleet of bidders across multiple data centers using a variety of technologies that could power over 100 billion daily queries per second in less than 100 milliseconds per request. We’ve also found some problems that can be addressed by judiciously using existing technologies like Apache Druid for reporting on large numbers of events and giving users the ability to ask fine-grained questions about these events interactively. My favorite part is the power that these systems provide, being able to very quickly analyze and act on massive amounts of data and traffic.
When looking at external systems, we also consider the ecosystem around it.”
How do you choose what tech to use to complete a project?
We consider several different aspects such as: what are the key requirements of the system we’re building; what solutions already exist; what would we need to do to use them for our purpose; and is our team already familiar with parts of the new tech.
Based on these and other factors, we might decide that we need to build a platform from scratch to meet low latency or volume requests. Or we might decide that an existing software package can be used to meet most of our needs and we will figure out how to make it meet the final needs.
When looking at external systems, we also consider the ecosystem around it: who else is using these systems and why? If other people are using it for a similar purpose then likely there will be a community that we can join and we will be able to leverage ongoing work.
