lindydonna
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.
This is a great question -- thanks for asking.
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.
The two products actually run on the same underlying infrastructure. And, with the open source JavaScript functions framework, you can have a GCF-like experience on Cloud Run. https://cloud.google.com/functions/docs/functions-framework
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.)
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.
My colleague wrote a blog post with more of the technical motivation: https://medium.com/@lukeh/programming-the-cloud-e795cafffc2b, and there's also this Twitch live-coding video: https://youtu.be/DM8Wd4f1MNA
We're hitting Slack's rate limiting on invites. Please DM your email @PulumiCorp on Twitter and we'll get you added!
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.
Does that help?
> 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.
You can also put the runtime code in a different file, as in this example: https://github.com/lindydonna/velocity-examples/tree/master/...
> 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.
If Terraform works for you, then definitely continue using it. Pulumi is just another option and works well for building libraries and components. I did a rundown of different tools for serverless apps at Velocity SF last week. Slides are here: https://cdn.oreillystatic.com/en/assets/1/event/270/Tooling%... and GitHub samples are here: https://github.com/lindydonna/velocity-examples
There are a ton of tools in this space, all with overlapping functionality, so there tends not to be a clear comparison of tool X vs tool Y.
Now, is the rest of the statement true?
I've talked to Brianna Wu. I've followed her work. She has never advocated censorship.
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.
Interestingly, the FBI got confessions from some of the attackers, and decided not to prosecute. http://www.businessinsider.com/gamergate-fbi-file-2017-2
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.
If you want to learn more, tune in to the Ignite live stream (https://www.microsoft.com/en-us/ignite) at 2:15 EDT for the session "Building innovative apps using the Microsoft Developer Platform".
(Disclosure: I'm a product manager on Azure Functions.)
You can try for free for up to 1 hour (no credit card required!) at https://functions.azure.com/try.
(I'm a product manager on Azure Functions)
- You can create a Function App via ARM/CLI/etc., you can write functions without ever touching the portal. See https://docs.microsoft.com/en-us/azure/azure-functions/funct.... You can also now use Visual Studio to author C# functions: https://docs.microsoft.com/en-us/azure/azure-functions/funct...
- It’s true that Functions is built on App Service, but I see that as an advantage. You get all the great features of Continuous Integration, custom domains, automated deployment, etc.
- Indeed, the portal does not do well when auth is enabled and all routes are protected. The problem is that the portal calls admin APIs that are also protected, so it fails. We now have better error messages for this, and we’re tracking this bug: https://github.com/Azure/azure-functions-ux/issues/499
- The Graph API issue is probably not specific to Functions, but it is a bit easier with the Authentication/Authorization feature. Can you provide more detail?
- You can install npm packages at the "root" of your Function and not reinstall them for each Function, just like a normal Node.js app - it walks the directories.
- Our documentation is much better now, and we even have documentation for all bindings in the portal. We also have much better conceptual docs on bindings, see https://docs.microsoft.com/en-us/azure/azure-functions/funct.... We’d welcome any specific feedback on docs that are missing.
- CI should be faster now, it usually takes about 2-3 minutes for commits to show up. It’s fast enough that I’ve demo’d it.
- You can now run locally and debug using the Azure Functions Core Tools (npm i -g azure-functions-core-tools; func init; func host start). See docs: https://docs.microsoft.com/en-us/azure/azure-functions/funct.... This is something that our users always praise us for. We support C# debugging with Visual Studio and JavaScript debugging with VSCode.
- Logs definitely weren't great. Initially, they always went to table storage, but the ones you see streaming in the portal get written to disk to enable the realtime portal stream - they are only written to disk when you're in the portal, so they are "sometimes" there. The good news is that we've tightly integrated Application Insights, which means logs are easy to find. It's easy to alert on failed functions. You can see perf and metric data all in one place without log parsing. For a demo, go to the 6 minute mark of this video: https://www.youtube.com/watch?v=TgB-fs1hwlw&t=6m
Here's a talk that walks through some of our features: https://www.youtube.com/watch?v=TgB-fs1hwlw&t=18s
Disclosure: I'm a Program Manager on Azure Functions.
When I first joined Microsoft, it was prior to the launch of Win8, and I saw a lot of complacency throughout many parts of the company. I found it frustrating, because I came from an open-source background on the Java stack, and I wanted to see more innovation.
In just a few years, things have changed dramatically, and that is because the market has changed. As others have said on this thread, Windows is no longer the key to Microsoft's business success, it is the ecosystem of products that Microsoft sells.
That is why there have been all of these cultural changes, because the industry has shifted, and there are some really smart leaders at Microsoft (e.g. Scott Guthrie) who realize that we have to change to stay viable.
So, the terrible practices you once saw just don't even make sense anymore. Microsoft is being challenged in every market it operates in, which means that we're forced to innovate. This turns out to be better for everyone, including employees like me. (I came from an academic research background, and I'd never want to work somewhere that was happy with the status quo.)
And yes, the Visual Studio 2015 uninstall takes a really long time. Some installs also take forever. They've made a ton of improvements in the new preview VS 2017.
The reason this wasn't done previously was not that a few engineers couldn't change things (though sometimes that is true), but rather that it was a hard engineering problem. It's easy to think that a big company has infinite resources, but the reality is that you can't build a product with too big of a team (see: Mythical Man Month), so you have to choose what you focus on. If you were to ask most customers, they'd rather have new features than have a better installation experience. That is, until the install experience got in people's way.
I don't work on anything related to the Windows client, so I can't speak to the telemetry, but what you're describing does sound pretty annoying. It is all anonymized (I know this because I'm familiar with the privacy reviews that all code has to go through), but I can see the case for wanting to opt out completely.
Obviously, one post is not going to change your mind (and I'm not looking to do so), but I'd suggest you look at leadership and philosophy changes, not just individuals.