Serverless Framework applications are made up of multiple services. A service can be thought of as a project that is based on a single
serverless.yml file. By default, Serverless Framework applications start with a
serverless.yml in the project root.
$ ls function.js serverless.yml
Once your application grows you might find yourself wanting to organize it by splitting your single service into multiple services. Or you might run into a deployment error (like the one below) that forces you to split them up.
Error -------------------------------------------------- The CloudFormation template is invalid: Template format error: Number of resources, 201, is greater than maximum allowed, 200
A common way to organize your multiple services is to create a
services/ directory in your application and adding the various services there.
$ ls services/ groups posts users
Here each service has it’s own
serverless.yml. Meaning you would deploy them by running the
serverless deploy command inside each service directory. In effect, you have multiple projects in the same repository. This type of organization (multiple services in the same repo) is generally referred to as mono-repo.
An alternative strategy is to completely separate the services into their own repositories. This is desirable when you are thinking of having different developers (or teams) manage those services on their own.
Mono-repo apps can add a layer of complexity to your deployment process. Deploying your application involves co-ordinating deployment across multiple services.
Seed deploys all the services in a mono-repo app concurrently.
Seed simplifies this by deploying the entire application as a whole.
Start by adding all the services in your application. The pipeline view of your app gives you a clear overview of the services and the specific builds that are deployed to it.
A deployment to the app will now trigger all the services in the app to be deployed. Seed deploys all the services in a mono-repo app concurrently.
Once you are ready to promote to production, you can pick the service and manually promote it.
Seed also gives you a way to manage the environments across all the services in your app. This is especially useful when you have a large number of services.
The pipeline view of your app is a table where the columns are the various stages in your app. And the rows are the different services.
To get a better sense of this pipeline view let’s click around a bit.
Clicking on a service (row header) for example, gives you a view of the stages (or environments) that apply to the service. It also shows you the past few builds for the respective stages.
Whereas, clicking on a stage (column header) shows you the various services deployed to that stage. It also shows you the builds that are deployed and the resulting deployment.
Finally, the app’s stage allows you to control the settings for all the services in the stage.
In the above example, using a set of custom IAM credentials would mean that all the services deployed to this stage will use this setting.
To drill down further, you click through to a service’s specific stage setting.
In this case, if you set the environment variables; it sets them for the specific stage of this service. And not for all the other services in the stage.
To help you distinguish between the various stages of a service, Seed will highlight this as
$Service-Name > $Stage-Name.
The stages and services in an app allow you to easily control your mono-repo serverless apps in Seed.
If you have any questions or feedback feel free to contact us via email.