5 ms·

That sounds scary. Going from a monolith to a microservices architecture doesn't seem like a great move for a software like ownCloud. I think rewriting this as

That sounds scary. Going from a monolith to a microservices architecture doesn't seem like a great move for a software like ownCloud. I think rewriting this as a Go application with a modern JS-based frontend might make sense, I just don't get why you need to throw microservices into the mix. But let's see if they can pull this off, historically such rewrites don't have a great track record though.

jeandejean 6y ago
I'm curious about past examples of failures, can you provide some? Thanks!
- bayindirh 6y ago
  The thing with Owncloud/Nextcloud is the complexity of the system. When many users are working with the files at the same time, there's a lot of messaging going on in the backbone. If people are working in shared folders, that traffic goes visibly up. Messaging between systems is hard. When things are async, it's harder. When there's async concurrency, it becomes spicy. I'm managing a Nextcloud instance at the office. Even with this relatively mature state, it can bork itself pretty decently. Also, it has separation of responsibilities and a system admin is not an admin the traditional sense so, a lot of things are hidden between logs and other layers. Complicating this further by adding microservices is a brave idea at least. We're going to see what's going to happen. I hope they succeed but it's not a piece of cake.
- fundatus 6y ago
  Netscape for example: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - rimliu 6y ago
    It is telling when a single example is used for 20+ years.
    - superjan 6y ago
      I know 3 examples from personal experience. One that I worked on myself, that was scrapped before completion. Two other two were finished but they have severely impacted the business. But they are not so useful to share because you would not know about these products. My assumption is that we all know these kind of projects, but the Netscape story is a great reference because it explains why it is a bad idea.
    - mjw1007 6y ago
      And in hindsight it doesn't seem a terribly good example. Gecko was a technical success. On the non-technical side, it isn't at all clear that Netscape-the-company came out worse than it would have done if it had tried to stick with the buggy Netscape 4 rendering engine.
      - ThePhysicist 6y ago
        I'd argue that their attempted rewrite of Firefox in Rust also caused them to actually fall behind in terms of features and speed, which is reflected in the diminishing market share of Firefox. Technologically Rust is an awesome language and a boon to secure software development, I'm just not sure it was such a great idea for Mozilla to put so much energy into this, which could've gone into improving their main product instead.
        ikt 6y ago
        I'd argue not because I switched from Firefox to Chrome at v1 https://ubuntuforums.org/showthread.php?t=1398220&page=11&p=10129030#post10129030 https://ubuntuforums.org/showthread.php?t=1398220&page=11&p=... Chrome was absolutely faster in web rendering than Firefox and more stable and the UX was cleaner, it made Firefox with its slow buggy performance and awful theme's look like myspace to Chromes facebook. I also remember being very frustrated with Firefox on Ubuntu ~10.04 at the time and when Chrome came along it was exactly what I'd been waiting for. Quantum/Servo/Rust/UI refreshes seems like this was Firefox catching up to Chrome v1 and honestly in 2020 it feels like Firefox has finally caught up significantly. It's still not as stable as Chrome but it's getting there, webrender is a massive leap forward in performance: https://testdrive-archive.azurewebsites.net/Performance/Chalkboard/ https://testdrive-archive.azurewebsites.net/Performance/Chal... That test is now showing at 6.65 seconds down from 45 seconds without it.
- ThePhysicist 6y ago
  There are many examples where complete rewrites have caused problems and killed or hampered companies, Netscape and Firefox come to mind. Regarding microservices I don't know any OS projects that have failed because of that (because there aren't many OS products that use a microservices architecture), but personally I witnessed many corporate software projects burn and fail when trying to rewrite an "ugly" but functional monolith as a collection of microservices. The thing is that the energy which you invest into rewriting your entire software in a new stack could also be invested into improving your existing stack. LAMP is not dead and actually evolving quite well, so there are definitely ways to improve the stability and speed of a LAMP application without rewriting it in Golang (even Facebook still uses PHP, albeit with some modifications). Having written extensive applications in both scripting languages and Golang I can say that the latter has its advantages but is also slower to develop in and in many respects not as agile as a scripting language like PHP or Python. Doing a rewrite of a popular project with thousands of deploys in the wild will also force you to split your attention between keeping the old system running and building the new one. Since most of your users will want to migrate from one system to the other without losing their existing data and configuration you'll have to ensure that there is a clear migration path that works, which can be quite hard. Also, all external systems that are interacting with existing installations (e.g. via APIs) will also need to be supported by the new system. In the end it might be possible to make it, but in my humble experience I think a complete rewrite is almost never a good idea and the energy you put into it is often better invested in making gradual improvements to your existing codebase. But that's just my 2c of course.
  - rimliu 6y ago
    I'd say in your examples there were problems at companies which killed or hampered them and also caused rewrites.
    - ThePhysicist 6y ago
      Probably! From my experience I think the main problem is that developers often don't like to work with "legacy" code, where legacy means anything they didn't write themselves. Also, most developers tend to drastically underestimate the cost of a full rewrite as they don't know all the intricacies of the old system. From the outside most systems seem easy and straightforward, so people think they should be easy to rewrite. During the rewrite people then discover all the little edge cases that the legacy system handled and that they didn't think about. There are legitimate reasons to rewrite a system in a new language, it's not a a decision that should be taken lightly though. From a business perspective it's also very expensive, as having a team of 5-10 developers rewrite a system that already exists and works can cost millions of dollars, so you should have a really good reason and clear ROI objective when deciding to do this.
