3 ms·
> Honestly reading the notes (and not knowing anything about the team) they need less DevOps and more SysAdmin/DBA. Having had problems in the past with Postgr
by jfroma 8y ago
> Honestly reading the notes (and not knowing anything about the team) they need less DevOps and more SysAdmin/DBA.
Having had problems in the past with Postgres and managing their database[1] I wonder why they haven't switch to a Postgres-as-a-service solution like Google Cloud SQL or Amazon RDS. It seems they are even running the site in their own hardware [2].
[1]: https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/ https://about.gitlab.com/2017/02/10/postmortem-of-database-o...
[2]: https://about.gitlab.com/2016/12/11/proposed-server-purchase-for-gitlab-com/ https://about.gitlab.com/2016/12/11/proposed-server-purchase...
- sytse 8y agoGitLab.com is on Azure https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/ https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-t... and in the process of moving to Google. After the move we'll look into Cloud SQL for PostgreSQL.
- edjboston 8y agoGitLab VPE here. We apologize for the site performance degradation today. We do have a dedicated DB team of three people. We also have an open vacancy for the team's manager and and individual contributor. We are in the midst of a move from Azure to GCP. That means more work than usual is going on currently because we're replicating data across infrastructure-as-a-service providers and keeping the site running. This has been the case for a couple months now and it's shouldn't impact site performance. Today's site slowness was unfortunately due to a manual mistake related to a Postgres upgrade task. [2] This article is old. A move to metal never happened, and is not in our future plans. In fact, after we move to GCP we are likely to set up a CloudSQL replica and evaluate it's performance