Back that Cass Up

Here at Geofeedia we love to take design and architecture cues from Netflix. One such cue is the adoption and use of Cassandra as a primary datastore. Apache describes Cassandra as,

…the right choice when you need scalability and high availability without compromising performance. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data. Cassandra’s support for replicating across multiple datacenters is best-in-class, providing lower latency for your users and the peace of mind of knowing that you can survive regional outages.

This post stands as the first in a series of posts discussing how we at Geofeedia are pushing Cassandra and proving out that scalability and fault-tolerance. In particular this post will focus on our strategy for running not only a cross-region Cassandra cluster in the cloud, but also cross-cloud, as well as our attempts to implement a consistent and reliable backup strategy.


Geofeedia Hackathon 2016

The Geofeedia development team recently met at the company headquarters in Chicago to compete in an internal hackathon. The contest involved coming up with an idea that could supplement the current Geofeedia platform, developing the software, and then presenting the projects that we built for the entire company within 48 hours. To make things even more interesting, every employee within Geofeedia was a judge for the hackathon, allowing voters to choose winners based off various criteria.


Graph Databases and Scalable High Volume Data Relationships

At Geofeedia, we pride ourselves in being a company that has never committed to a particular technology. Rather, we choose the technology that best fits the use case at the time of implementation. As a developer, this is an amazing quality to find in a company. What does it mean for devs? Our leadership puts faith in us to drive our product in the right technical direction with the latest and greatest technologies. This post will focus on one of our recent endeavors to implement an Enterprise Security architecture for our application leveraging a Graph Database.


Unbiased impressions of EC2 (AWS) and GCE

At Geofeedia we are true believers in using the best tool for the job, and we don’t typically concern ourselves with committing to a particular programming language, software framework, or cloud. This post will focus on that last point. Specifically, we have been operating in a multi-cloud environment for a little more than 6 months now that spans Amazon Web Services (AWS) and Google Compute Engine (GCE). While our initial motivations were driven by a cost-savings measure this ultra high-availability approach is a huge component of our architecture plans moving forward.


Distributed Builds FTW

As an engineering team, we recently decided to move towards a microservice based architecture and away from the classic monolithic application that struggles to support the modern day distributed architecture which highly available web applications require. Our goals are to write services that are isolated, small, fast, language and technology agnostic, as well as able to run inside of a container based solution (we use Docker). Ultimately we needed a distributed build system for our distributed services. In this article, we will demonstrate how we decided to use Drone CI to improve our developer productivity by reducing the lag time between a developer commit / push to git, and actually deploying that fully built microservice into our QA environment.