...
0
collections/problems/.collection
Normal file
9
collections/problems/internet_infra/cdn_issues.md
Normal file
@@ -0,0 +1,9 @@
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
>> this means to service 10m people it would cost about 1 to 2m USD per month just for CDN alone.
|
32
collections/problems/internet_infra/cdn_pricing_amazon.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# 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
|
||||
|
||||

|
||||
|
||||
= 28 USD per TB in US
|
||||
|
||||
## EUR
|
||||
|
||||

|
||||
|
||||
## MIDDLE EAST
|
||||
|
||||

|
||||
|
||||
= 56 USD per TB
|
||||
|
||||
## AFRICA
|
||||
|
||||

|
||||
|
||||
= 56 USD per TB
|
||||
|
||||
## Discounts
|
||||
|
||||
- discounts can be negotiated but required serious amounts of pre-financing
|
||||
|
||||
|
||||
|
10
collections/problems/internet_infra/cdn_pricing_google.md
Normal file
@@ -0,0 +1,10 @@
|
||||
# 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.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
https://cloud.google.com/cdn/pricing
|
||||
|
67
collections/problems/internet_infra/cloud_issues.md
Normal file
@@ -0,0 +1,67 @@
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
>> this means to service 10m people it would cost about 1 to 2m USD per month just for CDN alone.
|
||||
|
||||
## High cost of operations
|
||||
|
||||
- cloud servers
|
||||
- managing those servers, what if mistakes are made
|
||||
|
||||
## Ability to be shut down on the public cloud
|
||||
|
||||
- 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).
|
||||
|
||||
## apps 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
|
||||
|
||||
## 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
|
||||
|
||||
## Redundancy / 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
|
||||
|
||||
## 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?
|
||||
|
||||
## 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
|
||||
|
||||
|
||||
|
BIN
collections/problems/internet_infra/img/amz_eur.png
Normal file
After Width: | Height: | Size: 434 KiB |
BIN
collections/problems/internet_infra/img/amz_middleeast.png
Normal file
After Width: | Height: | Size: 417 KiB |
BIN
collections/problems/internet_infra/img/amz_sa.png
Normal file
After Width: | Height: | Size: 234 KiB |
BIN
collections/problems/internet_infra/img/amz_us.png
Normal file
After Width: | Height: | Size: 229 KiB |
BIN
collections/problems/internet_infra/img/google2.png
Normal file
After Width: | Height: | Size: 240 KiB |
BIN
collections/problems/internet_infra/img/google_1.png
Normal file
After Width: | Height: | Size: 119 KiB |
BIN
collections/problems/painkiller/img/model.png
Normal file
After Width: | Height: | Size: 42 KiB |
BIN
collections/problems/painkiller/img/onion_layers.png
Normal file
After Width: | Height: | Size: 584 KiB |
BIN
collections/problems/painkiller/img/painkillers.png
Normal file
After Width: | Height: | Size: 512 KiB |
16
collections/problems/painkiller/no_pain_killer.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# Painkillers are not a solution.
|
||||
|
||||

|
||||
|
||||
Currently, most countries 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.
|
||||
|
||||
We believe your country has the opportunity to leapfrog straight to a solution which is both easier to implement and solves most of its issues all at once.
|
||||
|
||||
This has huge benefits:
|
||||
|
||||
* It's much more cost effective
|
||||
* It's easier and more integrated which results in many benefits for the users
|
||||
* It will be safer (think about the cyber pandemic happening right now)
|
||||
* It is more prepared for the future
|
||||
* It's greener (such a system will use up to 100 times less energy)
|
||||
|
25
collections/problems/painkiller/onion_layers.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# onion layers
|
||||
|
||||

|
||||
|
||||
What has IT to do with onions...
|
||||
|
||||
The development of applications in the IT sphere has been using painkiller methods at each layer of model first patterns to go forward.
|
||||
|
||||
## Model First Pattern
|
||||
|
||||

|
||||
|
||||
A model first pattern has a standardised foundation. When there is a problem or a bug, or when changes are required, it is not possble to change the sublayers, so a new layer is created. Making changes in the middle is affecting everyhting else that is on top, therefore, it requires more work. Layers keep being added on top of the base which adds complexity, si the problem is never fixed at the root.
|
||||
|
||||
The model can be seen as a dictionary that keeps on expanding more and more.
|
||||
- More but complex words = Harder to understand
|
||||
- Less but simple words = Easy to understand
|
||||
|
||||
Now, imagine when hundreds of such models are connectted to one another and exchanging information. The more layers each indivdual model has, the heavier it is for its message to get across. The whole system becomes very complex.
|
||||
|
||||
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.
|
||||
|
||||
|
0
collections/problems/problems.md
Normal file
BIN
collections/problems/social_warming/img/africa_young.png
Normal file
After Width: | Height: | Size: 4.3 MiB |
BIN
collections/problems/social_warming/img/social_warming.png
Normal file
After Width: | Height: | Size: 3.4 MiB |
BIN
collections/problems/social_warming/img/toabondance.png
Normal file
After Width: | Height: | Size: 809 KiB |
BIN
collections/problems/social_warming/img/world_behind.png
Normal file
After Width: | Height: | Size: 3.4 MiB |
20
collections/problems/social_warming/social_warming.md
Normal file
@@ -0,0 +1,20 @@
|
||||
|
||||

|
||||
|
||||
## +5 billion people in survival mode
|
||||
|
||||

|
||||
|
||||
## Our Kids define our Future World
|
||||
|
||||

|
||||
|
||||
We are maybe too much focussed on what kind of world we will leave behind, rather than thinking about how we need to raise our kids so that they will treat our world differently.
|
||||
|
||||
|
||||
## Education is everything
|
||||
|
||||

|
||||
|
||||
|
||||
|