#55 tweaks

Author: miku

content/posts/meetup-55-wrapup.md

@@ -14,7 +14,7 @@ Hybrid Meetup #55 took place
 [Dr. Jörn F. Dreyer](https://www.xing.com/profile/Joern_Dreyer) from
 [OpenCloud](https://opencloud.eu). A recording can be found [here](https://youtu.be/DChn7mZuiIA):
 
-![](screenshot-2025-10-30-134510-leipzig-gophers-55-opencloud-youtube.png)
+![](/images/screenshot-2025-10-30-134510-leipzig-gophers-55-opencloud-youtube.png)
 
 OpenCloud is a widely deployed cloud storage and collaboration platform built
 on a variation of a microservices architecture. It scales from homelab
@@ -24,23 +24,27 @@ The presentation reflected on some architectural and deployment changes over
 the years - densily packed with engineering wisdom that extends beyond code and
 include aspects like deployment, backwards compatibilty and scalability.
 
+<!--
+
 [![](/meetup-55-opencloud/screenshot-2025-10-31-112307-opencloud-landscape.png)](https://docs.opencloud.eu/)
 
+-->
+
 Some highlights from the presentation:
 
 * [reva](https://reva.link/) is a CERN storage interop layer and is also where opencloud story started
 
 > Reva is an interoperability platform consisting of several daemons written in
 > Go. It acts as bridge between high-level clients (mobile, web, desktop) and
 > the underlying storage (CephFS,
-> [EOS](https://eos-docs.web.cern.ch/diopside/introduction/index.html), local
+> [EOS](https://github.com/cern-eos/eos), local
 > filesytems). It exports well-known APIs, like WebDAV, to faciliate access
 > from these devices. It also exports a high-performance gRPC API, codenamed
 > CS3 APIs, to easily integrate with other systems. Reva is meant to be a high
 > performant and customizable HTTP and gRPC server. --
 > [github.com/cs3org/reva/](https://github.com/cs3org/reva/)
 
-EOS itself is an impressive storage system:
+[EOS](https://eos-docs.web.cern.ch/diopside/) itself is an impressive storage system:
 
 > EOS instances at CERN store more than seven billion files and provide 780
 > petabytes of disk storage capacity using over 60k hard drives (as of June
@@ -64,7 +68,7 @@ CERNBox](https://www.epj-conferences.org/articles/epjconf/pdf/2025/22/epjconf_ch
 
 * not uncontroversial: you can get rid of a database at the core of your application (which was, in parts, a bottleneck) and move to a file based setup (plus lots of caches)
 * moving from individual shares to the concept of spaces opened up a more maintainably way to handle users (and users that left)
-* moving from from individual microservices to a more monolithic microservice architecture has been beneficial; internally opencloud uses [nats](https://nats.io/) for messaging
+* moving from from individual microservices to a more monolithic microservice architecture has been beneficial; internally opencloud uses [nats](https://nats.io/) for messaging (cf. list of microservices in the docs: [section services](https://docs.opencloud.eu/docs/dev/server/))
 * large scale deployments with predictable, but still spiky patterns inspired changes to the node communication setup
 * while user report that opencloud feels fast, it is hard to attribute this to the move from PHP to Go, only
 * the layer between a (distributed) filesystem or object store and the end user