fvbock

thx. i added some more documentation today - should be pretty straight forward: import the lib and replace http.ListenAndServe(TLS) with endless.ListenAndServe(TLS).

this makes firefox more attractive again. ^ ^

kind of amazing to see they had "high server load" problems with the systems already back then :)

and hat-tip to the guys who had the idea and balls to try it in that time!

one would assume thought that that thundering herd would have to go through some kind of queue to avoid resources-starveing/dos-ing yourself...

i hope that the postmortem they promise will shed some light onto the architecture.

i agree.

AZs - according to Amazon, "are distinct locations that are engineered to be insulated from failures in other Availability Zones."

that did not really seem to work.

if you're deployed in one zone and shit hit's the fan: "your fault". if you assume amazon does as advertised and live in several AZ and these go down apparently more or less at the same time: 'amazons fault'...

i read that amazon plans to post a 'postmortem' on this... i'd be really eager to know how AZs are actually designed/sperated. not to be able to point fingers (maybe just a little bit), but to just _know_ where i am deploying stuff to...

the visa part can be (as in many countries - except maybe as eu citizen in another eu country) a bit annoying.

as an engineer (programmer) you either need a degree or (documented) 10 yrs+ of work experience. if ou fulfill that you basically have to stick to the checklist of what to hand in in what form like sticking to an rfc. reason i mention this is that i heard of/from quite a couple of people who did not - going like "i did not have X so i handed in Y which is basically the same...". does not fly...

then you either need a company "sponsoring you' or have proof that you have enough income (ie. several contracts as a freelancer).

in the end it is less scary than many posts on the net make you (made me) think.

> If there's one general thing to say about scaling then that you scale applications, not stacks.

very true! which is why i think it usually is a good idea to analyze how you could split up your application into more or less discrete subsystems/"services". that way it becomes easier to react to bottlenecks in the subsystems instead of having to operate on the whole system.

ideally you design your system like that in the beginning but usually you grow and find out the harder way... step by step.

still there are a couple of things that are "always (about) the same": for example do session mangagement or logging/sitestats usually put quite a bit more write load (INS/UPD/DEL) on a system than other parts of a system.

so if your product grows the write stress these subsystems/functionalities put on a system on the one hand and the read load from other subsystems on the other hand make it hard to optimize your db/storage systems because they have quite contrary I/O needs.

if you have separate subsystems that run as discrete services with their own API it becomes much easier to put out a fire that breaks out due to growth or load spikes.

so to add to the comment by moe: "you scale applications" - and you get into a better position to do so if you design your applications in a way that they are composed of seperate subsystems that communicate via apis.