Dynamodb is better in cases where we want to localize the latency of our regional lambdas.
RDS for everything else like dashboard entity storage etc..
Cloudwatch prints logs, kinesis takes the log to s3 where it's transformed in batches with lambda then data is moved to Redshift.
Redshift for stats/reports.
Converted whole ad network to Serverless.
Used Rust Lambda runtime for CPU intensive tasks.
Using Go for the rest of the Lambdas.
I love Go and Rust and optimizing just one Lambda at a time brought back the programme joy in my life
Used Apex+Terrform to manage whole infra for the ad network.
We managed to deploy Lambda in all AWS regions ensuring minium latency for the ad viewers.
The thing which took over 50 (tech side only) person team, now takes 10 people to run the whole ad network.
Network is doing 20M profit per year/9 billion clicks per day.
It's my greatest achievement so far because we made it from scratch without any investor money.
But one the other side, we'll have to shrink our team size next year as growth opportunity is limited and we want to optimize efficiency further.
Did you mean 9 billion clicks or impressions daily?
50 person team to run an adnetwork on tech side only? I am really curious why did it take that many people before going to Lambdas. We are in the adtech space also and there is a 5 persons team (on-call ops+2 devs) to run our own datacollection, third party data providers, RTB doing half a million QPS and own adservers doing hundreds of millions of impressions daily.
Sounds really interesting, kudos for building a profitable business from scratch. I have no experience with redshift, we mostly use the ELK stack, so Kibana do to all the log analysis. Is redshift significantly better?
So what is the alternative? Maintaining your own infrastructure like we did before "cloud" providers, i.e. your own dedicated servers in managed locations unless you were huge enough to have your own locations? Or just a different cloud provider? It is hard to check if your suggestion is any better since you only say "don't do that", but not what else to do instead...
> unless you were huge enough to have your own locations
Those locations are millions, sometimes hundreds of millions of dollars investments with backup power generators large enough to provide power to a comfortably sized village. So, "large enough to a) need and b) able to afford owning such a location just for your own needs", e.g. Google, Amazon. Even companies like large banks have their servers co-hosted in a separate section but in the location owned by a 3rd party co-hosting provider. To own one you either are one of those providers or you are in the "Google tier". For the purposes of the current context, the linked article, one would even need to have multiple such locations all over the world. I think that qualifies as "huge" (the company owning such infrastructure just to run their own servers, co-hosting firms do it for others).
Then you're screwed I suppose. To do that they'd likely be performing some sort of replay attack, in which case you should be mitigating against this. There's no magic bullet anywhere.
By the way, there are links below the text, here's the one to the HN discussion of 2016: https://news.ycombinator.com/item?id=10885727