While there are plenty of folks who have reason to push a repatriation narrative, and there will always be examples (Dropbox!), I'll believe it's real when cloud providers like AWS and Google start eating into their considerable margin and begin meaningfully dropping prices again.
This sounds a lot like my daughter (3yo). She likes to play up, but also craves approval from her parents and stern words can be devastating to her.
The best approach we've found is to progressively and predictably escalate our language and tone. Starting with a friendly "now, now" and ending with time out if she hasn't fixed her behavior. At some point along the way she usually recognizes The Voice and course corrects voluntarily without needing to be reprimanded.
OAuth is perfectly valid as a standard for inter-API authentication but it is complicated. You'll also have to figure out separately how your oAuth clients manage the secrets they use to authenticate to the oAuth server to retrieve access tokens, and if encryption as well as authentication between the APIs is important to you, how to manage the keys to do so.
Take a look at https://spiffe.io/ which avoids these concerns focuses specifically for system to system authentication at scale.
While it won't solve for SPA, the SPIFFE project (https://spiffe.io/) aims to deliver short-lived keys and certificates to workloads at runtime to allow them to establish channel authentication (mTLS) and encryption, and to generate & validate JWT tokens for individual message authentication.
Supporting North/South is how they have traditionally been marketed, but not how they are actually used much of the time. Inside enterprise they are often used as an internal "service catalog" and are effectively a shim providing discovery and consistency over a bunch of fairly scoped internal services.
One reason for the explosive interest in service mesh over the last 24 months that this article glosses over is that it's deeply threatening to a range of existing industries, that are now responding.
Most immediately to API gateways (eg. Apigee, Kong, Mulesoft), which provide similar value to SM (in providing centralized control and auditing of an organization's East-West service traffic) but implemented differently. This is why Kong, Apigee, nginx etc. are all shipping service mesh implementations now before their market gets snatched away from them.
Secondly to cloud providers, who hate seeing their customers deploy vendor-agnostic middleware rather than use their proprietary APIs. None of them want to get "Kubernetted" again. Hence Amazon's investment in the very Istio-like "AppMesh" and Microsoft (who already had "Service Fabric") attempt to do an end run around Istio with the "Service Mesh Interface" spec. Both are part of a strategy to ensure if you are running a service mesh the cloud provider doesn't cede control.
Then there's a slew of monitoring vendors who aren't sure if SM is a threat (by providing a bunch of metrics "for free" out of the box) or an opportunity to expand the footprint of their own tools by hooking into SM rather than require folks to deploy their agents everywhere.
Finally there's the multi-billion dollar Software Defined Networking market - who are seeing a lot of their long term growth and value being threatened by these open source projects that are solving at Layer 7 (and with much more application context) what they had been solving for at Layer 3-4. VMWare NSX already have a SM implementation (NSX-SM) that is built on Istio and while I have no idea what Nutanix et al are doing I wouldn't be surprised if they launched something soon.
It will be interesting to see where it all nets out. If Google pulls off the same trick that they did with Kubernetes and creates a genuinely independent project with clean integration points for a wide range of vendors then it could become the open-source Switzerland we need. On the other hand it could just as easily become a vendor-driven tire fire. In a year or so we'll know.
This is great science writing. Straightforward, factual, and with context to help folks put the findings into perspective. It's a refreshing change from the hyperbolic coverage of scientific topics one often finds in more mainstream media.
I'd be curious to know how this compares to Google's (internal ) TrueTime service[1], and if it allows for development of globally consistent but highly available storage systems like Spanner.
If you adopt micro-services in earnest, a challenge you face is how to ensure that the right set of services can communicate (and only communicate with) the right other set of services. In a large organization, it's not unrealistic to have hundreds of services, and not all of them are fully trusted (some may be run by vendors, etc).
What's more, these things are being constantly deployed to a wide variety of environments. Some may be on cloud VMs (or a dynamically scaled cluster of VMs), some on bare metal, some in orchestrators like Kubernetes. Some will run on networks that the organization maintains, some may be maintained by a DC or cloud provider.
Historically the answer to securing this communication has been to use L3 network segmentation with strict rules to decide who can send packets to who. But, particularly in an increasingly heterogenous and dynamic environment it's very difficult to do this reliably and quickly. Networks are also a pretty crude authorization system - it implies that just because you can reach an endpoint that you are authorized to use it, which isn't necessarily true in practice. Some of the other benefits of Istio - like system-wide circuit breaking and flow control are also difficult to do purely at the network layer.
If you're interested in this, I'd encourage you to check out https://spiffe.io/about which has some more detailed thoughts on the limitations of the L3 micro-segmentation approach and how it can be solved.
Recently I've seen a few folks use protobufs within parts of a monolith as a mechanism to enforce a strongly typed interface between components. This helps define a contract between teams without the overhead of a distributed system.
I'm a fan of that book too, and definitely provides some constructive anecdotes.
This said, it's a survey of largely succesful organisations - and focuses in the main on what people did right. This talk was about anti-patterns, that in many cases often led to unsuccessful startups (or at least put unnecessary bumps in the road).
I can completely empathize that it's hard to talk safely about other people's private failures, especially as an investor.
It would be wonderful if these sorts of articles (which efficiently generalize advice based on thousands of data points) could back their assertions up with a few telling case studies. It's often too easy to nod sagely at advice like "don't loose focus" but not actually recognize the pathology in ourselves in our day to day lives.
On regular (non-Managed VM) App Engine, developers are encouraged (but not required) to access services such as Datastore or Mail via App Engine specific APIs. The SDK includes a Development Server that emulates these APIs locally for rapid development.
The Node.js runtime on App Engine Managed VMs encourages you to write against public APIs for Cloud Platform (and other) services - including the public Datastore API, which means your code on Managed VMs is written similarly to how you might write it anywhere else. As such, there's no limit to the potential APIs you might want to emulate.
The gcloud CLI tool does early support for emulating two of the more popular Cloud Platform APIs used by Managed VMs customers, and we hope to add more - you can read more in [1]. In this way you can locally emulate services when writing code that talks to them, independent of the platform you choose to deploy too.
As to builds, your application is re-built at deploy time (not run-time) as a Docker image, cached, and distributed out to new instances as needed. As with all Docker builds it is hermetic and so any code running is the same across all instances for a given version.