moca's comments

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.

Many Google APIs were created before this guide. New APIs published at https://github.com/googleapis follow this guide. Having the same API available via both REST and gRPC is very valuable, as gRPC often provides 10x performance.

Thanks for the comment. The error handling chapter will be published in a few weeks. For now, you can reference https://github.com/googleapis/googleapis/blob/master/google/....

Disclaimer: I am one of the co-authors.

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.

Agree. If you use any SDK built on top of Application Default Credentials library, it should work automatically and transparently across different environments. The complexity is handled by the library.

[0] https://cloud.google.com/docs/authentication

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.

Your statement is incorrect. HTTP/2 essentially sends HTTP requests/responses through a multiplex channel. The semantics is nearly identical to HTTP/1.1. SPDY has approved it in real world for several years, and many major companies adopted SPDY long time ago (like Amazon Kindle).

HTTP/1.1 is nowhere near simple or elegant. The current spec has 6 RFCs, and a real world implementation is totally non-trivial. RFC1945 is HTTP/1.0, which nobody uses it.

Unless someone proposes an acceptable better solution (Microsoft tried), the world needs to decide on something and move on.

> Bandwidth is cheap.

Bandwidth is just one problem. If you use HTTP/1.1 to download large files, you won't have much problem. If you try to design a memcache-like protocol based on HTTP/1.1, the result will be terrible. You simply can't afford to parse text at 100+k QPS and wait for previous request to finish before sending next one. HTTP/2 is not designed to solve bandwidth issue. It is about latency and throughput in real world.

I have used several Xiaomi products (phone, box, MIUI). I can say their product design and quality are very good. Obviously, they copied hardware design from Apple, but they have proved that they can build high quality products at very low prices, and they are selling phones, tablets, TV boxes, real TVs, earphones, routers. Very few companies in the world can achieve it (Google tried it and didn't go anywhere, remember Nexus Q). It is only matter of time Xiaomi to catch up on their original design capability.

For reference, Smartisan T1 had very good product design. It was done by a English teacher founder with less than $20M funding. All it took was to find a good design firm to help out. While I don't like their copycat, but they are very likely to succeed in the long run.

Among major companies, Apple did a better job with supporting old devices. Google Nexus devices become completely out of date after 2 years (too slow to run latest software, and too hard to get hardware repair support). Software wise, Apple could have done a better job as the newer version of iOS is indeed bloated and doesn't run well on old devices. On the other side, Microsoft did great job on supporting Windows XP for over a decade with wide variety of hardwares.

Java tried green thread since day one in 1995, and it never worked out well and was dropped long time ago (around 2000). Go did a good job with its gorountine at certain cost, for example embed Go library is much harder than C library, so Go application is typically a standalone static binary.

It is really great to see Rust drops the mixture of green and native threads, and reduce the runtime to minimum. It will make Rust stand out in many environment that no other languages would work well (besides C).

Since iPhone 4, iPhone design seems going downhill. With the same display size, iPhone 6+ is much bigger and heavier than LG G3. Its quality is so much better than others, especially on camera and battery life.

Today Alibaba has more sales than eBay and Amazon combined. One important factor was Alibaba had enough capital to outrun competitors, considering it offered free service in its early years and how strong Tencent and Baidu were China. Jack Ma paid the cost to ensure the long term success. I wouldn't consider it is a big mistake, and certainly not early (Yahoo deal came at much later time).

iOS apps use fixed layout, so they can't scale up/down with different display sizes. Since iOS only did double density once so far before iPhone 6 Plus, apps are quite easy to handle it. Android has way more variety, which is a pain for app developers.