tfgrid/info_tfgrid
33
3
Fork 0
Code Issues Pull Requests 2 Packages Projects Releases Activity

dy, problems update

Browse Source
This commit is contained in:
Mik-TF
2024-05-11 13:16:16 -04:00
parent a2af5a8038
commit 67c09a80da
12 changed files with 103 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files

89
collections/problems/painkiller/cd_issues_cloud_not_enough.md
View File

@@ -1,71 +1,80 @@
![](img/cloudcomplex.png)
# Do current clouds resolve your problems?
# Do Current Clouds Resolve Your Problems?
This page describe some of the issues you might encounter if your use clouds to fullfil your requirements for your solution.
## high CDN cost = Content Delivery
## High CDN Cost = Content Delivery
- CDN's cost between 20 and 60 on major CDN's from Amazon, Google, ..., after negotiation and willingness to park lots of money and commit per month it mught be certain discount.
- Other specialized CDN's can be around 10 per TB if services from e.g. Europe or US, smaller CDN's are much more expensive.
- Managing these CDN's is expensive and not easy job.
- Managing these CDN's is expensive and not an easy job.
>> this means to service 10m people it would cost about 1 to 2m USD per month just for CDN alone.
>> This means to service 10m people, it would cost about 1 to 2m USD per month just for CDN alone.
## High cost of operations
## High Cost of Operations
- cloud servers
- managing those servers, what if mistakes are made
There are high cost of operations attributed to this type of technology.
## Ability to be shut down on the public cloud
- Cloud servers
- Managing those servers
- What if mistakes are made
- its highly probable that within months there would be attempts to shut down the CDN's or often it happens more softly (give bad service and make your product look bad).
## Ability to Shut Down Servers
## apps typically not ready to scale
There is always the possibility to be shut down on the public cloud
- ...
- there are optimizations which can be done e.g. better indexing, better queries, more optimization strategies e.g. using redis
- more knowledge is required to optimize the app
It's highly probable that within months there would be attempts to shut down the CDN's or often it happens more softly (give bad service and make your product look bad).
## Ability to shutdown the mobile apps
## Can't Scale Apps
- google/apple might chose to shutdown apps
- not easy to know how fast this will go, it might just be overnight
Apps are typically not ready to scale.
- There are optimizations which can be done e.g. better indexing, better queries, more optimization strategies e.g. using redis
- More knowledge is required to optimize the app
## Ability to Shutdown the Mobile Apps
- Google/Apple might chose to shutdown apps
- Not easy to know how fast this will go, it might just be overnight
## GDPR
- are very annoying constraints in e.g. Europe, need to be careful to comply
The GDPR constraints are to be taken into account. They are very annoying constraints in e.g. Europe, need to be careful to comply.
## Legal potential trouble
## Legal Potential Trouble
- its important to have good terms & conditions and think which legal entity will be the counterpart of the T&C
- there will be legal requirements like how to shutdown / recognize bad content
- It's important to have good *Terms & Conditions* (T&C) and think which legal entity will be the counterpart of the T&C
- There will be legal requirements, e.g. shutdown and/or recognize bad content
## Redundancy / Uptime
## Redundancy and Uptime
- is the site redundant, can data be lost?
- what happens if a datacenter goes down?
- or what happens if a DB server crashes?
- what happens if e.g. DB gets corrupted?
- how to make sure people always deserve the service they need
- if it kind of works now, will it work if 10x more people?
- is everything monitored?
- if an issue is detected are there people available 24h/day 7/7 to fix
- do the people who will fix have the right knowledge, where is that knowledge stored
- is the monitoring system itself monitored, very often monitoring by itself will stop working
There are a factor of parameters that need to be taken into account to provide a reliable service.
- Is the site redundant, can data be lost?
- What happens if a datacenter goes down?
- Or what happens if a DB server crashes?
- What happens if e.g. DB gets corrupted?
- How to make sure people always deserve the service they need
- If it kind of works now, will it work if 10x more people?
- Is everything monitored?
- If an issue is detected are there people available 24h/day 7/7 to fix
- Do the people who will fix have the right knowledge, where is that knowledge stored
- Is the monitoring system itself monitored, very often monitoring by itself will stop working
## Performance
- how to see performance is not good enough for customers
- how to make sure we can easily fix it, can be region specific
- how to relocate services?
Performance affect user experience directly and must be dealt with care.
## protect against human error
- mistakes are and will be made this might have huge impact on uptime and if not careful loose data
- truck factor: what happens if someone goes away? can org easily take over and continue
- level of automation & documentation?
- how is version control done
- How to see performance is not good enough for customers
- How to make sure we can easily fix it, can be region specific
- How to relocate services?
## Protect Against Human Error
The system in place must be able to protect against human error. This has to be considered.
- Mistakes are and will be made this might have huge impact on uptime and if not careful loose data
- Truck factor: what happens if someone goes away? Can org easily take over and continue
- Level of automation & documentation?
- How is version control done

54
collections/problems/painkiller/cd_issues_cost.md
View File

