pdhborges

Unfortunately I think that the article doesn't make a good case of why this was discarded right off the bat. In particular it is not clear why this wasn't a lift and shift with the NAS storage replaced by S3 and Celery workers placed under an autoscale policy.

Looking at the conclusions the first two are consequences of having on demand compute power while the third one is just surpring (was 70% of the code dedicated to celery infrastructure?).

I think the point of the GP is that all of these application instances are still connected to the DB, doing sub optimal data fetches taxing the database in multiples.

Well that is a pretty tall order. Those languages probably have the most extensive type systems among the languages with significant use. But even so Python's type system has features that some of them don't have: for example Rust doesn't have structural subtyping.

> Also, Python technically has no typing system to speak of so your comment is kind of strange.

Python PEPs define the typing annotations and the typing rules for each annotation. That for me counts as a type system, despite the fact that there is not built in typechecker and you can run programs that you didn't type check.

> Not to mention pattern matching, destructuring and other goodies that improve productivity.

Python has pattern matching now: https://peps.python.org/pep-0636/

How did you reach this conclusion? Both Amazon and Google don't structure their software engineering teams around an 'Architect' title.

I also searched the Google Carrera page for Architect positions and the great majority of them are customer facing roles with very few Architect positions assigned to specialized fields.

You would have to queue one task for each request in the event loop and then await for them both to gain some parallelism in the I/O section of the code.

In my opinion having more tables and more GSIs available won't help you very much if you started with flawed data model (unless you kept making the same design mistakes 256 times). A team that tries to claw back from a flawed table design by pilling up GSIs is just in for a world of pain.

So if you are planing to go with Dynamo: - Read about the data modeling tecniques - Figure out your access patterns - Check if your application and model can withstand the eventual consistency of GSIs - Have a plan to rework your data model if requirements change: Are you going to incrementally rewrite your table? Are you going to export it and bulk load a fixed data model? How much is that going to cost?

Edit: For backend services it would probably put Python around one order of magnitude away from Go in terms of memory usage to serve the same load, enough for teams not to consider switching.

I don't think in 'handling x concurrent requests' terms because I don't even know what that means. Usually I think around thoughout, latency distributions and number of connections that can be kept open (for servers that deal with web sockets).

For example if you have the 4 core computer and you have 4 workers and your requests take around 50ms each you can get to a throughput of 80 requests per second. If the fraction of request time for IO if 50% you can bump your thread count to try to reach 160 request per second. Note that in this case each request consumes 25ms of CPU so you would never be able to get more than 40 requests per second per CPU whether you are using node or python.

- Imagine you have a monolith that mostly talks to the database. You have a primary with multiple read replicas. How are you going to take advantage of millions of async tasks if your IO concurrency ends up being caped at a couple of thousand database connections?

- The second question is: even if you can have a million requests on flight do you really want to have such a large blast radius on a single server?

[1] https://infoweekly.blogspot.com/2009/02/teaching.html

[2] https://inst.eecs.berkeley.edu/~cs172/sp09/

[receive] onlyFastForwards = true

    std::wstring remove_side_spaces(const std::wstring& str) {
        auto begin = std::find_if_not(str.begin(), str.end(), std::iswspace);
        if (begin == str.end()) {
            return std::wstring();
        } else {
            auto end = std::find_if_not(str.rbegin(), str.rend(), std::iswspace);
            return std::wstring(begin, end.base());
        }
    }

I disagree. Real HP software have their computation kernels hand written (or generated) in assembly. As for relying on the smartness of the compiler to take into account all those factors I invite you to recall or read the story of the itanium architecture.