Modernize or Fade Away — architectural patterns in long-lived platforms (Nextcloud as a case study)

đź’» Development
1

Hi everyone,

I’ve been studying long-lived software platforms and the architectural patterns that appear when a project grows over many years. I recently wrote an article that looks at the point where incremental fixes stop being enough, and deeper modernization becomes necessary for performance, developer velocity, and long-term sustainability.

Nextcloud is one of the case studies I use — not as criticism, but because it’s a mature, widely adopted PHP monolith with strong backward compatibility requirements and a long history of feature growth. It’s a great example of the tradeoffs that appear when a platform evolves by layering rather than replacing core boundaries.

The article covers:

  • how architectural debt accumulates in large, successful platforms
  • why layering (caches, proxies, shims) buys time but increases long-term complexity
  • operational and developer costs of avoiding modernization
  • a RAM comparison between typical Nextcloud deployments and modern cloud-native architectures
  • practical guidance for staged modernization without breaking the ecosystem

I’m sharing it here because I’m genuinely interested in how maintainers and contributors think about long-term architectural evolution, especially in the context of AppAPI, storage backends, and performance work.

Here’s the article: Modernize or Fade Away

Happy to hear your thoughts, disagreements, or additional perspectives from people working on the core.

2

Hello @blueSauron47,

this part of the forum is mostly about writing code yourself. The core team typically will not read the posts here. Just as a word of warning, so you don’t get disappointed in case you do not get much of an answer.

I would ping @Andy here. Maybe he knows if this might be of interest and/or who might be the right person to talk to…

Christian

3

Thanks Christian, appreciate the heads‑up.
I’ll ping @Andy then — I’m mainly interested in how the core team sees long‑term architectural evolution and whether there’s any ongoing discussion around modernization paths.

4

So in general for general changes large or small the community raises, discusses and decides them at https://github.com/nextcloud/standards/issuesOn the larger scale, like when having introduced ADA, or the performance hack-weeks we do for optimizations or in areas where we introduced services or to be a bit more abstract separate deployment units by either shifting functionality or introducing new functionality.So it is a constantly respected, seen and addressed topic in the sense of a evolutionary approach to modernization in contrast to a disruptive one like a rewrite which in all honesty only sounds cool on paper and devs might enjoy the challenge but else from any non-technical point of view will be a nightmare (think knowledge gap cause you just decided to replace the whole tech stack, operational model and processes behind it for your customers and community and while some people might appreciate this, most won’t).

Also to get a bit philosophical or more holistic, modernization comes in many forms and we do address them, we update frameworks / technologies, like back then when moving from jQuery to vue, or from Java to kotlin, from xml to composables, etc. Or if you look at the operational side, while we still support anything from bare metal to vms, to containers. So modernization doesn’t have to be limited to application architecture but is just one aspect.

ExApps is a complementary concept to the existing concept of apps which allows for modularization of your solution like php app do with the extension to the operational side, that php apps lack.

So in essence we are always working towards staying relevant and becoming more relevant. I quite disagree on the overall claim of your article regarding its conclusion. That is due to my view that modernization while being important for the (technical) health of a solution (ops cost, dev cost, maintenance, whatever) is only one factor that makes a solution relevant or fading away and while they do have an impact on time-to-market or implementation/maintenance cost, they have limited impact on marketing, sales or community building and health of the whole ecosystem.
In short Nextcloud is a modulith, not a monolith and never has been (!), The core server is strucuted and uses dependency injection so the code is de-coupled yet given the “core” aspect of it, there is also a strong cohesion within the modulesa and between these modules, so distributing them on the network is not going to help you. Nextcloud furthermore is deployed in many very large scenarios which work very nicely but also show a very clear pattern: load distribution happens on the macro-level, so micro-services won’t give you an edge, quite the contrary, on a (virtual) hardware level the general utilization will show you that individually scaling smaller gears in your clock won’t safe you any resources but you pay by extra complexity in operations. Yet there is always room for improvement large and small scaling.
Circling back to ADA, we started improving the file access layer as a first step and you could call that modernizing, for me it has been a clearer, better suited architectural approach for that type of logic and keep continuing in looking for such changes.

