So, I decided to give the MikroTik community a glimpse into what it's like to build a company dedicated to writing software for MikroTik networks.
My name is Hannes (https://www.linkedin.com/in/hannes-kruger/).
I logged into my first MikroTik router, an RB133, when I was 17 years old. That was 17 years ago, half my life ago.
Since then, I have used MikroTik routers for just about anything you can imagine: ISP core stuff, CPEs, WISPs, VoIP. Before Raspberry Pis were a thing, there were a few occasions where I soldered transistors to the user LEDs to operate relays controlling other equipment. Whatever the problem, a MikroTik router seemed to solve it.
About five years ago, I got it into my head that I would build a software-defined networking platform for MikroTik routers. Progress was slow initially (the first 18 months) until I decided to do it full time. We started acting like a software company, hiring talented developers, strengthening our focus on security, and looking at MikroTik/RouterOS from a developer's perspective. We asked questions like how do we build API-driven tools for MikroTik networks that are secure, developer-friendly, and modern.
In my mind, a reliable REST API + modern WebApp + MikroTik = an incredible product that could hold a candle to all the blue-chip brands in the SDN space.
So, did it work? Did we create SDWAN for MikroTik? If your definition of SDWAN is the same as what Gartner describes, then yes. We built and implemented that on MikroTik, and we did it in line with well-established industry standards.
Is it successful? As a business, no, not really.
These are some of the facts of this business:
- Writing scripts in RouterOS sucks (speaking from a developer's point of view). Compared to modern tooling, scripting in RouterOS feels like playing tennis on roller skates while handcuffed. This means you offload most of the workload to your own software. The less you process on the MikroTik, the more compute you pay for (in our case AWS).
- Producing quality and stable software takes a long time. There are very few shortcuts, and finding developers who understand networking is tough—they're unicorns. You don't want a network guy trying to become a software engineer. Writing modern and scalable software is much harder than understanding routing and networking stacks.
- Security first. If you are essentially the management plane of a lot of MikroTik routers, you have a target on your back. If you end up being the reason all your users' MikroTik routers were hacked... that's it, curtains.
- Skills are expensive. Over the last five years, we've spent more than the cost of 10 brand-new Tesla Model 3s, and we've never made a profit.
- Compliance is a big battle. Customers shopping for SDWAN solutions naturally assume that you are ISO27001 and SOC2 accredited (like the incumbents). These are big undertakings and time drains.
- Trust among the MikroTik community doesn't come easy. At one point in this journey, we went through a 750-point check on the security of our infrastructure in AWS by a third-party consultancy (WARF). It consumed months and cost thousands of dollars. It was totally worth it, we fixed a bunch of stuff, but we still respond daily to members in the community who label the entire company as a scam / security risk.
- And here is the biggest issue: $50 per year per MikroTik for SDWAN and a list of other features is too expensive. Most users can't / won't pay it, even though it costs less per year than an elevator ride to the top of the Eiffel Tower for two people.
- We have around 4,000 MikroTik routers on our platform, and to get there, we've taken plane rides, attended conferences on different continents, had hundreds of meetings, hired marketing firms, etc. Paying license fees seems to be diametrically opposed to the expectations of the average MikroTik customer.
Does Winbox pretty much still look like it did 17 years ago? Yes. Will the community put its trust in a third party to offer a modern alternative? It's unlikely, but we'll hold the course for now.