@@ -1,53 +1,51 @@
![](img/cdn2.png)
## high CDN cost = Content Delivery
## High CDN Cost = Content Delivery
- CDN's cost between 20 and 60 on major CDN's from Amazon, Google, ..., after negotiation and willingness to park lots of money and commit per month it mught be certain discount.
- CDN's cost between 20 and 60 on major CDN's from Amazon, Google, ..., after negotiation and willingness to park lots of money and commit per month it might be certain discount.
- Other specialized CDN's can be around 10 per TB if services from e.g. Europe or US, smaller CDN's are much more expensive.
- Managing these CDN's is expensive and not easy job.
>> this means to service 10m people it would cost about 1 to 2m USD per month just for CDN alone.
>> This means to service 10m people, it would cost about 1 to 2m USD per month just for CDN alone.
# CDN pricing Amazon
# CDN Pricing Amazon
Remark no fees included for HTTPS requests, but should be ok for volume we are talking about, if app is made in right way.
## US
| Location | Price per TB (USD) |
| ----------- | ------------------ |
| US | 28 |
| Middle East | 56 |
| Africa | 56 |
![](img/amz_us.png)
## CloudFront Price Amazon: Regional Data Transfer Out to Origin (per GB)
= 28 USD per TB in US
| | United States, Mexico, and Canada | Europe, Israel, and Türkiye |  South Africa, Kenya, Nigeria,  and Middle East | South America | Japan | Australia and New Zealand | Hong Kong, Indonesia,  Philippines, Singapore, South Korea, Taiwan, Thailand, Malaysia, and Vietnam | India |
| ----------------- | --------------------------------- | --------------------------- | ----------------------------------------------- | ------------- | ------ | ------------------------- | --------------------------------------------------------------------------------------------------- | ------ |
| All Data Transfer | $0.020 | $0.020 | $0.060 | $0.125 | $0.060 | $0.080 | $0.060 | $0.160 |
## EUR
![](img/amz_eur.png)
## MIDDLE EAST
![](img/amz_middleeast.png)
= 56 USD per TB
## AFRICA
![](img/amz_sa.png)
= 56 USD per TB
References: https://aws.amazon.com/cloudfront/pricing/
## Discounts
- discounts can be negotiated but required serious amounts of pre-financing
- Discounts can be negotiated but required serious amounts of pre-financing
# CDN pricing Google
# CDN Pricing Google
Remark no fees included for HTTPS requests, but should be ok for volume we are talking about, if app is made in right way.
![](img/google_1.png)
| | **< 10 TiB** | **10 TiB-150 TiB** | **150 TiB-500 TiB** | **\> 500 TiB** |
| ------------------------------------------------------------------------------ | ----- | ------------ | ------------------ | ------------------- |
| Asia Pacific<br>(including Hong Kong) | $0.09 | $0.06 | $0.05 | On demand |
| China | $0.20 | $0.17 | $0.16 | On demand |
| Europe | $0.08 | $0.055 | $0.03 | On demand |
| North America<br>(including Hawaii) | $0.08 | $0.055 | $0.03 | On demand |
| Oceania | $0.11 | $0.09 | $0.08 | On demand |
| South America | $0.09 | $0.06 | $0.05 | On demand |
| All other destinations<br>(including Mexico, Central America, and Middle East) | $0.09 | $0.06 | $0.05 | On demand |
![](img/google2.png)
https://cloud.google.com/cdn/pricing
References: https://cloud.google.com/cdn/pricing

12
collections/problems/painkiller/no_pain_killer.md
View File

@@ -1,12 +1,12 @@
![](img/painkillers.png)
# Painkillers are not a solution.
# Painkillers Are Not a Solution
Currently, most develop their digital future by implementing many independent projects which all act as painkillers to their problems. While a painkiller might fix symptoms, it rarely solves the root issue. This happens for content providers, countries, enterprises.
Currently, most develop their digital future by implementing many independent projects which all act as painkillers to their problems. While a painkiller might fix symptoms, it rarely solves the root issue. This happens for content providers, countries, enterprises, etc.
We should stop treating the symptoms it becomes time to resolve the root cause.
We should stop treating the symptoms. It's time to resolve the root cause.
We believe you have the opportunity to leapfrog straight to a solution which is both easier to implement and solves most of its issues all at once.
We believe you have the opportunity to leapfrog straight to a solution which is both easier to implement and solves most of the issues all at once.
This has huge benefits:
@@ -16,7 +16,7 @@ This has huge benefits:
* It is more prepared for the future
* It's greener (such a system will use up to 100 times less energy)
## onion layers
## Onion Layers
![](img/onion_layers.png)
@@ -38,5 +38,5 @@ Now, imagine when hundreds of such models are connectted to one another and exch
The problem here is that individual systems are trying to redo things better, however they are using the same base infrastructure. They simply redefine that base towards a relevant issue. Ths cannot lead to optimal systems since solutions are managed around a single functiion. If multiiple people need to use that function it gets very complicated.
One way to go around this has been to use Enterprise Message Bus: Controlling how models talk to each other by pre-defining the messages exchanged. But this does not solve the problem at the root.
One way to go around this has been to use Enterprise Message Bus: controlling how models talk to each other by pre-defining the messages exchanged. But this does not solve the problem at the root.