Skip to main content

No project description provided

Project description


A library to support development of enterprise Serverless applications.

Serverless computing allows you to build and run applications without expending time and effort managing a server. Code is executed and billed only when called. Whilst this model provides many advantages such as horizontal scalability and reduced operational costs it creates it's own set of drawbacks such as debugging, testing and packaging.

There are numerous articles detailing the advantages and disadvantages of serverless architectures. It's worth considering all the salient points before starting down the serverless path however, in general, the zero configuration horizontal scalability and cost efficiencies are the most significant driving factors. The architecture described here helps to mitigate the disadvantages whilst magnifying the advantages.

As with any architecture there is no one size fits all solution, however, I've seen the following pattern implemented successfully in both Java and Python across multiple domains. I believe it provides a reasonable amount of flexibility whilst being sufficiently structured to help developers rapidly implement clean code. One of the guiding principles of this pattern is to overcome one of the most significant issues with Serverless - the difficulty of debugging and testing Serverless ready code in a local environment.

The key design points and the basis for this architecture are as follows:

  • Lambdas are grouped into functional areas. Each group contains multiple lambdas with different handlers for each function. This is to allow related lambdas to share common ode more easily and to simplify packaging and application structure.
  • It should always be possible to execute and debug the lambda code locally.
  • The configuration for each environment is packaged with each lambda. Which configuration file to use is specified by an environment variable which is specified at deployment time.
  • The code to package and deploy each of the lambdas lives with the runtime code
  • One click deployment to new environments should be trivial, and the concept of infrastructure as code should be maintained at all times.
  • Dependency injection is used to allow alternative services to be injected into lambdas depending on where they are running.

The proposed architecture is designed to fulfill these high level goals whilst maintaining a flexibility which should allow future extension and resilience to changing project requirements.

Push to PyPi:

python bdist_wheel python -m twine upload lambdabase-0.x-py2-none-any.whl

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Files for lambdabase, version 0.6
Filename, size File type Python version Upload date Hashes
Filename, size lambdabase-0.6-py2-none-any.whl (25.5 kB) File type Wheel Python version py2 Upload date Hashes View
Filename, size lambdabase-0.6.tar.gz (15.5 kB) File type Source Python version None Upload date Hashes View

Supported by

AWS AWS Cloud computing Datadog Datadog Monitoring DigiCert DigiCert EV certificate Facebook / Instagram Facebook / Instagram PSF Sponsor Fastly Fastly CDN Google Google Object Storage and Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Salesforce Salesforce PSF Sponsor Sentry Sentry Error logging StatusPage StatusPage Status page