News for hackers. Stuff that matters.
Re:Should that be a microservice? Factors to keep in mind by cperciva on Saturday April 20, 2019 @09:31PM (#19710015)
I'll add another: Is it independently reusable?

Even if you aren't going to use it for something else, separating some of your code and releasing it as open source is a great way to get more people to test it -- and find bugs before they affect you in production.

Re:Should that be a microservice? Factors to keep in mind by clintonb on Saturday April 20, 2019 @09:47PM (#19710075)
This depends on what you are releasing, and how much support you’re willing to offer to the community. For example, the microservices and libraries I worked on at edX were used by the Open edX community, but rarely at the scale at which edX uses them. The community offered new features, but edX did much of the big fixing because we had more extensive knowledge and use of the software.
Re:Should that be a microservice? Factors to keep in mind by mooreds on Sunday April 21, 2019 @02:57AM (#19710879)
Is this a microservices issue or a scale issue in general? Seems like any open source tool that had users that operated at different scales would run into this issue, no matter the architecture, but I don't know what I am missing.
Re:Should that be a microservice? Factors to keep in mind by clintonb on Sunday April 21, 2019 @11:54AM (#19712639)
Project scale and scope. edX does most of its development in public repos. Not all of the features and functionality are used by every open source user. The scale of edX’s user base is so much larger than others’ that edX finds issues well before other users. Also, by the time a formal Open edX release is announced, edX has run the code for weeks or months.