-
Notifications
You must be signed in to change notification settings - Fork 1
Create primary-cloud-for-web-applications.md #3
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
base: main
Are you sure you want to change the base?
Conversation
| ## Assessment | ||
| Intuitively an organization of our size and complexity should only use **one** cloud. However, since we already are spread accross two clouds and a range of technologies, the best solution becomes somewhat less clear cut. | ||
|
|
||
| Specifically for end-user / high volume web applications, GCP is an appealing platform due to it's robust and secure nature. In addition, having applications that "talk" together in the same cloud is good for tracing, latency 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.
The "robustness" of CloudSQL is still an open point. The A-team project worked better after migrating to Azure than on GCP where the application / CloudSQL-db became unavailable for minutes at a time.
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.
Could this have been a configuration issue? I have not heard of this issue, which might mean that there wasn't any question to anyone that might know how to configure google cloud products.
It that regard I would say between the developers we currently have most actually know Google compared to azure.
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.
https://cloud.google.com/sql/docs/editions-intro
This is new and may be relevant. 99.95% and 99.99% SLA available.
| For specific applications (such as self-service BI), Azure is probably still a better platform whereas for some niche services (like streaming) other platforms (AWS) are more suitable. | ||
|
|
||
| The recommendation for "trial" is to make GCP the "default" cloud for container-based web apps, and work on: | ||
| 1. Developing best practices for monitoring and tracing. |
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.
Does this mean planning to move over our Application Insights setups. I know that Jakub has setup Google Trace for one of our Go APIs. Which could be a start.
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.
Yes. I just changed the recommendation to try both clouds though. So we should set up a .Net project with Google Trace and run a Go project on Azure
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.
StevenMalaihollo
left a comment
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.
Awesome that (somewhat of a) decision has been made.
| The recommendation for "trial" is to make GCP the "default" cloud for container-based web apps, and work on: | ||
| 1. Developing best practices for monitoring and tracing. | ||
| 2. Investigate sharing resources (specifically Redis and Postgresql) on GCP | ||
| 3. Investigate performance concerns with CloudSQL (can we get pgBouncer setup?) |
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.
If we are looking to have a common PG database, it may be worth looking at AlloyDB offering.
For the record: I think this is not a smart idea unless we have a dedicated DB admin. I don't want to be responsible for other peoples performance if I mess up and put a heavy load on the DB.
| 3. GCP-only strategy (for web applications) | ||
| 4. Low-cost hybrid solutions (linode, digital ocean etc.) | ||
|
|
||
| ### Summary |
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.
Did anyone compare the support plans?
| 3. No presence in Norway (yet) | ||
| 4. Poorer monitoring experience | ||
| 5. Need to manage security, costs etc. in multiple clouds (due to corporate applications) | ||
| 6. Much harder to get an overview of resources (discovery) compared to Azure |
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.
One can list all the resources in a project using the Asset Inventory feature available in IAM & Admin.
It looks uglier, but I got the impression that it gives more insights allowing filtering by tons of Resource Types (it shows Docker images, Cloud Run Revisions, Service Account Keys individually)
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 don't have strong opinions about any of the clouds. I found it pretty convenient to use only one cloud and focus on delivering a value to customers.
Personally I like Azure because of monitoring and traceability - Application Insights. Products like Azure Containers Apps, Service Bus, SignalR are pretty easy to use and I didn't have any problem with them.
From my point of view, where I focus more on business side, I'm good to use any cloud. I'm using Terraform with Env0 and it is not so critical what is underneath. I leave the infrastructure part to DevOps(Sec) Team.
But I agree that using two clouds are not an optimal solution.
No description provided.