Deploy to multiple cloud providers

Wabba · October 16, 2017, 11:52am

Hi,

I have a serverless function that I’d like to deploy to AWS as well as Azure.
My idea was to have a common codebase and then call those from provider-specific handler scripts.
Any suggestions on how to handle the two different serverless.yml files?

Thanks,
Daniel

buggy · October 17, 2017, 2:30am

You’ll need at least three projects. One for each platform with platform specific function handlers and their own serverless.yml. A third one with platform independent business logic. If you’re using Node then I’d implement this as a private NPM package.

You’ll also need an abstraction layer for storage, message queues, etc so that your business logic doesn’t end up with platform specific code in it. I’d try to inject this into your business logic from your platform specific handlers.

Wabba · October 18, 2017, 1:44pm

Hi buggy,

thanks for you reply. I really like the suggestion of using private npm packages for this. As I’ve already set up a local npm server, this will be the way to go.

Still, I think it would be neat if the Serverless CLI had an option to set a specific yml file. This way, a user could keep 2 different configurations in the sam project folder and decide for each deployment which one to use.

bawbgale · January 21, 2019, 12:45am

FYI: There’s a PR in progress to address this as a CLI option.

gurpreet.singh.drish · September 26, 2019, 9:33am

Can you provide link to this pull request ?

diegotremper · March 2, 2020, 2:22pm

I recently had the same question and notice that there some differences how to handle http requests in aws and Google cloud, my solution was create a node wrapper to handle that differences. Take a look: https://github.com/cloudifyjs/restful

jmtt89 · January 15, 2022, 8:43am

github.com/serverless/serverless

Multi provider deployments

opened 11:45AM - 09 Jun 21 UTC

medikoo

enhancement needs feedback cat/design

