moca

Both Google and Microsoft have published their API design guidelines, which are very much RESTful. Both companies have applied their guidelines to broader set of products at very large scale. At least, we have not seen alternatives that would be applicable or scalable to companies at Google or Microsoft scale.

API design is like UI design or car design or clothes design. It is a form of craft, which does take time and skills. API design is for customers to have best experience, it was never meant to save time or work for the designers.

Disclosure: contributor of Google API Design Guide.

This guide has been in use since 2014, including recently launched Cloud Spanner API.

Disclaimer: co-author of the design guide.

The proxy is packaged as a docker image, it can run anywhere docker is supported. For performance and convenience, the proxy and the server typically run next to each other, but that is not required.

Have you considered to use a centralized configuration storage (such as S3 and anything else) with access control and audit trail? That is easier to update configs without restarting all the servers.

If we look at how much technologies have advanced over last decades, the economy produces more than enough output for basic needs, which can be distributed to everyone without much burden.

We can simply offer basic income for everyone, then we can get rid of most special rules, such as food stamps, minimum wage, all kinds of deductibles, flexible spending, childcare. We can tax all incomes at fixed rate and be done with it. All these can be trivially tracked by simple computer system, the only thing needed is identify verification once a year or two.

We would have a much greater society and economy, and avoid the need of "job creation like Walmart".

For consumer applications, you are limited by the ecosystems, such Android or iOS or Windows, so you can't choose kernel anyway.

For cloud applications, what is more important is the system architecture, not the kernel. If we assume docker is the preferred way to deploy an app. We only need very limited features from kernel:

- If I specify the CPU and RAM requirements, the kernel simply allocates them to the container. There is no need for complicated dynamic scheduling and balance.

- Network within the same data center has much lower latency than hard disk (<<1ms vs 10ms). We will be much better of using network storage or database.

- If we assign network address to each container, the kernel can deliver network packets to container, and the container uses its own CPU and RAM to process the network traffic. This will avoid the situation that kernel spend a lot of CPU/RAM to process network traffic for all containers and find the correct way to charge the cost.

If we do all above, there is not much kernel features are needed by cloud applications, as such features will be replaced by cloud services like cloud storage/database. It will make develop and deploy cloud services easier and more productive.

A single disk seek takes a few milliseconds. If you need to do any kind of disk verification, it will take longer than a few milliseconds.

I have seen this kind of problems many times in real life. By start writing design doc and prototype code from very beginning, you demonstrate effort and progress. You most likely get hold of the project and eventually deliver it along with all the incremental complexity during the process.

On the other hand, if you spend 2 months iterate through the requirements and alternative design choices, you are far more likely to come up better design, but your manager (or the entire company) would have no patience to watch you thinking in your head. As the result, I have seen software designs could have been 10x or even 1000x better, but most people prefer to get something out first (this is especially necessary for startups).

Another random comment is LoC per day. I worked at a few large companies. The statistics show the residual code is about 6-16 lines of code per business day per software engineer. A lot of time goes into design, debugging, testing, iterations, redesign, refactoring.

SpaceX would drive the product and Google will be a great partner and investor. It is a good match. If Google drive the product, that would raise a lot of concerns across many governments - like EU - as if they didn't have enough problems already.