There’s tremendous value in choosing solutions that give you the freedom to build your own solutions atop the platform. If the method avoids lock-in, so much the better.
Later today, I’ll be working with a different vendor that will not give you programming docs, API references, tools, etc. without a signed NDA, a faxed copy of your business license, a recommendation from a priest, and a sample of your blood. Then on top of that, the resulting programs won’t run on any other company’s hardware, because their platform is proprietary. Guess which company’s products we’re least likely to do custom development work atop.
MikroTik, on the other hand, is leveraging the single most popular container platform — contrast BSD jails, Solaris zones, OpenVZ… — and they’re giving the feature away for free, for anyone to do with what they want, within the platform’s considerable limitations. Even with all the problems, this does not completely suck.
fixing / adding what’s missing
I am quite certain that most of MikroTik’s customers would look at you strangely if you started talking to them about PIM-SM. That’s a very niche feature. I happen to be one of the few that does need it, but at the scale of LAN I generally deal with, it needs to exist in only one place, the big core router that separates all the VLANs, which isn’t likely to be MikroTik anyway. How many customers are we talking about, vs all the ones who couldn’t expand the acronym at all, much less justify using the technology it refers to?
I couldn’t say for certain whether BGP is more or less popular than inter-VLAN multicast — they feel about equally niche to me — but I can confidently predict that most RouterOS device owners don’t own or manage an AS themselves. I expect most MikroTik routers end up as WISP CPEs and such, not big corporate edge routers.
Spare utility computing, though, that’s something you can use everywhere, if you have sufficient imagination.
Ok, but how much free RAM/CPU to do what exactly ? For instance I don’t see a single usefull service in my 20+ VMs and containers deployed on my home network which could be a candidate for deployment on a mikrotik device.
It’s usually a mistake to think of a Docker-style container as a lightweight VM. There’s no kernel, and even on big iron hardware, you have an incentive to pare the container down as far as is practical. RouterOS multiplies that incentive by 4-10x.
In the big-boy container world, they talk about microservice fabrics and swarms of cooperating services, but we can’t afford that at the RouterOS scale. What we’re going to do instead is more of a return to the early days of containers, where it was one service per, tightly-scoped.
This is nothing like a VM, except in the most myopic manner. It’s closer to an embedded system: a single service that boots and immediately begins work, not stopping until the device loses power.
Security
Containers are generally quite secure. “Root” on the container only has a handful of the hundreds of kernel capabilities real root has out on the host, for one.
For another, you will notice that the current implementation requires NAT, not allowing direct access to the host’s bridge. That’s a sensible default, though I hope MikroTik eventually lifts it, as there are services you can only provide when bound to real hardware.
As an example, I want to see a netinstall container. Put that on a hEX-sized device, and now you have a utility box a tech can carry around and plug into ailing RouterOS boxes to bring them back online without going through the fourteen documented steps needed to reconfigure a Windows laptop so it’ll serve the same end, then reverse those steps to get their laptop back into a useful state again.
No, in my dream world, you run a cable from the rescue box to the target box, reset the latter, wait, reboot, done. With PoE, you won’t even need to carry a power brick.
Or, do the same thing to a disused RB3011, running a separate netinstall container behind each port, one for each RouterOS NPK type you have in use, and you’ve got a benchtop version of the same facility. Someone brings in a flatlined router, you pull over a labeled cable matching the CPU type of the victim, call “clear!” and zap the patient back to life.
The only thing is, I suspect netinstall won’t work through NAT, so even if they do produce ARM builds of the program for us, it still won’t work. Still, it’s a nice dream, and it’s within reach.
performance
Not everything requires a Xeon. You have only to look at all the Raspberry Pi boards pressed into service as network utility boxes. It’s why you’re seeing so many of the people in these threads talking about PiHole and AdGuard.
increased heat
ARM is about 3x more efficient on a MIPS per watt basis than Intel, so unless you’re telling me you’ve got ARM servers over there, I’m gonna call bull on that one. The service had to run somewhere, so if you have a choice between ARM and Intel, and the ARM processor is sufficiently free to carry the load, it’s a better place to put it.
separation of concerns
What do you think a container is but a way to separate concerns?
If your point is that containers let you run multiple services on a single box, then why are you telling me about VMs and big-boy servers? Your argument is incoherent and falls in on itself.
am I the only one in this situation ?
Have you even tried to read through the various threads on this? Ideas for how to use containers abound. Many are absurd, and I’ve done my share of puncturing the worst ideas, but they’re not all bad.
I won’t deploy DMZ services on an network infrastructure appliance, nor will deploy security related services on it, nor will deploy potentially high RAM/CPU/I/O consuming services, nor critical services.
That sounds like a tailor-made list of criteria against running a VPN on RouterOS.
So here’s the situation: RouterOS offers a plethora of VPN options, yet someone always wants one more. Let’s pick on Tailscale today. MikroTik almost have that one, between WireGuard and ZeroTier, but they’ve chosen not to give it to us.
And yet, they have: we have containers, on which we may hope to get Tailscale working on our own.
I don’t believe this is possible today due to restrictions in the current RouterOS container platform, but which would you rather have MikroTik working on: yet another VPN protocol, or the generic platform that lets you deploy whatever damn VPN you like?
[quote=“, post:52, topic:152868”]
Even when cost is no object, the ability to deliver a complete, integrated, custom solution may be compelling.
[/quote]This is an argument which may be of interest. But again what services are you talking about
I had PBX service in mind, mentioned in post #8 in this thread. (Thus why I challenged you on whether you’d even tried to understand this before railing on the idea.)
If you think that’s risible, I wonder what you’d tell the WISP operator what he’s supposed to do instead when selling against all the triple-play packages from the cable and fiber providers, given that MikroTik shows no interest in putting an RJ11 POTS plug on their devices.
With containers, there’s hope that you can put Asterisk or similar on the WiFi CPE you provide, then sell the customer a set of SIP phones to go with it. That’s called turning a problem into profit where I come from.
And “integrated” with external storage ? hmm…
For the USB case, there are low-profile memory sticks, the size of those Logitech unifying receivers.
For the microSD case, they’re nearly zero-profile already.
And for the m.2 case, they’re inside the enclosure.
these people were hired in the first place, they didn’t appear out of nowhere…
MikroTik only hires BGP engineers, and they’ve never put out a new hiring offer since v7 was forked from v6?
I’m quite certain not every software developer on MikroTik’s staff is equally capable of going after your pet problems. They’re certain to have different strengths, different training, and different predilections, as in any other workforce. The one working on containers probably doesn’t even know the BGP protocols at a deep enough level to help out.
ability to declare a mikrotik device as a NUT client would help rationalize UPS provisionning
There you are, then. This container is already built for ARM, it’s configurable for the shutdown command (e.g. “ssh admin@hostip /system/shutdown”) and it comes to 7-8 MiB. If you run it from flash on a 16 MiB device, you can’t upgrade ROS while it’s running, but containers are all about automated recreation. So, stop all the NUT containers, remove them, do the upgrade, and redeploy.
This sounds like a fine use of containers on RouterOS.
And best of all, from your perspective, it didn’t require that MikroTik divert any development effort away from your pet problems for it, specifically. Instead, they spent the time on a generic platform so they don’t have to answer every single random request. It probably nets out an improvement for them, freeing people from chasing random customer requests.