MirageOS for B2B SaaS

Ecosystem
,
1

Hi dear OCaml community!

I have an idea to build a SaaS for corporate blogging (like Medium, but for companies) and I want to try MirageOS as a total platform for services. I have no production experience with OCaml (only Golang, JS, Ruby) and have no experience with MirageOS and unikernels (only Docker, Linux, and a little bit k8s), but I’m very interested in both. Could you please help me to clarify possible issues with such an approach?

Also I’m interested about a hosting for MirageOS services. I don’t like containers and k8s stuff and I prefer dedicated and virtual servers instead of cloud stuff because I have no resources to pay up to 5x more for hosting.

Thank you for your help!

3 Likes
2

Hello,

Thank you for your interest in MirageOS. MirageOS is first and foremost a framework for creating an application (such as a blog) for several targets. One of these targets is Solo5 which allows to create an entire system which includes everything necessary for OCaml (its runtime). Thus, one can deploy a MirageOS application on:

  • KVM (with the target hvt)
  • Xen
  • or produce a simple executable taking advantage of seccomp (and thus finely controlling access to the executable).
  • we can also mention the experimental target for Raspberry Pi 4

The objective of MirageOS is to make the choice of targets transparent to the application. This means that for a given application, deploying for KVM or Xen should not be an upstream choice (which would govern the development of the application) but the last of the choices which can, of course, be left to third party users.

This reverses the development logic of an application thanks to abstraction mechanisms (specific to OCaml) (the functors) that allow to get rid of any specialisation to a given system (Solo5, Unix, Raspberry Pi, etc.).

This is of course the theory and in practice, it works quite well :slight_smile: .

To take the example of the blog, you can see Hannes’ blog or mine which runs on MirageOS (KVM). The latter have a similar architecture: a unikernel managing TLS certificates and redirecting HTTP connections to unikernels on a local network (tlstunnel or contruno) and a unikernel (unipi) that only transmits what appears in a Git repository via the HTTP protocol (http/1.1 and h2).

Deployment depends of course on what you have. Regarding KVM, you can follow the tutorials here (quite general) and there. You can deploy your unikernels on Google Cloud with this (probably a bit old) tutorial. Finally, a deployment with seccomp is possible, it is a simple executable.

Of course, most of these unikernels are already available for download here thanks to the excellent work of robur.io. It is ensured that the generated image is reproducible regardless of the context.

There is of course a whole series of unikernels made by the community that you can mainly find on GitHub. We can talk about several services like DNS or emails.

I would like to specify that all this is still experimental. We are gradually reaching the stage where our unikernels are used in production domains, but it still requires a lot of work and a lot of skills for such a small team :slight_smile: . Of course, we are open to everyone’s participation and we are especially here to help newcomers.

14 Likes
3

Thank you for such a detailed answer!

1 Like
4

To add to @dinosaure answer, you may be interested in albatross – which supports solo5-hvt (KVM) and solo5-spt (seccomp) to start and restart unikernels (with remote management via TLS + certificates). Access to the (read-only) console is provided as well as integration with monitoring / metrics.

If you’ve further questions or want to chat, feel free to contact us (team at robur dot coop).

3 Likes
5

You can deploy your unikernels on Google Cloud with this (probably a bit old) tutorial.

I feel it necessary to add that it’s not currently possible to use block storage on Google Cloud with Mirage, as Solo5 does not currently support the virtio-scsi disk. Some more details here.

I’m not sure the cloud story with Mirage is all that great on AWS either, as only their older virtualization platform is supported.

These may or may not be deal-breakers for your SaaS play, but it seems worth mentioning.

6

Writing business critical software in an unpopular language is a questionable choice (guilty). Writing business critical software in an unpopular language you don’t know, using an exotic deployment platform even for that unpopular language is an extremely bad idea.

7

If you get some time at some point it’s always interesting to publish an objective write-up about what went well and what went bad.

I also sometimes struggle with this but more than once ended up with better results than if I had been able to tap in the libraries of popular languages (due to quality or performance issues). Here’s my new slogan: in OCaml, the battery is you :–)

4 Likes
8

I don’t have a feeling when it comes to the verdict, yet. I can mostly see positives when I look at the “forest”, and mostly painpoints when I look at the “trees”. Meaning that at large, the code quality is great, very low amount of “bugs”, we can still move quickly, people interested in OCaml are usually high quality talent. But at the same time, indeed, the battery is you and it can be distracting.

9

I understand this, but, that problematic stuff belongs to unknown unknows and I want to make it to be known unknows to understand risks instead of being scaried by something new.

2 Likes
10

Perhaps Scaleway would be an interesting place to host MirageOS services. I haven’t tried doing so myself, but you can get some kind of bare-metal and cloud combination (essentially you can pay for it by the hour, i.e. if you shut it off you don’t pay for compute, just for storage, etc. and you could use that to scale up/down), and then you can try to run your choice of hypervisor as bare metal and boot MirageOS unikernels. (I’ve used them in the past to run some Linux code, but that was so long ago that their offering seems to have changed substantially since then. I)

Although if you never used unikernels before I’d suggest to run MirageOS in Unix mode first. Then you can use familiar tools like strace, gdb, and perf to debug your code. Once you are reasonably happy with how it works you can deploy it in unikernel mode.

Before putting anything on the Internet check that it has proper authentication (or it is entirely readonly), and that it can scale with large number of visitors (there are various load-testing tools you can run locally, prior to deployment).

For building a web service Dream — Tidy, feature-complete web framework (and it appears to have a dream-mirage package) looks promising, whether you use MirageOS or not.

Finally a production deployment should probably use something like haproxy, a DNS based round-robin, or something like Cloudflare just in case one server goes down (even if its OCaml code would run perfectly hardware or networking can always fail!) to allow another server to take over, or just in general for load-balancing.

2 Likes