search

awslabs / amplify-video

An open source Category Plugin for the AWS Amplify-CLI that makes it easy to deploy live and file based streaming video services and integrate them into your Amplify applications.
https://www.npmjs.com/package/amplify-category-video
Apache License 2.0
267 stars 56 forks source link

Transition to CloudFormation #1

Open wizage opened 5 years ago

wizage commented 5 years ago

Is your feature request related to a problem? Please describe. Using Lambda's to deploy Elemental services is only a work around is not maintainable for new feature releases. Transitioning to CloudFormation deployment instead of Lambda deployment will provide more clear deployment and updating of infrastructure.

Describe the solution you'd like To use just CloudFormation to deploy Elemental services instead of using Lambda to deploy the Elemental service.

Additional context Waiting for service team.

smp commented 5 years ago

mediastore launched cloudformtion support: https://aws.amazon.com/about-aws/whats-new/2019/05/aws-elemental-mediastore-now-supports-aws-cloudformation/

wizage commented 4 years ago

Looking over MediaLive and MediaPackage they both have configurations that can be unique.

For MediaLive you can specify the output type, the current templates for the HLS out are: full.json hd.json mobile.json sd.json

Should we move forward with migrating these templates over to the new MediaLive CloudFormation or should we look at refactoring them?

MediaPackage outputs today are dynamically create from gop size, gop per segment, segment per playlist. Should we become more prescriptive with those and follow more of a template approach and allow people to edit the templates themselves instead of some of the variables like gop size.

@smp your thoughts would be great.

smp commented 4 years ago

For MediaLive, I think we should refactor into a single, well documented/understood profile that we think will be "good" for the majority of use-cases and then have a really simple way to customize the resource. This way, we're not getting too deep into the maintenance of each set of profiles.

MediaPackage is a bit more tricky because there's a lot of things users might want to do that we don't expose at all today, which, actually, makes me wonder why we even implement it at all. For instance, is there anything you can do with mediapackage from Amplify Video that separates it from MediaStore? Or are we just allowing it because it's there?

If we want to expose management/config of mediapackage through amplify video, that would be awesome, but we should take that in bite-sized chunks working backwards from user needs. Endpoint Config (multi-drm/protocol/filttering), Harvest Jobs, and VOD all seem like sprints, not just in terms of how to control/config them, but in how we expose them through the CLI.

I wouldn't be mad if we set mediapackage aside until

  1. it has cfn support
  2. it supports a workflow/user story that we're aiming to support
  3. we have a clear way of managing the entire resource directly from the amplify project
wizage commented 3 years ago

Should also work on this #152