:waving_hand: Greeting, Andy

Also I like people and you in this thread in particular voicing their thoughts and concerns to have a constructive discussion on how to keep improving things in and around Nextcloud - hence happy to keep discussing and elaborating on architectural matters!

5

Thanks a lot, Andy — I really appreciate you taking the time to write such a detailed and thoughtful reply. I have a lot of respect for your work and for the whole Nextcloud community. Diverse viewpoints and open discussion are what keep any project healthy, so I’m genuinely glad we can talk about this constructively.

I fully understand your perspective on evolutionary modernization and the risks of disruptive rewrites. I don’t disagree with the reasoning — replacing an entire tech stack or operational model would indeed be painful for both developers and users.

At the same time, I still believe that the long‑term sustainability of a PHP‑based modulith will eventually face limits. ExApps is a great step forward — it keeps the ecosystem intact while allowing modern, isolated components. In many ways it’s the “best of both worlds”, but it also feels like postponing an inevitable question: how to stay competitive against lightweight, cloud‑native architectures that rely on standard SQL databases, S3‑compatible storage and independent services rather than tightly coupled plugins.

Part of why I’m asking is practical: I’m evaluating whether it makes sense to build a Nextcloud integration for my application, or whether I should look in a different direction. App already runs its own backend with S3 storage and PostgreSQL, so an ExApp wouldn’t add new capabilities — it would mainly introduce an additional container that wraps an existing service just to expose a UI inside Nextcloud. Even if lightweight, this increases operational complexity. And more broadly, if platforms like Nextcloud or ownCloud cannot evolve beyond the PHP/WebDAV era, they may gradually lose relevance in a world where modern applications are independent services connected through open standards and unified login (OIDC), not through heavy plugin systems. Unified authentication is increasingly becoming the “anti‑plugin” model: users simply see a dashboard of applications, each running its own stack, storage and database, without needing to be embedded into a PHP‑based modulith platform.

Maybe the future really is continuing to run relatively simple applications on increasingly large VM footprints with multiple independent containers — or maybe the momentum toward lightweight, standard‑based, cloud‑native stacks will keep accelerating. Time will tell. My intention isn’t to be confrontational; I genuinely value every perspective in this discussion and I’m simply trying to understand how these architectural choices shape the long‑term direction of the ecosystem.

Thanks again for engaging in this discussion — I truly appreciate it.

6

Hi again,
happy to further discuss the matter.

So two issues here from my perspective, first one “believe” and second one “eventually face limits” - neither is an argument but both reflect a feeling without any evidence. So my question would be what is the limitation you expect PHP (as a language or runtime) to hit? And what would be the sustainability problem with the modulith? To be clear I do not argue for it to be the single best solution. An architecture should always be adequate and cater for various requirements. So certain thing have already been carved out, or their level of clean modularization has been improved. To be clear, thanks to DI, when a request hits the server-side only the relevant part of the code-base gets executed, not the whole sever-package code (like most or any other language), if it is about having a server/application state, not tied to a user/request than upcoming things like the FrankenPHP project will bring this concept to PHP as well (like many other languages have) and we are actively keeping tabs on the project and analyse how to bring the project or a similar one with the same concept to Nexctcloud.

With ExApps in mind and even with classic PHP apps, being more plugin-like what is is you are missing or where do you see the issue? In short, yes, any app that is not tightly integrating the the core functionality could well be an ExApp, any app closely integrating should probably be a classic PHP app to safe on latency cost. SQL we do support, S3 as well but only as one type of storage and making it the only one would also be rather bad, again the architecture should cater for the requirements, and being storage agnostic is a requirement.

Arguing for independent services I can’t tell if that implies independent apps will little integration, than yeah Nextcloud is not focused on that, in the sense of it being a platform, not an application builder framework like Spring would be for Java.

So basically this is the actual question to answer. And for me it boils down to what is your goal - what are you trying to achieve?

