The official blog from the team at Runnable.

Event-driven Microservices Using RabbitMQ

Using the right patterns to communicate between microservices can help scale your application and solve most distributed systems problems. We started with direct HTTP calls for all communication, but decided to move to an event-driven system. This system changed the way we thought about interactions between services, forced scalable patterns, and increased our resilience.

We moved to using events over traditional HTTP communication for a few reasons. First, it forced decoupling of services. From our experience with HTTP, one service would make calls to every service it needed to, and that meant the original service would need a client library for every service it communicated with. The client library would ensure errors would not stop or block functionality, and would be consistent with each service.

Keep reading
Lessons Learned While Building Microservices, Part I

The microservices architecture, like any solution, has its tradeoffs. Most have heard the main talking points — the decoupling of components, faster and more frequent deployments, and improved fault tolerance. Over the past couple of years, I’ve observed these first-hand, along with other subtle advantages of the microservices architecture.

Keep reading
Runnable RC and Pricing

We’re very excited to announce that Runnable is now in Release Candidate. The progress we’ve made far exceeds our Beta and Preview releases, and will prepare us for the weeks ahead. Here’s what’s new:

Keep reading
Elastic Routing in Runnable

Our service gives teams full-stack environments for every branch. This means we run all repository branches simultaneously, each on a different container. As new commits are pushed to a branch, we automatically rebuild its code on a new container. To make all of this useful, we give a URL to each branch that’s always connected to the container with the latest commit. Behind the scenes, our routing system dynamically switches the container that’s connected to the branch URL, which may have ended up on a different host to help distribute load across the instances we provision for every team.

Keep reading
Think Before You Mongo

I believe choosing the right database for your application is an even more important decision than choosing your programing language. Picking the wrong database can really hurt you down the road.

MongoDB is the go-to database for many NodeJS applications. It has its uses, but despite the hype, it’s probably not the best choice for your application’s main database. Many people choose Mongo for the same reason we did: its schema-less design makes it simple to set up. This enabled us to focus on quickly building out our MVP. But if you take this path, beware that you may be charging a large sum to your tech-debt card.

Keep reading
Using a Slack Bot to Improve Customer Support

We rely heavily on Slack for communication throughout our company, so it was only a matter of time before we started utilizing Slack bots to improve our customer support workflows. With some light reading and a little programming, we’ve begun automating many mundane tasks which help us improve how we troubleshoot customer issues.

Keep reading
Handling Errors with ES6

Over the last couple of months, we’ve transitioned away from callback-style error handling. Instead, we’re handling our errors with ES6 features (mainly promises and classes). In this post, I’ll talk about why we’ve made this transition.

Keep reading
Cost-efficient container scheduling with Docker Swarm

We run hundreds of thousands of containers across hundreds of servers a day. One of the biggest challenges we face is how to efficiently schedule containers. In this sense, scheduling is managing the allocation of containers to a set of servers in order to keep things running smoothly. Because the containers we schedule are components of our customers’ applications, we have to schedule them with no prior knowledge of their performance characteristics.

Keep reading