Change Details

= Session= * Track: Deploying and Hosting * Topic: Self-service Stateless Microservices (for APIs) =Description= Copied from: https://phabricator.wikimedia.org/T220212#5209716 > Right now any new service needs to go through a series of steps to get in production, which make sense for long term projects but not for epxeriments or small services that just transform data from one source and are not in the critical path to serve the wikis. For such smaller projects, we could think of creating an ever more streamlined system that our current one, basically allowing people to register lambda services to an API to run in production in a self-service fashion. Such a system would allow much faster experimentation and iteration, but will need to be well defined and scoped. I think the conference would be the perfect place to have a discussion where we can better define the scope of such a project and gather requirements from people that could use it. =Questions to answer and discuss= **Question:** **Significance:** **Question:** **Significance:** = Related Issues = * ... * ... =Pre-reading for all Participants= * [add links here] ---- =Notes document(s)= [link to notes document (gdoc and / or etherpad)] =Notes and Facilitation guidance= https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019/NotesandFacilitation ---- =Session Leader(s)= * [name] * [name] =Session Scribes= * [name] * [name] =Session Facilitator= * [name] =Session Style / Format= * [what type of format will this session be?] ---- **Session Leaders** please: [] Add more details to this task description. [] Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc). [] Outline the plan for discussing this topic at the event. [] Optionally, include what this session will //not// try to solve. [] Update this task with summaries of any pre-event discussions. [] Include ways for people not attending to be involved in discussions before the event and afterwards. ---- Post-event summary: * ... Post-event action items: * ...

= Session= * Track: Deploying and Hosting * Topic: Self-service Stateless Microservices (for APIs) =Description= Right now any new service needs to go through a series of steps to get in production, which make sense for long term projects but not for epxeriments or small services that just transform data from one source and are not in the critical path to serve the wikis. For such smaller projects, we could think of creating an ever more streamlined system that our current one, basically allowing people to register lambda services to an API to run in production in a self-service fashion. Such a system would allow much faster experimentation and iteration, but will need to be well defined and scoped. =Questions to answer and discuss= **Question:** Is there broad interest in such a system? **Significance:** Given engineering such a simplified system requires a sizeable amount of work, it only makes sense if there is widespread interest around the idea. **Question:** What would be the scope of such self-service microservices? ** Significance:** Defining what scope such simplified services could be applied for is fundamental to understanding if we can strike a good balance between stability and soundness of the architecture and speed of development. If we're too strict in what we allow, the system might be seldom used. If we're too liberal, it might create a tower of babel no one has a comprehensive understanding of. **Question:** Which parts of our usual process could be bypassed? **Significance:** While some parts of our current process, like creating a new service request, a load-balanced endpoint, a deployment-chart, a pipeline-based project can probably be removed from the equation without harm, we might still want to have some basic security review of the software, or to have some architectural rubberstamp to the idea. We should discuss which parts of the current process we consider unavoidable even for experiments and small lambda functions. **Question:** What an interface to such a system should look like to the user? **Significance:** We need to understand what the potential users - the developers! - would find attractive as an interface to such a system. Maybe being able to point the system to a git repository and expect it to just work(TM) in a CD fashion? an API to upload files for callbacks? = Related Issues = * ... * ... =Pre-reading for all Participants= * [add links here] ---- =Notes document(s)= [link to notes document (gdoc and / or etherpad)] =Notes and Facilitation guidance= https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019/NotesandFacilitation ---- =Session Leader(s)= * Giuseppe Lavagetto * =Session Scribes= * [name] * [name] =Session Facilitator= * [name] =Session Style / Format= * [what type of format will this session be?] ---- **Session Leaders** please: [x] Add more details to this task description. [] Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc). [x] Outline the plan for discussing this topic at the event. [] Optionally, include what this session will //not// try to solve. [x] Update this task with summaries of any pre-event discussions. [] Include ways for people not attending to be involved in discussions before the event and afterwards. ---- Post-event summary: * ... Post-event action items: * ...

= Session= * Track: Deploying and Hosting * Topic: Self-service Stateless Microservices (for APIs) =Description= Copied from: https://phabricator.wikimedia.org/T220212#5209716 > Right now any new service needs to go through a series of steps to get in production, which make sense for long term projects but not for epxeriments or small services that just transform data from one source and are not in the critical path to serve the wikis. For such smaller projects, we could think of creating an ever more streamlined system that our current one, basically allowing people to register lambda services to an API to run in production in a self-service fashion. Such a system would allow much faster experimentation and iteration, but will need to be well defined and scoped. I think the conference would be the perfect place to have a discussion where we can better define the scope of such a project and gather requirements from people that could use itbut will need to be well defined and scoped. =Questions to answer and discuss= **Question:** Is there broad interest in such a system? **Significance:** Given engineering such a simplified system requires a sizeable amount of work, it only makes sense if there is widespread interest around the idea. **Question:** What would be the scope of such self-service microservices? ** Significance:** Defining what scope such simplified services could be applied for is fundamental to understanding if we can strike a good balance between stability and soundness of the architecture and speed of development. If we're too strict in what we allow, the system might be seldom used. If we're too liberal, it might create a tower of babel no one has a comprehensive understanding of. **Question:** Which parts of our usual process could be bypassed? **Significance:** While some parts of our current process, like creating a new service request, a load-balanced endpoint, a deployment-chart, a pipeline-based project can probably be removed from the equation without harm, we might still want to have some basic security review of the software, or to have some architectural rubberstamp to the idea. We should discuss which parts of the current process we consider unavoidable even for experiments and small lambda functions. **Question:** What an interface to such a system should look like to the user? **Significance:** We need to understand what the potential users - the developers! - would find attractive as an interface to such a system. Maybe being able to point the system to a git repository and expect it to just work(TM) in a CD fashion? an API to upload files for callbacks? = Related Issues = * ... * ... =Pre-reading for all Participants= * [add links here] ---- =Notes document(s)= [link to notes document (gdoc and / or etherpad)] =Notes and Facilitation guidance= https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019/NotesandFacilitation ---- =Session Leader(s)= * [name]* Giuseppe Lavagetto * [name] =Session Scribes= * [name] * [name] =Session Facilitator= * [name] =Session Style / Format= * [what type of format will this session be?] ---- **Session Leaders** please: [x] Add more details to this task description. [] Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc). [x] Outline the plan for discussing this topic at the event. [] Optionally, include what this session will //not// try to solve. [x] Update this task with summaries of any pre-event discussions. [] Include ways for people not attending to be involved in discussions before the event and afterwards. ---- Post-event summary: * ... Post-event action items: * ...