If you already have a fully operational, standalone app, than I have to thought on that: Either you want to make your life easier in terms of maintenance and you are looking ore for a application framework while potentially keeping your freedom but that implies not looking for a platform and ecosystem. If you’d be looking for tapping into a community and hence pool of potential users and if using you app furthermore adds extra value of makes even more sense to use in a EFSS/Nextcloud scenario mid-term also visually integrating in terms of look and feel, than Nextcloud form the existing platforms (yes, I am obviously very biased) makes sense but comes with the platform price of having a tighter external dependency than not being embedded into an ecosystem/community.

As for the remaining parts you mentioned, hard to comment - as you said: the future is very hard to predict here. I personaly doubt the dashboard-approach. That has been here many times which former names, call it a portal, a best-of-breed approach, it all had a general UX issue in the end of trying to take the shortcut in terms of loosely integrating saving development and maintenance effort at the cost of experience and while it works in the begging (time to market) it fails in the long run given the better product is the better integrated one. So to me is is also a bit of a pendulum of trends, none ever fully going away and none ever fully winning over the other. In the end the question is about the personal goals when making the decision for one or the other and which trade-offs of which approach you can easier live with.

…and yeah, if this is your scenario and implying from my point of view it is not what users generally want but something a certain percentage of an overall user-base would be fine with than all your arguments work. The moment my hypothesis kicks in that given the applications have at least some relation to each other and are not nicely isolated in what they do, but rather close, than this architecture gets you into serious performance issues and deployment monoliths.

So maybe a bit philosophical or political correctness. I believe all architecture patterns have their use case. Nextcloud is proven to be very scalable so at least for now and when talking millions of users on a single (clustered) instance it works very well. With ADA the task has been to change the file layer in a way that is is capable of managing an instance with 1 billion users. So the current architecture is proven to work and delivery at scale, hence can’t be that bad given reality proves it to work. Also when talking with customers and looking at their very large systems, it becomes clear that scaling works on a macro level and the micro-level as a conceptual improvement actually provides no real benefit in terms of operational cost.

The long term direction, is hard to tell. Given the evolutionary approach and the value of freedom at Nextcloud I see both current concepts to simply co-exist and people also had the idea of a strip-down 3rd approach where Nextcloud would just turn into a lean runtime layer for apps without the integration making it a pure app framework and execution environment.

Happy to discuss the matter and also appreciate the constructive and open discussion around it :folded_hands:

7

Thanks a lot for the thoughtful and detailed explanation — I really appreciate the transparency and the insight into how Nextcloud is evolving. It’s clear that a huge amount of engineering effort goes into balancing innovation with compatibility, and I have a lot of respect for the challenges involved in moving such a large and widely‑used platform forward.

I’m genuinely cheering for Nextcloud. It’s an important project for the open‑source community, and I’m glad to see that the team is actively modernizing the architecture (ADA) instead of standing still.

At the same time, I hope you won’t mind one small reflection: sometimes, in large projects, a more radical architectural shift can actually help developers adapt faster, instead of maintaining a very complex legacy layer for many years and consuming huge capacity. I fully understand why Nextcloud can’t simply “start from scratch”, but I also believe the community would be capable of adapting if the long‑term direction were communicated clearly and confidently.

Either way, since I want to build something useful for the Nextcloud ecosystem, I’ll happily align with the current direction — AppAPI, external services and modern Web‑App patterns make perfect sense, and I’ll follow that path.

Thanks again for the constructive discussion and the friendly atmosphere. Looking forward to contributing to the community.

9

@blueSauron47 Sorry for the late reply, the last days have been busy on my end. Always happy to discuss and also in the future to discuss architecture, tech, any kind of decisions, directions and crucial points!

I can agree to that assessment and that this is a viable option as well. We often also get the feedback that we change things too often (every major release something to be done by app devs) and that maintenance can be time consuming, so devs also want stability. So yeah smaller steps at a higher frequency vs. larger steps but less often. Both have their pros and cons!

In any case I do value and highly appreciate such conversations like this one and am obviously happy that you generally like the Nextcloud projects and I am looking forward to your work and contribution to the community and ecosystem! :folded_hands: