April 7th, 2020 • By Jon de Andrés Frías In the first part of our series of blog posts on how we remove technical debt using Apache Kafka at Rollbar, we covered some important topics such as: In the second part of the series, we’ll give an overview of how our Kafka consumer works, how we monitor it, and which deployment and release process we followed so we could replace an old system without any downtime.

March 10th, 2020 • By Jon de Andrés Frías In this two-part series of blog posts, we’ll explain how Kafka has helped us in removing parts of our architecture that we consider to be “legacy”. During the development of a project sometimes we need to take decisions on our architecture or software design that may not be the best decisions from a pure and perfectionist technical perspective.

Nearly eight years ago, Cory and I started on a journey to help developers build software quickly and painlessly. As software developers ourselves, we had felt the pain of being afraid to ship and spending late nights tracking down bugs. In 2013, we launched Rollbar into the world so that developers could build software faster, shipping often without fear. These days, lots of people talk about continuous delivery, and nearly all of them focus on automating releases.

At Rollbar we love workflow automation. With our new Notifications API, you can automate setting up of custom notification rules for all your Rollbar projects. As more of our customers switch to microservices, we wanted to build a programmatic way to set up these rules for multiple projects or services in just a few seconds, without having to go to the UI.

At Rollbar, we care about reducing the time it takes developers to find and fix errors. This is why we’re making our integration with GitHub even stronger to provide more context around errors and reduce the mean time it takes to resolve them MTTR. Last year, we launched Code Context to show additional lines of code within each frame of the stack trace, reducing the back and forth between GitHub and Rollbar.

In the first post of this series, we looked at the state of your organization, how to tell if Microservices are right for you, and wrapped up with a few challenges this architecture brings to the table. In this article, we will look at organizational changes that will help you adopt a Microservice architecture. Additionally, we will touch on topics like how to bring change to your organization, how to embrace the primacy effect, and why you should embrace cross-functional teams.