Different architectures and patterns are all about different tradeoffs. More specifically, they’re about transferring and transforming complexity from one place to another, and from one type into another. The same is of course true about the event-driven architecture that we use here at Runnable.
Let’s dive into where event-driven architecture reduces complexity and where it makes things more difficult. Warning: lots of code ahead.
Keep reading
In my previous two blog posts, I explored how Runnable’s architecture evolved over the last two years. There’s no one-size-fits-all solution, but the microservices approach has yielded a lot of benefits for us. In this post, I’ll talk about how Conway’s law has worked in reverse for us, and what the results of that look like.
Keep reading
In part I, I explored the less-obvious advantages of the microservices architecture that we’ve discovered while building Runnable. In this part, I’ll explain how the microservices architecture creates happier and healthier teams.
Keep reading
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
Like any other generic solution, the microservices architecture has its tradeoffs; some things become easier and some become harder. When switching to microservices, one of the most common challenges is the question of where to put shared code.
Keep reading
I see Runnable as a very versatile, and therefore powerful, tool. It enables teams to deploy and run code on every commit. The concept sounds simple, but it lights up a vast number of not-so-obvious use cases.
For example, here’s how Runnable can be added to an existing revision workflow for static sites / blogs to improve how updates can be made.