Recently, GitHub announced a totally new way for applications to integrate with its service. This will allow applications to act as independent entities on GitHub. Currently, applications must always impersonate a user who has the necessary permissions to perform a given action. It can be a headache managing which user an application needs to impersonate in order do the work it needs to do. GitHub’s recent change affects how applications can receive webhooks, how they interact with users, and how they connect to GitHub. Here are three ways Integrations will be easier to implement and maintain.Keep reading
The official blog from the team at Runnable.
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
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