When we first started deploying containers across multiple servers, we managed scheduling ourselves. We had to maintain cluster state and determine the best place to schedule a container. We had a solution, but it was not elegant or pretty. When Swarm came out, it promised to solve our scheduling woes. Unfortunately, using it in production hasn’t been as straightforward as we’d hoped. In this post, I’ll cover the problems we encountered and how we worked around them.Keep reading
The official blog from the team at Runnable.
A good developer is a lazy developer. A good developer should always hate doing the same things over and over again. One of the best ways to embrace the laziness and be more efficient is through writing good shell scripts. In this blog post, I’ll show some of the tricks I’ve recently learned while writing some more complex bash scripts.
Note: In this post I’ll be talking specifically about bash, since it’s what I use and what I prepared all examples with, but most of it should work with other shells.
I’m excited to announce Runnable is now generally available. Runnable makes developing container-based applications a lot faster and easier.
Since we started in 2013, our vision has remained the same — make it easy for anyone to run code without worrying about infrastructure. As software teams around the globe adopt containers and microservices, we think the time is finally right for Runnable.
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.
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
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
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
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.