Make serverless the default for yarn start / yarn es

[flash1293]

As serverless is on track to become an important target for development efforts, development should mostly happen in the serverless context unless there is a particular reason to work on a stateful-only feature:

• Serverless is released on a faster cadence, so not testing in serverless and missing a bug means it will be visible to users much quicker as there isn't an implicit "dev testing" period
• Serverless is more limited than stateful, which means it's easy to miss issues on serverless when only working on stateful

To address this, I'm proposing one of these two adjustments:

• yarn start and yarn es will start the serverless version - as a solution type needs to be picked, running yarn start will print Error, please specify environment, e.g. yarn start --serverless=oblt or yarn start --stateful
• There is a config file that specifies which solution type should be used (e.g. via an env variable). If yarn start is started without a specified solution, the user is prompted to pick one, which is persisted for the next time (under the assumption that most engineers will tend to work with the same solution most of the time)

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[jbudz]

cc @elastic/appex-sharedux @elastic/kibana-core any thoughts?

[TinaHeiligers]

@flash1293 While I see the benefit to elastic devs, we cannot ignore the dev community as a whole.

How much impact would changing the default behavior affect developers from outside of Elastic?

As an alternative, could we recommend setting an alias to the start script, or perhaps introducing a new startup yarn method that defaults to serverless instead?

[flash1293]

Thanks for raising this point @TinaHeiligers

How much impact would changing the default behavior affect developers from outside of Elastic?

They would try to run the dev server as usual and see an explanatory error message that mentions how to run the "old" thing.

As an alternative, could we recommend setting an alias to the start script, or perhaps introducing a new startup yarn method that defaults to serverless instead?

The yarn start --serverless=oblt is already there, but IMHO the power of this really is the default behavior to nudge devs towards using it. As a side note, are we collecting telemetry on these dev tools? Just to get an idea of where we are right now and how much communication / default changing we need to do.

It's really about the goal of having devs perceiving serverless as the default, everything is just a means to that end.

[pgayvallet]

any thoughts?

I'm personally against it:

IHMO, we already have the tooling / commands in place to run serverless, and by defaulting the "standard" command so that it runs serverless instead of traditional, we're breaking the default behavior for any non-internal developer (that can't run serverless locally given it requires internal ES images), and also sending a strong message that this repository is more about our internal serverless solution than the traditional ES.

If the issue is that our developers are not testing properly against serverless / not running serverless mode locally, I feel like it's more an educational issue than a tooling one, maybe?