- dosethree 6y ago
  Incremental rewrites are just always better. The issue with full rewrites is that you have to rewrite everything - which I suppose sounds good to some engineers, but I dread being forced to spent weeks on parts of the product that are not an issue. Usually you do the rewrite to make things faster, more maintainable, and easier to add features. The issue is, the larger the rewrite, the worse you make all those things in the short-term.
cientifico 6y ago
The problem is not refactor vs rewrite. What most people oversees is the domain knowledge. If the domain knowledge is on the code, you can only refactor. If the domain knowledge is on the team, then rewrite tends to be faster. Most rewrites fails because the team rewriting is not the team that did the initial development.
- twsted 6y ago
  Really well said, this is also my own experience in many projects.
  - Gravityloss 6y ago
    This is one of those statements that seem very obvious in hindsight! Is this common knowledge? I'm hearing this argument so precisely for the first time.
- LukasReschke 6y ago
  > Most rewrites fails because the team rewriting is not the team that did the initial development. Looking at https://github.com/owncloud/core/graphs/contributors https://github.com/owncloud/core/graphs/contributors, most of the initial core contributors contribute now to Nextcloud instead. I am interested in seeing how the rewrite affects end-users. Currently, it seems to be mainly focused on File Sync and I don't see things such as calendar or contacts management. (they totally could appear in the future though) I'd assume that limiting the scope of components, makes a rewrite also easier. Nextcloud for example has a ton of hooks that allow you to write apps to customize the behaviour (want users to sign the ToS before downloading a share? Should be doable etc.). When you leave these out, implementing new things just got a whole lot easier :) (so I guess I am envious on the fact that they got rid of a ton of backwards compatible APIs to maintain :-) ) Disclaimer: Contributed to ownCloud for a few years, then to Nextcloud.
  - butonic 6y ago
    Lukas! Yep, for now, we focus on file sync and share. Personally, I am looking into kopano or etesync to replace calendar and contacts. We already embed kopano konnectd as the OpenID provider so, there are synergies. We do maintain backwards compatibility for the WebDAV, OCS and OCM apis and the clients are all working. The inner hook system of oc 10 obviously is gone, just as well as the internal PHP APIs. Instead we now rely on the CS3 APIs that describe a set of services in a microservice architecture to extend or customize functionality. Something that has always been fragile, because a bug in an oc/nc app could affect all other services. Furthermore, we did not have to start from scratch but contributed to reva, which has been powering CernBox for a few years. It is the reference implementation for the CS3 api. So, we are very much Protocol driven, which makes changing the implementation language possible if needed. And everyone is free to implement his own service replacement if he needs to. The extensive acceptance testsuite will tell you what is not working compared to oc 10 or ocis. For now, we are pretty happy with go and the initial benchmarks. One more thing regarding core developers having moved from oc to nc. The server is just one piece of the puzzle. None, literally, none of the desktop, iOS or Android developers paid by ownCloud moved to the fork. It feels as if they were not even considered important. The sync protocol and the end user experience on his daily driver really is what matters. I am very happy that we as ownCloud finally grabbed the chance to really tackle the file sync and share part with the right tools for the job. Without being pulled in a gazillion of directions. I cannot express my gratitude for the rest of the oc sales and support team that keeps oc 10 well running and bought us the time to actually make this step. Truly exciting times Keep in mind this is still tech preview. There is still a lot of work to do. Helping hands welcome. And yes we need to work on our communication skills... Full disclosure: oc employee no 7 and ocis tech lead here. Originally hired to work on full text search in ownCloud 10. Good old times. Cheers to all the oc and nc devs: it should be possible to implement the internal PHP API of oc/nc using roadrunner. That might allow existing PHP apps to be wrapped in a dedicated microservice. But that is not something we are investing time in. Feel free to ping me on https://talk.owncloud.com https://talk.owncloud.com
