In my previous post, I went over how our event-driven architecture allows us to rapidly ship new features. This post covers how we used this model to ship a new feature: Docker Compose support.
Docker Compose enables our customers to build environments on Runnable using the same configuration they use to deploy to production, staging, or wherever they currently use Docker Compose. The best part? They get this with no additional setup.
Keep reading
After Runnable launched last September, we’ve received lots of interest from dev teams looking to improve their development process. One of the questions we often get is, “how does Runnable compare to my current CI solution?”
Keep reading
Code reviews are one of the most important parts of an engineering team’s workflow. The benefits of code reviews include: creating visibility for new changes, preventing bugs, improving code quality, and creating cohesive patterns. Despite the benefits, code reviews can sometimes create tension in the team: some developers are stricter than others, some take a long time to review, etc.. Often, these tensions come from a lack of agreement of how code reviews should be conducted and what the roles of a reviewer and a submitter should be.
I wrote the 10 commandments for code reviews, to create a common understanding for reviewers and submitters about how code reviews should be conducted. By following them, teams share a common understanding of their responsibilities, reduce the tension between teammates, and deploy their code faster. Since reviewers and submitters have very different responsibilities, I split the 10 commandments in 2—5 commandments for each role. Each set of commandments were written with the other set in mind, which means that both sides need to obey the commandments to reap the benefits.
Keep reading
While building two products over the past four years, our team has grown in both headcount and dev speed. Adopting a process to improve our speed of development took us a while to get right. As we all reflect and make resolutions at the start of the new year, we think other teams might benefit from how we identified our slowdowns and improved our dev speed.
Keep reading
Engineers making the move from callbacks to promises make common mistakes and introduce anti-patterns into their codebase. During my time working with promises at Runnable, I’ve identified a few common anti-patterns people use that cause issues maintaining the codebase. As I go through these anti-patterns I’ll explain what the pattern is, how to avoid it, and then take it a step further using Bluebird to make the code cleaner.
Keep reading
I previously outlined the methods I used to speed up our AWS infrastructure spin-up time. The method covered in this post further reduced that time by about 50% by pre-baking all of the services we needed to run an application.
Our microservice applications are hosted in Docker containers and can be pulled from the Docker registry and our own private registry. Rather than install and configure services on an Ubuntu server using bash scripts, the individual Docker images for each application can be copied onto every instance that we need. This allows us to add instances much faster if we need to quickly scale to handle a heavy load, and is a practice that most organizations should adopt if it can be implemented.
Keep reading
A few months ago, Anand discussed the benefits of transitioning from traditional HTTP communication to event-driven microservices. He noted how this transition decoupled our services, forced scalable patterns, and increased our resilience. Here, we’ll detail the lessons we learned when we re-implemented our Cron-esque scheduler service, Khronos.
Keep reading
Developer hiring. For both parties, it’s a stress-inducing and potentially life-changing decision. And yet, they each have around 4 hours to gather enough info to make that decision. How do you use that time? Are you asking questions that prove the competency you need? How do you compare candidates?
Keep reading