Instances, stages, IDs...

[austencollins]

In this early stage, components don't use their stage or anything else when naming resources. This can results in collisions.

We also want to enable people to easily spin up separate instances of their Components, across stages, or previews of features within a single stage (like Netlify).

This issue suggests we should use instanceId's like previous versions of components and auto-add these to all resource names. If we use instanceIds, we do not need to add stage names to resources. By using instanceIds, we can create multiple instances of infrastructure, even on the same account, within the same stage, for previewing and sharing with teammates.

Now, is the time to do this. The initial Components we write must showcase best practices.

[eahefnawy]

Using instanceIds would make it hard to reuse existing resources though. We'd be again stuck with the idea that each project would own resources, and other projects would create their own from scratch.

[pmuens]

We'd be again stuck with the idea that each project would own resources, and other projects would create their own from scratch.

Not sure if I'm following here. Can you provide an example for this?

I really liked the auto-generated instance ids we had in our first component implementation. Using those via Variables was a very convenient way to e.g. auto-generate non-colliding bucket names.

Name collisions is a big problems right now. Instance ids could resolve this.

[eahefnawy]

right now if you already have a lambda named serverless in your account, that you want to "include" in your new components project, you'd just use the AwsLambda component and provide it with the serverless name, in this case, the component will detect that it already exists and will not create a new one, you can then manage it via the framework.

Having unique IDs that are hardcoded in the code will make that hard.

[austencollins]

@eahefnawy and I spoke about this recently.

What came out of the conversation was that we both believe in the stageless future. Meaning, developers should be able to provision infinite instances of the infrastructure for both long-term uses (e.g. a development copy, a QA copy, a production copy) and short-term uses (quick preview versions for testing, reviewing, feedback, like Netlify offers).

We decided that perhaps we get rid of stages, since they imply phases of a process (e.g. dev, qa, prod) and replace them with instances.

In this world, instances could be stages, or anything really. For example:

instance: dev instance: prod instance: ua891 instance: iA103

It might look something like this:

name: myApp
instance: dev

or

$ serverless -i prod
$ serverless -i 1jfa9

This also makes it so the instance IS the ID. No need to create a separate one.

[austencollins]

instanceName??? instanceId

Instance ID is the same as stage: dev, qa, prod.

Instance IDs SHOULD always added to resources, etc.

Instance ID MUST be no longer than 8 characters ua91j9K3

Instance ID MUST contain only alphanumeric characters.

Component name and Instance IDs look like this: myComponent-ua91j9K3

Component names and Instance IDs SHOULD be prefixed to resource names, like this: myComponent-ua91j9K3-userCreate or myComponent-prod-usersDb

serverless.yml

serverless.js

Multiple instances of the same child component

What to do about child components that have multiple instances? instanceAlias?

[eahefnawy]

hmm why do we need to add the component name myComponent to the resource name? 🤔

Also, how does this impact the name property we usually pass to components? Does this naming convention only applies if we don't specify a name property? (ie. default naming pattern)

[austencollins]

@pmuens Would you like to take this on and write up a proposal for this?

Some areas to cover are:

What can we do to help people indicate which resources are for which Component and instance?

@eahefnawy had some questions above as to why include myComponent. I did this because resources can often have the same names across applications as well as the same instances.

For example a create function in the instance prod

create-prod seems like it will run into collisions.

serverless.yml

How is the instance declared when using YAML experience? Likely via CLI or a config option like we do alerady via stage?

serverless.js

How is the instance declared when deploying a javascript component? CLI only?

Multiple instances of the same child component

The word "instance" is currently being used to indicate multiple instances of the same child components. We're talking about the same thing, but in a different circumstance. A bit of weirdness here..

[barrysteyn]

Any updates on this? It is at the top of our wish list right now. In fact, we are unable to make a dev instance, and since there is a lack of plugins, cannot work locally (the old serverless plugins allows us to run offline, both with agw and dynamodb offline). The result is that we would need to use the prod instance to test things!

[eahefnawy]

@barrysteyn you probably already seen this, but there's a solution to this here:

https://github.com/serverless/components/issues/481#issuecomment-543364153

[eahefnawy]

Will keep this open as we are still thinking of ways to make this better

[RichardWright]

@eahefnawy hi! Just to confirm from this thread, local development isn't currently possible (due to the lack of offline plugins) and that the preferred workflow is to test against a deployed environment?