ampdepolymerase 6y ago
There is nothing stopping them from offering a fat binary. Not everything has to run on Kubernetes.
cosmotic 6y ago
You suggest a 'modern' JS frontend... Microservices were a 'modern' architecture a few years ago. Whichever reasons lie behind choosing a modern JS frontend would similarly support (or not support) the microservice backend.

jeandejean 6y ago

I'm curious about past examples of failures, can you provide some? Thanks!

bayindirh 6y ago
The thing with Owncloud/Nextcloud is the complexity of the system. When many users are working with the files at the same time, there's a lot of messaging going on in the backbone. If people are working in shared folders, that traffic goes visibly up. Messaging between systems is hard. When things are async, it's harder. When there's async concurrency, it becomes spicy. I'm managing a Nextcloud instance at the office. Even with this relatively mature state, it can bork itself pretty decently. Also, it has separation of responsibilities and a system admin is not an admin the traditional sense so, a lot of things are hidden between logs and other layers. Complicating this further by adding microservices is a brave idea at least. We're going to see what's going to happen. I hope they succeed but it's not a piece of cake.
fundatus 6y ago
Netscape for example: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- rimliu 6y ago
  It is telling when a single example is used for 20+ years.
  - superjan 6y ago
    I know 3 examples from personal experience. One that I worked on myself, that was scrapped before completion. Two other two were finished but they have severely impacted the business. But they are not so useful to share because you would not know about these products. My assumption is that we all know these kind of projects, but the Netscape story is a great reference because it explains why it is a bad idea.
  - mjw1007 6y ago
    And in hindsight it doesn't seem a terribly good example. Gecko was a technical success. On the non-technical side, it isn't at all clear that Netscape-the-company came out worse than it would have done if it had tried to stick with the buggy Netscape 4 rendering engine.
    - ThePhysicist 6y ago
      I'd argue that their attempted rewrite of Firefox in Rust also caused them to actually fall behind in terms of features and speed, which is reflected in the diminishing market share of Firefox. Technologically Rust is an awesome language and a boon to secure software development, I'm just not sure it was such a great idea for Mozilla to put so much energy into this, which could've gone into improving their main product instead.
      - ikt 6y ago
        I'd argue not because I switched from Firefox to Chrome at v1 https://ubuntuforums.org/showthread.php?t=1398220&page=11&p=10129030#post10129030 https://ubuntuforums.org/showthread.php?t=1398220&page=11&p=... Chrome was absolutely faster in web rendering than Firefox and more stable and the UX was cleaner, it made Firefox with its slow buggy performance and awful theme's look like myspace to Chromes facebook. I also remember being very frustrated with Firefox on Ubuntu ~10.04 at the time and when Chrome came along it was exactly what I'd been waiting for. Quantum/Servo/Rust/UI refreshes seems like this was Firefox catching up to Chrome v1 and honestly in 2020 it feels like Firefox has finally caught up significantly. It's still not as stable as Chrome but it's getting there, webrender is a massive leap forward in performance: https://testdrive-archive.azurewebsites.net/Performance/Chalkboard/ https://testdrive-archive.azurewebsites.net/Performance/Chal... That test is now showing at 6.65 seconds down from 45 seconds without it.
ThePhysicist 6y ago
There are many examples where complete rewrites have caused problems and killed or hampered companies, Netscape and Firefox come to mind. Regarding microservices I don't know any OS projects that have failed because of that (because there aren't many OS products that use a microservices architecture), but personally I witnessed many corporate software projects burn and fail when trying to rewrite an "ugly" but functional monolith as a collection of microservices. The thing is that the energy which you invest into rewriting your entire software in a new stack could also be invested into improving your existing stack. LAMP is not dead and actually evolving quite well, so there are definitely ways to improve the stability and speed of a LAMP application without rewriting it in Golang (even Facebook still uses PHP, albeit with some modifications). Having written extensive applications in both scripting languages and Golang I can say that the latter has its advantages but is also slower to develop in and in many respects not as agile as a scripting language like PHP or Python. Doing a rewrite of a popular project with thousands of deploys in the wild will also force you to split your attention between keeping the old system running and building the new one. Since most of your users will want to migrate from one system to the other without losing their existing data and configuration you'll have to ensure that there is a clear migration path that works, which can be quite hard. Also, all external systems that are interacting with existing installations (e.g. via APIs) will also need to be supported by the new system. In the end it might be possible to make it, but in my humble experience I think a complete rewrite is almost never a good idea and the energy you put into it is often better invested in making gradual improvements to your existing codebase. But that's just my 2c of course.
- rimliu 6y ago
  I'd say in your examples there were problems at companies which killed or hampered them and also caused rewrites.
  - ThePhysicist 6y ago
    Probably! From my experience I think the main problem is that developers often don't like to work with "legacy" code, where legacy means anything they didn't write themselves. Also, most developers tend to drastically underestimate the cost of a full rewrite as they don't know all the intricacies of the old system. From the outside most systems seem easy and straightforward, so people think they should be easy to rewrite. During the rewrite people then discover all the little edge cases that the legacy system handled and that they didn't think about. There are legitimate reasons to rewrite a system in a new language, it's not a a decision that should be taken lightly though. From a business perspective it's also very expensive, as having a team of 5-10 developers rewrite a system that already exists and works can cost millions of dollars, so you should have a really good reason and clear ROI objective when deciding to do this.
