Pick n Pay moves its IT infrastructure to Amazon Web Services

You use local caching, asynchronous loading etc and most people won't notice <200ms response times for the parts you cannot cache.
Local caching is a bit limited on mobile and caching is not enough to remove the effect of high latency. This should be done with a local deploy also, and there will be a difference perceivable to the user in terms of latency. The user will be checking the memory of the apps and will probably remove the ecommerce app that uses the most amount of memory, so local caching must be minimal.
 
I would assume his version of badly is it doesn't use Azure therefore its bad...

Well he is going to be having a bad time with his recent job application to an australian company, the oz companies are very big on aws. Last I saw when I was in oz, majority of businesses use aws over any other provider.

You use local caching, asynchronous loading etc and most people won't notice <200ms response times for the parts you cannot cache.

Well we will know soon enough if it worked or not when the mybb articles (don't) start appearing about longer wait times at the checkout.
 
when it comes to latency for https traffic ,its not going to make or break the solution , as these protocols dont get effected much by slighly higher latency.Realtime protocols such as voice and video are very dependant latency.So in summary having an ecommerce solution local or remote is not a major issue.Obviously best practice is to have the solution hosted as close to home , however if you use the azure CDN product , then its all good.
 
Local caching is a bit limited on mobile and caching is not enough to remove the effect of high latency. This should be done with a local deploy also, and there will be a difference perceivable to the user in terms of latency. The user will be checking the memory of the apps and will probably remove the ecommerce app that uses the most amount of memory, so local caching must be minimal.

By the time the user has seen the home screen and figured out where to navigate next any app has had more than enough time to update inventory, images etc in the background. Images will be in the SA cloudfront cache in any case so thats already local, inventory can be done the same if you just invalidate the cloudfront file when its updated. I dont know why you say local caching is limited as you can do a great deal with the device cache and a decent CDN cache. Navigating the app really shouldn't be any different if your middleware sits in Ireland or SA.
Its only when you add things to the basket, change email address etc where you need to do an instant indication but again if you design your app with that in mind and let the user carry on navigating and just notify them when an asynchronous call returns it doesn't detract from their experience.
 
Well we will know soon enough if it worked or not when the mybb articles (don't) start appearing about longer wait times at the checkout.

If thats the case I will still blame architectuure or implementation thereof over latency.
 
By the time the user has seen the home screen and figured out where to navigate next any app has had more than enough time to update inventory, images etc in the background. Images will be in the SA cloudfront cache in any case so thats already local, inventory can be done the same if you just invalidate the cloudfront file when its updated. I dont know why you say local caching is limited as you can do a great deal with the device cache and a decent CDN cache. Navigating the app really shouldn't be any different if your middleware sits in Ireland or SA.
Its only when you add things to the basket, change email address etc where you need to do an instant indication but again if you design your app with that in mind and let the user carry on navigating and just notify them when an asynchronous call returns it doesn't detract from their experience.
You are talking about mobile native apps, that is not 1st choice today. Think more in terms of a mobile browser app, caching is limited, and products should probably not be cached very long, if ever. PnP is targeting people that mostly don`t have the latest mobiles with lots of memory to burn.
 
I am a cloud architect
:ROFL:

"Cloud Architects" with "certification" in specific provider is a bit like a "financial advisor"
They are a sales person for that company with a fancy title ¯\_(ツ)_/¯

Local caching is a bit limited on mobile and caching is not enough to remove the effect of high latency. This should be done with a local deploy also, and there will be a difference perceivable to the user in terms of latency. The user will be checking the memory of the apps and will probably remove the ecommerce app that uses the most amount of memory, so local caching must be minimal.

AWS SA latency:

Code:
ping ec2.af-south-1.amazonaws.com
PING ec2.af-south-1.amazonaws.com (99.78.136.92): 56 data bytes
64 bytes from 99.78.136.92: icmp_seq=0 ttl=240 time=3.481 ms
64 bytes from 99.78.136.92: icmp_seq=1 ttl=240 time=3.145 ms
64 bytes from 99.78.136.92: icmp_seq=2 ttl=240 time=3.223 ms
64 bytes from 99.78.136.92: icmp_seq=3 ttl=240 time=2.897 ms
64 bytes from 99.78.136.92: icmp_seq=4 ttl=240 time=3.218 ms

Also unlike your multiple callouts, they have 3 data centres here, a single region with 3 availability zones, with redundant power lines, different fault lines, different places around Cape Town, etc.
These are also fully fledged AWS data centres, not colocated like Azure.

There is no doubt about the fact that the AWS data centre in SA is far superior to what the others are offering.
 
You are talking about mobile native apps, that is not 1st choice today. Think more in terms of a mobile browser app, caching is limited, and products should probably not be cached very long, if ever. PnP is targeting people that mostly don`t have the latest mobiles with lots of memory to burn.
Doesn't really matter, mobile web apps can be done in a similar way and the majority of the app will be cached in the local CDN. Products can be cached in the local CDN perfectly fine as well all you need to do is refresh the local CDN if there was an update to the inventory on the server side.
 
:ROFL:

"Cloud Architects" with "certification" in specific provider is a bit like a "financial advisor".
They are a sales person for that company with a fancy title ¯\_(ツ)_/¯



AWS SA latency:

Code:
ping ec2.af-south-1.amazonaws.com
PING ec2.af-south-1.amazonaws.com (99.78.136.92): 56 data bytes
64 bytes from 99.78.136.92: icmp_seq=0 ttl=240 time=3.481 ms
64 bytes from 99.78.136.92: icmp_seq=1 ttl=240 time=3.145 ms
64 bytes from 99.78.136.92: icmp_seq=2 ttl=240 time=3.223 ms
64 bytes from 99.78.136.92: icmp_seq=3 ttl=240 time=2.897 ms
64 bytes from 99.78.136.92: icmp_seq=4 ttl=240 time=3.218 ms

Also unlike your multiple callouts, they have 3 data centres here, a single region with 3 availability zones, with redundant power lines, different fault lines, different places around Cape Town, etc.
These are also fully fledged AWS data centres, not colocated like Azure.

There is no doubt about the fact that the AWS data centre in SA is far superior to what the others are offering.
If you say so almighty lord of AWS.
 
You guys make me laugh. AWS has been in SA for a long time already first only for selected customers but its been open to everyone a few years already.
Besides that performance wise most services really don't have to be in country if you architect things properly.

Yeah considering it was only built just before Covid calling it a few years is a bit of a stretch.

Selected customers only went on the platform early in 2020.
 
Doesn't really matter, mobile web apps can be done in a similar way and the majority of the app will be cached in the local CDN. Products can be cached in the local CDN perfectly fine as well all you need to do is refresh the local CDN if there was an update to the inventory on the server side.
You can not just refresh the local CDN, this does not seem correct as a strategy to reduce the effect of latency and is not feasible to do for ecommerce where product inventory info must be real time.
 
Local caching is a bit limited on mobile and caching is not enough to remove the effect of high latency. This should be done with a local deploy also, and there will be a difference perceivable to the user in terms of latency. The user will be checking the memory of the apps and will probably remove the ecommerce app that uses the most amount of memory, so local caching must be minimal.

You are in for a shock when you find out just how many things are serviced from Ireland that you never noticed the latency on.
 
You are in for a shock when you find out just how many things are serviced from Ireland that you never noticed the latency on.

correct , classic example is ms teams.That app makes connections all over the world.
 
Yeah considering it was only built just before Covid calling it a few years is a bit of a stretch.

Selected customers only went on the platform early in 2020.
The region was open to all customers from 22 April 2020.
However some services like EKS were not yet built out at that point.
Perhaps the reason Clicks, et. al. didn't yet onboard in SA

Since then a significant number of services have been built out.
There are still fewer instance types up for selection than the big regions like us-east-1 and eu-west-1
 
You are in for a shock when you find out just how many things are serviced from Ireland that you never noticed the latency on.
Maybe, maybe not. What I do know is that with these type of systems a snappy experience is of utmost importance, so why run the gauntlet when there are local data centers available?
 
You are talking about mobile native apps, that is not 1st choice today. Think more in terms of a mobile browser app, caching is limited, and products should probably not be cached very long, if ever. PnP is targeting people that mostly don`t have the latest mobiles with lots of memory to burn.

Actually any relatively well designed system these days is platform agnostic and relies heavily on API calls to service the data requests from the front end... so you can push your front end and cached data layer close to the customer and put the heavy lifting in a region that is cheaper to operate in.
 
correct , classic example is ms teams.That app makes connections all over the world.

Yeah I wasn’t even referring to anycast type protocols but rather applications he is already using on his own devices that are only served from Ireland and nowhere else.
 
Actually any relatively well designed system these days is platform agnostic and relies heavily on API calls to service the data requests from the front end... so you can push your front end and cached data layer close to the customer and put the heavy lifting in a region that is cheaper to operate in.
Must +1 this. Static content really should be behind a CDN. Look at romans.co.za, they use Cloudflare and their web-site is absolutely blazing. I'm really impressed by it.
Then hosting your API locally too is an extra bonus but CDN goes so far
 
Must +1 this. Static content really should be behind a CDN. Look at romans.co.za, they use Cloudflare and their web-site is absolutely blazing. I'm really impressed by it.
Then hosting your API locally too is an extra bonus but CDN goes so far

Yeah you could host certain APIs locally to improve the user experience and push a data layer near them to improve user experience... hell with decent message brokering systems these days its not all the difficult to keep consistency within your data layer even with 300 - 800ms latency between certain elements.
 
Top
Sign up to the MyBroadband newsletter
X