lindydonna
Joined 10 years ago
Karma
61
Submissions
35
Member since
Mar 31
I'm a Product Manager at @PulumiCorp. I'm @lindydonna on Twitter.
View on Hacker NewsRecent submissions
Comment · 7 years ago
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. :)
Comment · 7 years ago
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.
Comment · 7 years ago
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.
Comment · 7 years ago
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.)
Comment · 7 years ago
(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.
Comment · 8 years ago
(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.
Comment · 8 years ago
(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.
Comment · 8 years ago
(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.
Comment · 8 years ago
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
Comment · 8 years ago
> 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!
Comment · 8 years ago
(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?
Comment · 8 years ago
(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.
Comment · 8 years ago
(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.
Comment · 8 years ago
Well, she was targeted by GamerGate. Lots of people who were not involved in the original drama were targeted later.
Comment · 8 years ago
/s/founded/formed
Now, is the rest of the statement true?