dosethree 6y ago
Incremental rewrites are just always better. The issue with full rewrites is that you have to rewrite everything - which I suppose sounds good to some engineers, but I dread being forced to spent weeks on parts of the product that are not an issue. Usually you do the rewrite to make things faster, more maintainable, and easier to add features. The issue is, the larger the rewrite, the worse you make all those things in the short-term.

cientifico 6y ago

The problem is not refactor vs rewrite. What most people oversees is the domain knowledge. If the domain knowledge is on the code, you can only refactor. If the domain knowledge is on the team, then rewrite tends to be faster. Most rewrites fails because the team rewriting is not the team that did the initial development.

twsted 6y ago
Really well said, this is also my own experience in many projects.
- Gravityloss 6y ago
  This is one of those statements that seem very obvious in hindsight! Is this common knowledge? I'm hearing this argument so precisely for the first time.
LukasReschke 6y ago
> Most rewrites fails because the team rewriting is not the team that did the initial development. Looking at https://github.com/owncloud/core/graphs/contributors https://github.com/owncloud/core/graphs/contributors, most of the initial core contributors contribute now to Nextcloud instead. I am interested in seeing how the rewrite affects end-users. Currently, it seems to be mainly focused on File Sync and I don't see things such as calendar or contacts management. (they totally could appear in the future though) I'd assume that limiting the scope of components, makes a rewrite also easier. Nextcloud for example has a ton of hooks that allow you to write apps to customize the behaviour (want users to sign the ToS before downloading a share? Should be doable etc.). When you leave these out, implementing new things just got a whole lot easier :) (so I guess I am envious on the fact that they got rid of a ton of backwards compatible APIs to maintain :-) ) Disclaimer: Contributed to ownCloud for a few years, then to Nextcloud.
- butonic 6y ago
  Lukas! Yep, for now, we focus on file sync and share. Personally, I am looking into kopano or etesync to replace calendar and contacts. We already embed kopano konnectd as the OpenID provider so, there are synergies. We do maintain backwards compatibility for the WebDAV, OCS and OCM apis and the clients are all working. The inner hook system of oc 10 obviously is gone, just as well as the internal PHP APIs. Instead we now rely on the CS3 APIs that describe a set of services in a microservice architecture to extend or customize functionality. Something that has always been fragile, because a bug in an oc/nc app could affect all other services. Furthermore, we did not have to start from scratch but contributed to reva, which has been powering CernBox for a few years. It is the reference implementation for the CS3 api. So, we are very much Protocol driven, which makes changing the implementation language possible if needed. And everyone is free to implement his own service replacement if he needs to. The extensive acceptance testsuite will tell you what is not working compared to oc 10 or ocis. For now, we are pretty happy with go and the initial benchmarks. One more thing regarding core developers having moved from oc to nc. The server is just one piece of the puzzle. None, literally, none of the desktop, iOS or Android developers paid by ownCloud moved to the fork. It feels as if they were not even considered important. The sync protocol and the end user experience on his daily driver really is what matters. I am very happy that we as ownCloud finally grabbed the chance to really tackle the file sync and share part with the right tools for the job. Without being pulled in a gazillion of directions. I cannot express my gratitude for the rest of the oc sales and support team that keeps oc 10 well running and bought us the time to actually make this step. Truly exciting times Keep in mind this is still tech preview. There is still a lot of work to do. Helping hands welcome. And yes we need to work on our communication skills... Full disclosure: oc employee no 7 and ocis tech lead here. Originally hired to work on full text search in ownCloud 10. Good old times. Cheers to all the oc and nc devs: it should be possible to implement the internal PHP API of oc/nc using roadrunner. That might allow existing PHP apps to be wrapped in a dedicated microservice. But that is not something we are investing time in. Feel free to ping me on https://talk.owncloud.com https://talk.owncloud.com

ampdepolymerase 6y ago

There is nothing stopping them from offering a fat binary. Not everything has to run on Kubernetes.

cosmotic 6y ago

You suggest a 'modern' JS frontend... Microservices were a 'modern' architecture a few years ago. Whichever reasons lie behind choosing a modern JS frontend would similarly support (or not support) the microservice backend.