lindydonna

The UI changes take a few days to roll out completely. Even though it's just a label change, we always do slow, safe, rollouts. :)

Product Manager for Cloud Run for Anthos here.

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.

Product Manager for Cloud Run for Anthos here.

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.

Product Manager for Cloud Run for Anthos 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.)

(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.

(Disclosure: I work at Pulumi)

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.

(Disclosure: I work at 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.

(Disclosure: I work at Pulumi.)

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.

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

Also, I tried getting an invite for the Pulumi Slack community and was greeted with "invite_limit_reached".

We're hitting Slack's rate limiting on invites. Please DM your email @PulumiCorp on Twitter and we'll get you added!

(I'm a product manager at Pulumi.)

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?

(I'm a product manager at Pulumi.)

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.

(I'm a product manager on Pulumi.)

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.

Well, she was targeted by GamerGate. Lots of people who were not involved in the original drama were targeted later.

/s/founded/formed

Now, is the rest of the statement true?

If that is true, you should be able to point to articles or statements where game developers advocated censorship.

I've talked to Brianna Wu. I've followed her work. She has never advocated censorship.

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.

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.

I found the talks by Brendan Burns to be very good for a high-level overview.

Plus the ability to do custom containers. For some workloads, may be valuable.

Donna from the Azure Functions team here. I'm demoing this later today.

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".

FYI that while you can solve similar problems with Container Instances and Lambda, the closest offering to Lambda is Azure Functions.

FYI that Azure Functions doesn't have this limitation. Code is stored on your own storage account and you can go as high as you want.

(Disclosure: I'm a product manager on Azure Functions.)

Not quite, the equivalent of AWS Lambda is Azure Functions. This is more like a managed container service.

The equivalent of AWS Lambda is Azure Functions. It does have the same memory limits as AWS (max 1.5 GB per instance), though you can run for up to 10 minutes.

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)

Update: the portal does work if Auth is enabled--the bug was fixed a couple of months ago and we didn't close the issue. See https://github.com/Azure/azure-functions-ux/issues/499

Thanks for the detailed feedback! I think you probably used Functions when it was much newer, and I think we’ve actually addressed all of your issues.

- 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

Have you tried out Azure Functions? It has pretty good features for continuous integration, a CLI where you can run locally, and a really nice monitoring experience. Obviously it's probably not worth migrating an existing project, but it might be useful for future projects. Plus, we have a Serverless Framework plugin.

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.

I've worked at MSFT since 2011, on developer tools and Azure. (My opinions are my own, of course).

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.

It might be a chicken and egg problem, but on Azure Web Apps, Python is much more popular than Ruby. This might be because of Windows vs. Linux, but that's where things are at right now.