The purpose of this post is to present reasons that make the idea that Mikrotik starts to support the MIPS platform for the Container feature in RouterOS 7.X and bigger.
Proportion of hardware with MIPS architecture in Mikrotik's portfolio:
I think it's almost unnecessary to bring up this argument, but it's always good to adjust to exemplify what the gain and increase in possibilities would be.
In the following link we have the Mikrotik product matrix officially published by itself.
I have attached the CSV that i downloaded on 2022-07-13 where 390 items are listed.
116 are related to the MIPS architecture (SMIPS->3, MMIPS->8, MIPSBE->105).
On a dry account we have 30% of the published portfolio being MIPS architecture.
And I am convinced that if mikrotik could add the number of devices produced/sold in each row of this spreadsheet, the proportion of MIPS devices in absolute numbers would exceed 70%.
The existence of MIPS architecture support in Container technologies:
Docker:
It is a fact that the dominant tool in the world of Linux containers is Docker, and if I didn't make a mistake in the interpretation, the official information from Docker says that it does support the MIPS architecture.
docker-library/official-images
It says: "As of 2017-09-12, these other architectures are included under the non-prefixed images via "manifest lists" (also known as "indexes" in the OCI image specification), such that, for example, docker run hello-world should run as-is on all supported platforms."
The Open Container Initiative link points to supported architectures in:
$GOARCH on GO Language
Also, in the special MIPS architecture section of Docker Hub there are official images to Debian and Busybox.
Podman and other Container engines:
In addition to Docker, other engines like Podman and some listed at https://github.com/containers also support the MIPS architecture.
Possible uses:
Well, when talking about containers running inside devices like RouterBoards Mikrotik, we can say that if the limits of capacity and hardware characteristics are respected, "The sky is the limit".
P.S. Here is a suggestion of a hard/soft limitation previously defined by the configuration defaults to prevent some genius from unknowingly overloading the equipment's capacity and then complaining about the capabilities of the RouterBoard.
However functions that are in my plans at the moment are related to desirable services in an ISP/ITP management network, such as Zabbix Agent, or Syslog Collectors.
Note: Support for M.2 drives on miniPCIe got me really excited about these ideas.
Obviously, it doesn't stop there! Reverse proxy with NGINX or Traefik is very promising. And DNS-related services like an authoritative DNS engine, or things like pi-hole also need no explanation of how they would be useful to the niche market that Mikrotik serves.
And what about MetaRouter?
Well, Metarouter is/was something very smart! I think it did its job...
But today, if we compare the Workload of maintaining a Container Registry, or the idea of having to build images to put services running inside a RouterBoard using MetaRouter, I think the reason to avoid thinking about Metarouter is quite evident.
"But it has already been said that the MIPS architecture will not be supported by RouterOS":
Yes, I've been reading and researching this before creating this post.
I found some answer from
,Normis
,pe1chl
,jbl42
about that starting in post #214 in topic v7.3 and v7.3.1 [stable] is released!tangent
However, I want to believe that these points that I have brought up here have not been fully taken into account at that time.
Thank you in advance for your attention and effort to understand these arguments.