Seamlessly build, deploy & manage cloud-native applications.
Jazz addresses gaps and pain points with serverless, particularly for production applications. It is not another FaaS implementation. Rather, it enhances the usability of existing FaaS systems. Jazz has a beautiful UI designed to let developers quickly self-start and focus on code. Its modular design makes it easy to add new integrations:
- Services - Today devs can build functions, APIs and static websites. The template-based system makes it easy to define new ones.
- Deployment Targets - Currently we deploy to AWS (Lambda, API gateway and S3). We plan to support Azure Functions and Docker containers in the near future.
- Features - Services seamlessly integrate features like monitoring (CloudWatch), logging (ElasticSearch), authentication (Cognito) and secret management (KMS, Vault coming soon).
- Deployment & CI/CD - We leverage Serverless Framework and Git/Bitbucket/Jenkins.
Jazz is open-sourced and under active development by T-Mobile's Cloud Center of Excellence.
You can install Jazz in your account using the automated installer.
You can try out public preview version of Jazz by registering with your email address here. You will need a registration code which can be requested by joining slack. Once in slack, go to #jazz-serverless channel to get a working registration code.
For more details, see the Wiki.
If you're interested in submitting a PR, it would be a good idea to set up your editor/IDE to use the following checkers:
- editorconfig so your editor follows the same whitespace/line-ending/indent rules as everyone else.
- flake8 for Python linting
- tflint for Terraform script linting
- foodcritic for Chef script linting
New contributions should consist entirely of Python(2, soon to be 3) code or Terraform scripts. No new shell script code will be accepted, we have too much of it and it's not particularly maintainable. If you want to add a new optional feature (rather than simply bugfix) please chat with the maintainers in Slack before starting, and take a look at the feature-extensions subdirectory for an example of how we currently structure such things.
- Breaking/nontrivial features first go into named feature branches cut from
develop - When/if a feature branch is chosen to be included in the next release, it is merged into
develop - Release testing happens in
develop - When confirmed/vetted,
developis merged intomaster, andmasterbecomes the current release. - Small fixes explicitly intended for the next release can be PRed directly into
developwithout first needing a feature branch.
tl;dr master is always the current release, develop is always the current state of the next release. If you want to contribute a PR, recommend you fork and work in a branch off of develop, then PR against develop. Project owners will move you into a feature branch if they deem it necessary.
Jazz is released under the Apache 2.0 License.