-
Notifications
You must be signed in to change notification settings - Fork 1
Open Source as a Service #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
fcad116
to
a25d547
Compare
@martinpitt @thrix @TomasTomecek @major @durandom @emmanuelbernard @gsaslis Interested in reviewing? Here's an introductory blog post about the Open Source Services topic we've talked about. I'm thinking of following it up with more content, perhaps some of the playbook ideas we've already drafted together. But one thing at a time. |
a25d547
to
332002b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice article, thanks!
Yes, that means opening a pull request against a running service | ||
and running that change before it's merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Connecting that to your point above -- the only way that this is feasible is if your own little shard of that SaaS with your PR operates on a cloned subset of the production data. If any random Joe Developer could submit a PR against gitlab that runs on the production data, what trust could you still place in the gitlab Saas? IMHO, it would be "none".
But again, I think having a playground with empty (or cloned data that belongs to you) is actually preferable, as it gives you the possibility of doing thorough, destructive, and risky tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll cover this in follow up articles and playbook. I believe that your statements are just as true of team contributions.
Many teams only merge code once they have gotten it into production. See the GitHub internal contribution process.
But yes, I'm happy leaving this as a controvesial topic to be discussed further.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@martinpitt i think the crucial bit that is mentioned above is that this change would only affect your data / how only you consume the service.
I think of it like this:
many SaaS offer an option to try their "beta" features or become part of their "fast" channel, with latest changes not-yet fully tested on everyone else. Other SaaS A/B test features all the time, so it's not like all the users of the service experience the same service anyway.
Switching to "contributor mode" for an Open Source Service would be very similar to those cases but the features you are beta testing are simply your own.
332002b
to
bffa223
Compare
Thank you @martinpitt for your valuable critique and review. I hope I've addressed the points you raised. One point in particular (about sharding/cloning data) is better covered in a follow up, and is a key example of the areas where we must apply existing known deployment techniques to solve. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this sounds great to me now! I can't resolve my comments above, but please do so (especially if/when others chime in, to keep track of discussions).
After discussing this with others, I firmly believe we have all the techniques we need, | ||
whether canary deployments, load balancing, continuous delivery, | ||
infrastructure as code, and so on. It's been hard to find a single | ||
problem that an existing practice doesn't solve. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not for your article (perhaps), but a thought: Achieving this would also mean that you have full control of the "real" deployment, and constantly exercise and improve its (re)deployment. The importance of that can hardly be over-estimated for a project's/company's long-term resilience.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for bringing this out @stefwalter ! Love it.
I've left some minor edits that I think help readability. I also left some comments that I think help bring more emphasis on "Open Source Services" - so that this endeavor has a nice catchy name that will help us pull more people behind it.
Yes, that means opening a pull request against a running service | ||
and running that change before it's merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@martinpitt i think the crucial bit that is mentioned above is that this change would only affect your data / how only you consume the service.
I think of it like this:
many SaaS offer an option to try their "beta" features or become part of their "fast" channel, with latest changes not-yet fully tested on everyone else. Other SaaS A/B test features all the time, so it's not like all the users of the service experience the same service anyway.
Switching to "contributor mode" for an Open Source Service would be very similar to those cases but the features you are beta testing are simply your own.
Hey @stefwalter , /lgtm . One thing I'd add is to figure out how to capture and open SOPs -- standard operating practices. You're talking about opening access to the components/services and making transparent changes there - that's great but I feel like it's often not about what you run but how you run it - how you operate it. That experience is often encoded in heads of SRE/operational team - debugging and troubleshooting services, actions triggered by monitoring events etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️ it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice! Would be nice to add at least a single picture so it doesn't feel like a wall of text :)
Related: stefwalter/blog#1 Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
Related: stefwalter/blog#1 Signed-off-by: Tomas Tomecek <ttomecek@redhat.com> Co-authored-by: Marcel Hild <mhild@redhat.com>
Co-authored-by: Yorgos Saslis <2420882+gsaslis@users.noreply.github.com>
Co-authored-by: Yorgos Saslis <2420882+gsaslis@users.noreply.github.com>
Thanks for reviews. I've made all the changes, but I agree we could add a couple pictures. I'll work on those. @durandom @martinpitt @gsaslis @TomasTomecek @radekvokal Would you be open to me linking back to this pull request at the bottom of the article as a way of thanking you for your feedback? |
I did not find anything to comment, lgtm |
@stefwalter : Sure! Linking to PRs is very much the spirit of FOSS 😉 |
This is an article describing why and what it means to enable Open Source contributions to a Service.
Sharing the source code to a Service is insufficient. We effectively enable users to contribute to the a running service for it to be Open Source.