RFC for mobile app backend stack #170
Conversation
| status_last_reviewed: | ||
| --- | ||
|
|
||
| # Back end stack for GOV.UK App backends |
There was a problem hiding this comment.
This decision feels like it's heavily entwined with GDS' future organisation design, which is itself somewhat unknown.
There are two paths I think we could follow - be consistent with GOV.UK, or be consistent with DI. If the app ends up close to DI in terms of organisation structure, then it will have been better to have been consistent with DI. If the app ends up close to GOV.UK, then it will have been better to have been consistent with GOV.UK.
A big reason for that is support - who will be supporting this infrastructure? Does it need 24x7 support? If there's any intent to piggy back on GOV.UK or DI's existing arrangements, then being consistent with the infrastructure those teams currently use will be a requirement (or at the very least, highly desirable).
rfc-170-mobile-app-backend-stack.md
Outdated
|
|
||
| The principal drawback of this option is that it is not currently a stack that is widely used and understood across GOV.UK, so would require some upskilling - particularly in terms of infrastructure management and use of AWS SAM (although we could look at an alternative to this like CDK). | ||
|
|
||
| ### Option 2 - Adopt a Ruby-based containerised stack on AWS |
There was a problem hiding this comment.
| ### Option 2 - Adopt a Ruby-based containerised stack on AWS | |
| ### Option 2 - Adopt a Ruby-based containerised stack on AWS |
(nit: non-breaking space)
rfc-170-mobile-app-backend-stack.md
Outdated
|
|
||
| The principal drawback of this option is that it is not currently a stack that is widely used and understood across GOV.UK, so would require some upskilling - particularly in terms of infrastructure management and use of AWS SAM (although we could look at an alternative to this like CDK). | ||
|
|
||
| ### Option 2 - Adopt a Ruby-based containerised stack on AWS |
There was a problem hiding this comment.
I think option 2 should be more of a "consistent with GOV.UK" option. If we were going down that route, I would suggest using our existing kubernetes clusters, and building services using Ruby on Rails with Postgres for persistence. I wouldn't expect you to have new AWS accounts or really any new infrastructure in this model at all - we'd just reuse what we have.
There was a problem hiding this comment.
Just to second this - we've already build a platform to run containerised applications in GOV.UK, which I'd thought we can just reuse. If there are concerns as to why we couldn't, it be good to understand what those are.
rfc-170-mobile-app-backend-stack.md
Outdated
| * Aligns with the DI tech stack so that the entire mobile back end estate could be maintained by a single group of people | ||
| * Benefit from existing DI infrastructure for NFRs like monitoring / logging / alerting | ||
|
|
||
| The principal drawback of this option is that it is not currently a stack that is widely used and understood across GOV.UK, so would require some upskilling - particularly in terms of infrastructure management and use of AWS SAM (although we could look at an alternative to this like CDK). |
There was a problem hiding this comment.
I think there are quite a few more details we'll need to work out if we go down this route:
- Which AWS organisation would our accounts be part of? Would we follow DI's approach with control tower / many AWS accounts per service?
- What would the deployment pipeline look like? Would we have integration / staging / production environments like GOV.UK? Or would we have a different pattern like DI presumably have?
- Which team would be responsible for infrastructure support? This could be the app team itself, or DI's infrastructure team, or GOV.UK's platform engineering team. The latter would probably not be able to support such a divergent estate
rfc-170-mobile-app-backend-stack.md
Outdated
| * Aligns with the DI tech stack so that the entire mobile back end estate could be maintained by a single group of people | ||
| * Benefit from existing DI infrastructure for NFRs like monitoring / logging / alerting |
There was a problem hiding this comment.
These are advantages if the app sits close to DI in the org structure. They're disadvantages if it sits close to GOV.UK (e.g. if GOV.UK needed to support this infrastructure using its existing structures, it would be problematic to have to learn new monitoring / logging tools)
|
I understand there's a bunch of discussions going on about what exactly needs to be established before taking this further as an RFC so I've switched this to a draft for now. Feel free to open it switch it back when it's ready, there's a list of the steps to take to push out an RFC in the README that can be followed so that people see it and comment: https://github.com/alphagov/govuk-rfcs?tab=readme-ov-file#process Thanks so much for putting it together - it's great to have a recording of these big decisions 🥇 |
rfc-170-mobile-app-backend-stack.md
Outdated
|
|
||
| The following are key considerations we need to take into account: | ||
|
|
||
| 1. There is a single app, and it would be most straightforward to integrate the app with a single back end. This means we only need a single set of configuration rather than multiple settings for different features. Additionally, we can centralise concerns like logging, monitoring and alerting. |
There was a problem hiding this comment.
I'm interested why exactly we'd need a single backend. Have we considered the implications DI running a separate API endpoint for the identity functionality, vs separate APIs for (potentially hosted in GOV.UK's platform) for other features.
Clearly defined APIs for these supporting services could facilitate the decoupling of these backend services from the App team. I'm concerned that without this separation, the scope of the App team's responsibilities could expand excessively, encompassing a wide range of backend APIs. These could instead be developed and maintained independently by other relevant teams.
There was a problem hiding this comment.
Particularly if these backend services have the potential to be leveraged by not just the App.
No description provided.