Skip to content
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

RFC for mobile app backend stack #170

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Conversation

jflm
Copy link

@jflm jflm commented Apr 11, 2024

No description provided.

Copy link
Contributor

@richardTowers richardTowers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello! Thank you for writing this up - it's great to see what you're thinking.

I've put a few comments inline, so they can be discussed separately as threads.

status_last_reviewed:
---

# Back end stack for GOV.UK App backends
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).


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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Option 2 - Adopt a Ruby-based containerised stack on AWS
### Option 2 - Adopt a Ruby-based containerised stack on AWS

(nit: non-breaking space)


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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

* 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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines 49 to 50
* 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

@kevindew kevindew marked this pull request as draft April 29, 2024 15:04
@kevindew
Copy link
Member

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 🥇


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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Particularly if these backend services have the potential to be leveraged by not just the App.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Particularly if these backend services have the potential to be leveraged by not just the App.

Totally agree, I'm sure both AI and App have some common requirements for such an API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants