It's business time

When I started this blog it was my intention to write about two topics: Technology I've tried and found interesting, and my experience starting a company.

So far, there hasn't been much writing about the business side of things. I've been working on a product for a while, and some of the technology I've written about has been related to that. But I haven't written much about actually starting a business.

Well, there have been some changes recently. I've decided to give starting a business an actual go, and I've quit my job to do so.

There are going to be more business related posts in the future. Today I will opt for a smooth transition, something in between. I will show you what I am working on.

The amazing world of DevOps

Oh man, the world has changed in recent years. I struggle keeping up, but what a great time to be a developer. We have truly great and powerful cloud platforms at our disposal, and amazing tools for running a well-oiled software machine.

Source control, build servers, automated testing, deployment, configuration management, centralized logging, monitoring.. And everything in between.

Despite all this, in my experience there is often something missing from the mix. That last link between the systems, and the people operating them.

Things will happen inside our applications, and we won't know about them and handle them in a timely manner. Things happen all the time, good and bad, and we want to respond when they happen.

Ever heard anyone say something like?

"The server went down around 4AM, but I didn't see the e-mail until now"

Or?

"A customer called, he put in an order a week ago but hasn't heard from us"

Interesting things happen inside our applications all the time, and we need to get the right people reacting to them as they happen.

I want to create a tool that will help track all these events, aggregating them from our applications, existing logging and monitoring tools. And make sure the right people know about them, and handle them.

And it's not just about reacting to technical problems, it's about reacting to business events as well. Getting customer service to make that phone call to help a customer, or the sales rep to send an e-mail to a prospective client. Operations is about more than keeping your database available.

Introducing Happyrelay

There is still a long way to go, but I am working on something I call Happyrelay.

Happyrelay Sensors Overview

I've got a ton of ideas for this, but let me walk you through the core concepts I am implementing for the first version.

Happyrelay Core Concepts

Team

At the heart of Happyrelay is the team. The people working in your organisation who are responsible for operating the applications. Add your team and assign responsibilities.

Scheduling

Schedules can be used to delegate responsibility differently at different times. Not everything has to be scheduled, but it's handy for sharing on-call workloads.

Sensors

Sensors are how we start reacting to things. Ultimately sensors could be any number of neatly wrapped integrations with other tools. For the first version, the two "native sensors" supported are going to be e-mail and webhook.

You configure a sensor to receive input either by sending e-mail to it, or by invoking a REST sensor endpoint.

Triggers of the sensors can then be filtered according to data in the e-mail or webhook request. Information about sensor triggers are stored and visualized on a dashboard.

With the two general purpose native sensors you can start aggregating all sorts of events from your existing logging and monitoring systems, as well as custom business events from your applications.

Incidents

You can set criteria for sensors to raise incidents when triggered. An example could be a monitoring system reporting that your website is unavailable.

Escalations

You create escalation plans that can be started when incidents are raised. Escalation plans specify how and who to notify about incidents. Escalation plans make sure that the right people are alerted about events, and that incidents are followed up until they are handled.

Notifications

Notifications are different methods of contacting people (or other systems) which can be used by escalation plans. Ultimately notifications could be any kind integration. To get started Happyrelay will support four "native notifications", e-mail, text message, phone call and webhook.

The first three are obviously for notifying team members directly, while webhook can be used for notifying other systems, or for creating custom integrations.

The sum of the parts

Put together you should be able to create workflows that go from sensor input to reaction output. With logic deciding who should be responsible for following up.

How will I run this thing?

I plan to create both an on-premise, an on-premise/SaaS-hybrid and a full blown SaaS solution. Eventually.

To get started I will put together a beta version that can run on-premise, and that you can use for free. The plan is to always offer a free community edition that you can run on-premise.

When can I try it out?

Good question. I've worked on this for quite a while now, and it's getting very close to something usable. I don't want to make promises other than I will release it as early as possible. Warts and all.

If you want to try it out, sign up over at Happyrelay and I will let you know when it becomes available!

So that's it

My first real attempt at a non-tech post. More will follow. I hope you found Happyrelay interesting. Please let me know what you think! :)

View Comments