Built in Boston Startup Tech Stacks

Spring Boot – We field a number of microservices on top of Spring Boot. Its convention-over-configuration design allows us to focus on business logic rather than plumbing. We’re particularly looking forward to the Spring team’s upcoming first-class support for Kotlin, which we’ve been gradually introducing as a safe, expressive alternative to Java 8.

React + Redux – We’ve built a highly interactive and engaging front-end using React and Redux. The resulting code is modular, easy to reason about, flexible, and composable.

Kafka – We use Kafka as our primary message bus. Unlike most “big data” technologies, Kafka has allowed us to scale without imposing a notable increase in complexity. In fact, becuase its append-only architecture allows us to view topic contents long after the message has been “consumed”, Kafka allows us to significantly improve monitoring and visibility over more traditional message buses (JMS, AMQP). We’re looking forward to experimenting with Kafka Streams as a lightweight alternative to standalone stream processing frameworks such as Spark.

Zeppelin – We use Apache Zeppelin to query, aggregate, and visualize data across a number of heterogeneous data sources, including MySQL, ElasticSearch, and S3. We write ‘notebooks’ in Scala and SQL to drive Spark in creating these visualizations. These notebooks can be ad hoc or shared, versioned, and parameterized.

NiFi – We use NiFi as an orchestration layer to manage real-time data flows in a simple scaleable way. The framework provides us with the ability to easily monitor the progress of messages as they move through the processing pipeline and to replay messages should it be necessary.

Ruby / Rails – We use Ruby and Rails for our web facing applications, as well as the API underlying the platform. The entire platform is deployed to Amazon AWS. We haven’t made the jump to Rails 5 yet for existing applications, but it’s on the radar.

AWS – The entire drizly platform is built on AWS. We use a variety of different services, including SNS, Redshift and Lambda, which are used heavily in our data pipeline.

React – Where possible new frontend development is done in React. We have some SPA style projects built in React, as well as a significant number of components on our e-commerce site utilizing react.

Mysql/Postgres/Redshift – Depending on the application we use a slightly different data-store. We like to be flexible, and find the right solution for the problem at hand.

SQS – We utilize SQS heavily as a background job processing system. We’ve found it to be stable, and durable, and performant enough for our use cases.

Keen.io – Keen.io plays an essential role for us in user and application analytics. Our user facing and internal application event tracking dashboards are built on top of keen events. We utilize both client-side and Node.js libraries for event tracking and management.

Firebase/AngularFire – Firebase and AngularFire are used in the front end to create a dynamic, real-time user-interface, and to support user authentication.

Gitlab – We use a self-hosted gitlab instance running on Ubuntu for source code control and release management.

Node.js/Express – Node.js and Express are used for a variety of background services including job running and our REST API.

Amazon Web Services – We rely on AWS extensively. We use EC2 for computing, EBS for storage, RDS for relational databases, ElastiCache for caching, and we’ve also experimented with Kinesis, Lambda and ElastiSearch. In the past, we used other hosting providers that were less expensive, but as we’re scaling, AWS has been able to scale extremely effectively.

Codeship.io – We use Codeship to run integration tests at every commit. This lets us push hotfixes quickly, especially for UI changes, and lets us run experiments quickly.

FullStory – We use FullStory extensively to look at customers’ use of MarketMuse. It’s also great for debugging – when a customer reports an issue, we can replicate it in FullStory. Our Customer Success team also uses it, especially with new customers, to see how well they’re using the software and where there may be gaps in their understanding.

Scala with Play Framework – We use python for prototyping and in areas where we need to move flexibly. But for heavy lifting, we use Scala. It runs on the JVM, so it natively supports all Java libraries (of which there are many in Natural Language Processing). We use Akka and its “actors” extensively to take full advantage of CPU and network/IO resources.

Ruby on Rails – We use Ruby on Rails because of its maturity and large ecosystem. On the front-end we use jQuery and Bootstrap, and on the backend we use ActiveRecord and Sequel to access Postgres databases.

Sidekiq and Redis – for distributed job processing capabilities.

RSpec – While not dogmatic about test-first development in all cases, we are passionate about writing and maintaining thoughtful and robust test coverage in RSpec.

Heroku and AWS – Heroku hosts our applications, managed databases, and various services such as centralized logging and distributed batch job processing. Amazon Web Services (AWS) provides file storage and simple messaging capabilities.

Bamboo – We implement continuous integration and delivery (CI / CD) via Atlassian Bamboo, deploying to production environments multiple times per day.

React and Redux – The skeleton and nervous system of our in-browser code. The combination of one-way data binding and functional state transitions has made our products much easier to build (and, more importantly, debug).

Elixir – Our persistent services are written in Elixir, a relatively young functional language built on the Erlang VM. It’s got lots of features to recommend it — immutability, actor-based concurrency with crash supervision, hot upgrades and rollbacks, built-in clustering, etc — but the syntax is also downright comfy and very productive. Elixir’s been great to us in the last year we’ve had it in production.

