Yes, your understanding is correct, though I can't comment on the price point. Note that there's a free trial of Cloud Run for Anthos available until May 2020.
You can currently use Cloud Run for Anthos with no additional charge beyond GKE until May 2020. After that, you'd need an Anthos subscription to continue using the product.
I agree that it's frustrating that you have to contact sales to sign up. We're working to make this self-serve in the future -- Anthos hasn't been available for very long, and we plan to make substantial improvements here.
GCF provides a different experience where you provide just snippets of code and you don't have to even build a full app. Of course, this has pros and cons. The pros are that it's easier to get started, and the service manages things like language runtimes for you. But, the number of languages is usually limited, and you can't customize the OS packages you're including.
In Cloud Run, you provide an entire container. But, this means you're responsible for the contents of the container, which means you have to roll out updates if there there is a security issue for a language.
This was actually the subject of a talk I did last month at ServerlessConf (containers vs. functions), but unfortunately the video hasn't been posted yet. (It'll be posted at https://acloud.guru/series/serverlessconf-nyc-2019.)
(I'm a product manager on the serverless team at Google Cloud)
The early access was based on a user account being added to an access list. But, I'm not sure why your team member had access without explicitly asking for it.
> I may be wrong, but from what I can tell this is really a souped-up framework for working with clouds. Most of it looks like primitive for immutable infrastructure, so Terraform but as a library. As far as can tell, there's no deployment system, no orchestration etc. -- a "Pulumi app" doesn't know how to deploy itself. Is that accurate?
Not quite. A Pulumi app is always deployed through the Pulumi CLI, which deploys and manages Pulumi programs. Note that most Pulumi code runs at deployment time, not runtime. Instead of specifying resources in a configuration language, you write them in code. The Pulumi CLI turns this code into a declarative plan, and updates your infrastructure when you run `pulumi update`. You may find this doc page helpful: https://pulumi.io/reference/how.html
Docker builds, plus provisioning of a container registry instance (and deploying to it), are handled automatically. This blog post walks through the e2e container scenario (but on AWS, rather than GCP): http://blog.pulumi.com/deploying-production-ready-containers...
> Typically applications aren't self-contained enough that they can, or should, declare all their resources. So presumably then you have to centralize common stuff (e.g. your central Postgres server) in a shared module that all your apps import. Now you get into versioning hell as your app depends on an old version of the "common" module and "pulumi update" tears down your Postgres 10 install and creates a 9.6 install instead. (Presumably it asks first. But still. Versioning has got to be a challenge here.)
This is just one way to architect an app, and it's unlikely to work well for a database, as you say. In this case, you'd likely use a `database.get` call, where you reference an existing database, that may be managed in a different Pulumi program or stack, or even outside of Pulumi.
Yes, Pulumi does mutate resources in place, if the cloud provider supports it. For most resources, it will create a new one (such as a new ECS task), and wait for it to be ready before deleting the old one.
The `pulumi update` command first shows you a preview of the exact resources it will create. Once you've deployed, you can view all your resources on the pulumi.com console, so you know exactly what has happened.
The main upside is that it's just regular code. This is more natural for some folks, but mainly the advantage is that you can build abstractions. So, you can build a component that's built up from lower-level resources in AWS. For example, directly setting up API Gateway requires a specific setup (and can be error-prone), so there's a Pulumi library for that.
Pulumi lets you describe cloud resources using code instead of a config language. It's not like Heroku, it's more like a deployment tool (e.g. Serverless Framework, Terraform, Claudia.js, Chalice, etc).
The difference compared to other deployment tools is that you use regular code, but it's turned into a declarative plan when you run `pulumi update`. So, you get the benefits of a regular programming language, while still following best practices of immutable infrastructure.
> That makes it sound like Pulumi only runs the infrastructure declarations when you run "pulumi update", and that those things don't run when your program runs. That's confusing to me, because your examples (like the thumbnailer) seems to have the program and the declarations in the same file.
This is an optional way to do it, by combining the runtime code and infra code. The runtime code doesn't run when you deploy with "pulumi update," but it is packaged and sent to AWS.
> Is Pulumi stateful, then? If you create resources with "pulumi update", change the declarations without updating, and run "pulumi destroy" or whatever, it will only delete the stuff you created in the first step? (That is what I would expect. I would also expect it to support a dry run mode with a diff showing what operations would be executed.) If so, where is this state stored?
Yes, the state is stored on pulumi.com. The state is list of resource IDs that you provisioned. The Pulumi CLI does indeed have a dry run mode that shows a diff: whenever you run "pulumi update", it first shows a preview.
> the forced censorship of games by those who found them "offensive" or "not inclusive enough".
This is false. No one proposed censorship. They proposed and created new games that were more inclusive. In doing this, they also criticized mainstream games. The narrative of censorship was invented by GamerGate.
And clearly, their version of events was so compelling that others repeat it as fact.
And yet, they performed targeted attacks against a number of prominent women in the games industry, so much that these women had to relocate multiple times for fear of their personal safety.
Just because they didn't have a central organization, doesn't change the fact that it was a movement that caused a lot of damage. In fact, there's a parallel with the Alt-Right.
Many terrorist organizations operate with individual cells who work independently, so that they can't implicate each other. I'd still call that an organization.