### Us…e case description In scope of a single service we'd like to be able to setup cloud components which are deployed to multiple providers. Side considerations to keep in mind: - **Modular approach**: Derive from single `serverless` installation, instead switch to model where each construct which is in sope of interest is installed individually, and `serverless` just serves as a core CLI that orchestrates deployments and other CLI commands - **Any and multi region deployments**: - In scope of a single service deploy different components to different regions, also consider use case of deploying same component to multiple regions at once - **Fast development flow**: Ensure fast integration with a cloud, but do not close the door for _offline emulation_ (while it's being promoted as an anti-pattern, users should be able to achieve that if they want to) - **Any provider deployments**: Provide a mean to easily switch given _component_ to be deployed to other provider - **Programmatical API**: Allow to construct components programmatically (IaC). Ensure solid intellisense integration, with attached typings - **Ease of extensibility**: Currently Framework is easly extendable/patchable through integrated plugins systems, this shouldn't change  ### Proposed solution [WIP] _Derives from internal document in which potential solution was discussed by @ac360 @mnapoli @fredericbarthelet @medikoo and @pgrzesik_ _Shares same goal as [`serverless-lift`](https://github.com/getlift/lift) plugin, but with intention to evolve a current implementation of a Serverless Framework CLI into a solution which delivers first-class multi-providers support (so it does not happen via plugin or injected external CLI implementation)_ #### General design and configuration structure New `providers` top level property, in which target cloud vendors with eventual extra configuration should be listed, e.g.: ```yaml providers: aws: type: "aws" ... # additional config netlify: type: "netlify" ... # additional config googleCloud: type: "google-cloud" ... # additional config ``` New `<to-be-named>` top level property, in which cloud components should be listed. Current property name candidates: `constructs` or `components` (let's settle on `components` for now). Components could be high level and low level. High level component may construct needed low level components internally (so they're not mentioned in configuration explicitly), or user may configure low level components to be used by high level components. ```yaml components: # Low level component someFunction: type: function provider: aws ... # additional config # High level component staticWebsite: type: static-website provider: netlify ... # additional config ``` Each listed provider indicates distinct deployment group. For given provider type (e.g. `aws`) multiple providers can be configured. That way multiple Cloudformation stacks could be configured, or CloudFormation deployment, could be accompanied with one made directly through AWS SDK Components may rely on outputs coming from other components. Such cross dependencies influence the providers/components deployment order Atomic deployment (depending on provider configuration) is made either on provider or component level State management (depending on provider configuration) is handled either externally (e.g. CloudFormation case) or internally (direct AWS-SDK case) Each provider type and component type can be constructed programmatically (IaC way). Abstract classes ideally should be published as separate paackage (e.g. `@serverless/core`, `@serverless/base` or similiar). This package should be used as a base when creating specific Providers or Components Each provider and component may expose commands, which can be triggered programmatically or via CLI, to operate directly and just against given provider or component Provider specific command: `sls provider-<command-name> <provider-name> [...options]` e.g. we can deploy just specific provider via `sls provider-deploy netlify` Component specific command: `sls component-<command-name> <component-name> [...options]` e.g. current `sls invoke -f <function-name>` could be represented via `sls component-invoke <function-name>` Aside of that, Framework will provide global CLI commands as `deploy`, `remove`, `info`, `package`, `print` (and others TBD) which will be processed against all configured providers. ##### Community extensions/plugins system Community may introduce their own provider/component implementations by either (1) extending existing providers/components or by (2) creating new ones by extending documented abstractions we will provide. Commands processing is backed by evented lifycycle engine, through which community may hack into process and update existing behaviors in more general manner. ##### Integration with current Framework services CLI will support two service configuration modes exclusively, either one (we use currently) with `provider` top level property setup, or one with `providers`, but with possibility to integrate existing service configuration into multi providers (`providers`) service, by configuring it as one of the providers: ```yaml providers: oldService: type: "legacy" # Current properties of serverless.yml (aside of some core ones) provider: name: "aws" runtime: nodejs14.x functions: fucntionA: handler: index.js ``` Such legacy provider type cannot be accompanied with components New provider & component constructs may access deployment outputs of old provider and may pass their outputs to it (this will also indicate the order - whether legacy deployment is made before new providers, after or maybe in parallel). Legacy provider will support all old Framework commands, they will have to be run against it specifically. So e.g. current `sls invoke <...options>`, after integration could be achieved via `sls provider-invoke oldService <...options>` Theoretically multiple legacy providers could be configured, but it has to be ensured that our internals allow for multiple `Serverless` instances in same process, and success with plugins may vary #### CLI process integration Handling of a new provider and components constructs will happen with a brand new deployment engine, but most of the preliminary steps that happen in a CLI process (like CLI input validation, service configuration resolution), will stay common to old Framework deployements and new multi-provider deployments. To integrate new providers & component constructs handling, we will need to update our processing flow so when it detects Multi Providers configuration it runs Multi Providers engine ##### Pre Multi Providers introduction CLI process flow Processing flow as of v3 (with no Multi Providers support yet) will be significantly improved from state we have currently in v2, and will lay out as follows: _(■ marks handlers which may terminate further processing)_ 1. Local Fallback ■ 1. CLI Triage ■ 1. Essentials 1. Tab completion ■ 1. Graceful FS 1. Uncaught exception 1. CLI input (schema: no service) 1. Version ■ 1. if "no service" command 1. CLI input (schema: AWS service) 1. CLI input validation ■ 1. else 1. Service configuration ■ 1. if no service 1. CLI input (schema: AWS service) 1. CLI input validation ■ 1. else 1. Service configuration body ■ 1. Core configuration properties ■ 1. Dotenv ■ 1. Provider resolution ■ 1. CLI input (schema: service or AWS service) 1. Variables meta 1. Variable parse errors ■ 1. Variables resolution (unfulfilled: opt) 1. Variable resolution errors ■ 1. Plugins initialization ■ 1. CLI input (schema: service or AWS service + extensions) 1. CLI input validation ■ 1. Variables resolution 1. Variable resolution errors ■ 1. Help ■ 1. if service 1. Service command (run through lifecycle engine) 1. else 1. Non-service command ##### CLI process flow with Multi Providers handling Integration of Multi Provider services, will mostly fall down to using Multi Providers engine instead of old Framework engine when Multi Providers service is detected. _Cursive_ indicates processing specific to old Framework provider service **Bold** indicates processing specific to new Multi Providers service 1. Local Fallback ■ 1. CLI Triage ■ 1. Essentials 1. Tab completion ■ 1. Graceful FS 1. Uncaught exception 1. CLI input (schema: no service) 1. Version ■ 1. if "no service" command 1. CLI input (schema: AWS service) 1. CLI input validation ■ 1. else 1. Service configuration ■ 1. if no service 1. CLI input (schema: AWS service) 1. CLI input validation ■ 1. else 1. Service configuration body 1. Core configuration properties ■ 1. Dotenv ■ 1. Provider(s) resolution ■ 1. CLI input (schema: _service or AWS service_ or **Multi providers service**) 1. Dashboard provider credentials resolution 1. Variables meta 1. Variable parse errors ■ 1. Variables resolution (unfulfilled: opt) 1. Variable resolution errors ■ 1. if old provider 1. _Old plugins initialization ■_ 1. else 1. **Multi Providers (providers & components) initialization ■** 1. **New plugins initialization ■** 1. CLI input (schema: _service or AWS service_ or **Multi providers service** + extensions) 1. CLI input validation ■ 1. Variables resolution 1. Variable resolution errors ■ 1. Help ■ 1. if service 1. if old provider 1. _Old service command run (run through old lifecycle engine)_ 1. else 1. **Multi-providers command run (run through new lifecycle engine)** 1. else 1. Non-service command #### Multi providers processing engine When initialized each provider and component should export: - Configuration schema - A list of commands with corresponding lifecycle events map - Lifecycle handlers Command run phase will be just about processing lifecycle engine events in configured order So conceptually very similar to how it works in old engine. New implementation will be about creating a cleaner, simpler, without unrelated attachments, version of lifecycle engine we're working with currently. Processing engine should not be CLI specific in any way. It should expose a natural programmatical API, to be used by CLI process. It probably should be implemented in scope of this repository _Note: That's just general description. Before jumping into implementation, we should in finer detail specify the engine, together with abstractions and first real cases of providers and components_ #### Implementation Roadmap 1. [x] [v3-pre](https://github.com/serverless/serverless/milestone/83) milestone (all steps needed to be done in context of v2, to open the door for v3 release) 1. [ ] [v3](https://github.com/serverless/serverless/milestone/84) release 1. [x] https://github.com/serverless/serverless/issues/1720 Upgrade logging library 1. [ ] https://github.com/serverless/serverless/issues/9290 Improve AWS credentials handling and seclude then from internals 1. [ ] Seclude dashboard provider credentials resolution from internals 1. [ ] Specify in detail Multi Provider abstractions and processing engine 1. [ ] Implement Multi Provider abstractions and processing engine 1. [ ] Integrate Multi Provider engine into CLI

Topic		Replies	Views
Serverless support for deploying on any cloud irrespective of the provider Serverless Framework aws , azure	5	1475	May 8, 2018
Multi cloud Deployment Serverless Framework	0	366	December 24, 2020
Sample http function - cross provider deployment Serverless Framework	0	447	April 6, 2018
Can you use serverless.yml in azure to deploy golang azure functions Serverless Architectures	0	411	March 3, 2021
Serverless deploys full source code of the service for each lambda function Serverless Framework	3	1725	June 25, 2020

Deploy to multiple cloud providers

Related topics