AWS Lambda and Serverless Framework – Lambdas are an amazingly cost-efficient way to implement services or event handlers that don’t require low latency or long execution times. We’ve recently begun to move our dozen-or-so Lambdas into the Serverless Framework, which automates their deployment and configuration. And the ease of working with Serverless Framework makes it likely that we’ll build a bunch more features with it.

DynamoDB – While we use a combination of data persistence layers (Postgres, Firebase, and S3 also play a part), we began to experience growing pains with our most frequently-updated data. We moved this workload from Postgres to DynamoDB last fall, and we’ve not only seen a 30-40% reduction in operating cost, but our response time is much more predictable, and our peak-traffic performance is between three and twenty times better.

Redis – We’re using Redis as the basis of a stats collection system. In particular, its implementation of the HyperLogLog cardinality estimation algorithm means that we can keep as many unique counters (e.g., daily active users for each customer) as we like without worrying much about disk space or CPU time.

React/Redux – We use React for all new development, in combination with Redux for state management, and are actively converting existing features to it. The simplicity of React is more in parity with our Go back-end, and removes many of the frustrations our team has encountered with other technologies. We leverage Reselect for performance and composability, and find Enzyme to be a great testing utility.

AWS – The clypd platform runs entirely on AWS. We leverage VPCs to provide network isolation, EC2 to run our code and provide load balancing, S3 for backups, RDS to host databases, SQS for job queuing, and Redshift for heavy duty analytics. We have been thoughtful in how we set up security groups and instance profiles to follow a least-privilege model for both admins performing maintenance and our apps. We define the state of our infrastructure in Terraform, which allows for code review and dry-runs of infrastructure changes, along with maintaining history in git.

Go – Our team loves using Go to build software for the back-end. The safety and speed are a huge asset for rapid iteration. We’ve successfully leveraged many packages from the community, including Testify for unit test assertions and gorp for a minimal database abstraction layer.

GLPK – At its core, our product optimizes the buying and selling of television advertising. For that, we need technology that can grow and scale to accommodate larger and more complicated optimization problems. R has been crucial for the rapid prototyping of these mathematical problem abstractions but to actually solve them we leverage the Gnu Linear Programming Kit (GLPK). Both tools help us grow and refine the mathematical foundations of our product.

MySQL – We use MySQL for a principal data store, mainly because we inherited that from the MVP, but we don’t have many complaints about it. We’re starting to use ElasticSearch as a data warehouse for OLAP and to optimize heavy queries. It’s REST-first design works nicely for us, and the speed is unbeatable.

Play Framework – We use Play / Scala for the heart of our platform: the API. We don’t serve any pages out of play, but it works nicely to provide a REST API. Scala takes a bit of learning, but it provides OO hooks to ease you into functional programming.

Backbone.js – Most of our web app is based on Backbone, for better or worse. It was the right decision four years ago when we started using it, and holds up fairly well. It’s stable, but being so event driven can make it hard to reason about.

React.js – Newer parts of our app are being built in React, which we’re very optimistic about. We’re hoping to take advantage of code re-use by repackaging with React Native for mobile app use.

Amazon Web Services – We run everything on AWS, which makes life easy, if sometimes expensive. We’re trying to avoid vendor lock-in by steering clear of their branded products as much as makes sense, and instead using plain old computer resources. Jenkins runs our continuous integration, which is a hugely important part of our process. As an agile shop we want to de-dramatize releases; CI makes this process so easy that it’s possible to release without worrying.

C++ – The majority of our codebase (Desktop & Embedded) is written in C++. This allows us to share code across platforms, and to be able to carefully control sensitive areas of code (performance and memory-wise).

Qt / QML – We use the Qt libraries throughout our code. This allows us to extend C++ with nice features for integrating various logic areas (signals / slots), as well as a tight integration with QML, which we use for our user interface code. QML is a great way to track state transitions, both on our embedded & desktop applications. Qt also makes cross-platform code easier to develop & maintain.

Yocto – Our printer runs a custom Linux distribution, which we build using the Yocto project. This system allows us to track our firmware builds & releases in a deterministic way.

Git – All of our source code is tracked in git, which provides all of our version control needs. It works nicely with Yocto to be able to exactly specify versions of firmware builds at the package level. It also allows for good collaboration between developers while preserving the cleanliness of shipping source code.

Java – We use java for our core backend and middleware needs. We use it for data mining large volumes of player tracking data and for an in memory business intelligence engine.

MySQL and PostgreSQL – We use both relational DB’s in various products. They’re used in fairly similar and traditional ways. We’ve let teams pick the DB they’re more comfortable with for each app. We’ve used PostgreSQL mostly for storing user data and MySQL mostly for persisting our analytics warehouse.

NodeJS – We use Express/NodeJS for our front end web servers. This allows us to take advantage of sharing clientside and serverside code.

Polymer – We use Polymer and Web Components to help modularize our UI. This is relatively new for us, with the goal of increasing maintainability, reusability, and reduced development time.

React Native – We use react currently for iOS development. We chose React so that when we also create an android app that will be quick and still feel native on each mobile plaform.