DeployHub is a sharing platform for microservices and other components used by developers working in the new serverless architecture. It supports Lambda by treating a Lambda Function as a component associated to a software application, versions that configuration, and deploys it to AWS.
When you add a sharing, packaging, and configuration versioning tool to your process, you create a single source of truth about your Lambda Functions and their changes overtime. In addition, you unleash the power of your Lambda Functions by sharing them. Our software makes it easier for others to find your reusable Lambda Functions using DeployHub’s Domain Driven Design.
For AWS users, Lambda is a critical computing service that executes Lambda Functions, or code, based on an event. Its primary job is to manage the computing resources needed by that function for that event. It determines the computing resources based on configurations associated to the Function. Software developers create Lambda Functions by writing code with Lambda specifications that allow it to execute the code. Once ready, the code is zipped and copied to AWS Lambda. Each Function has a laundry list of configurations that tell Lambda how to interact with the Functions for those event triggers. In essence, your code is only a part of the Lambda Function, the other part are the specifications themselves. Your code and specifications will no doubt change over time.
Lambda Functions and DeployHub
DeployHub treats your Lambda Function like any standard component. A DeployHub Component has some basic parameters. First, a Component is consumed by an Application. Applications are a collection of Components. Applications are a logical view of the monolithic equivalent. Second, Components have configuration attributes. Each version of your Lambda Function will have a set of attributes or specifications that are then tracked and versioned. A change to a specification creates a new version of the Lambda Function. And lastly, a Component has pre and post actions that are executed prior to a deployment. In a Pre- Action, DeployHub performs the activities to retrieve your code from an external repository like GitHub, zips it up, and applies the configurations specifications. A Post-Action moves the Lambda Function to AWS, or if it is a DB function, to the AWS DynamoDB table.
Steps for Lambda Functions
The following steps are common when using DeployHub to update AWS
- You define a Component to DeployHub indicating which source code repository the code should be pulled from and what Domain it should be associated to. Domains organize your Lambda Functions making them easy to find and share.
- You define your Components Attributes. These are the Lambda specifications for your Lambda Function.
- You define a Lambda Pre-Action that zips your code and pulls the Component’s Attributes as command line parameters.
- The Post Action then executes an AWS command line that deploys the zip file to Lambda passing the Attributes as command parameters.
Note: DeployHub Credentials can be used for authentication and associated to AWS.
Versioning the Configuration and Deploying Changes
For every change you make in your Function’s code, specifications or pre/post actions, a new version of the Component is created, which in turn creates a new version of the Application. DeployHub tracks these versions of the Components to the Application, and only deploys the Functions that have changed, but continues to track a logical view of your new monolithic equivalent.
Continuous Delivery and Lambda Functions
DeployHub can be called by your favorite CI/CD engine such as Jenkins or CircleCI. Once called by your CI/CD engine, DeployHub takes over the process of preparing, tracking, and versioning your Lambda Function.
DeployHub simplifies the management of Lambda Functions by organizing them into Domains for easy sharing, associating them to applications, versioning their configurations, and releasing them to AWS. It can be called by your CI/CD process allowing you to support a pipeline process for your Lambda Functions. DeployHub tracks application versions to versions of your Lambda Functions building a single source of truth for easy rollback, rollforward, or even version jumping.
- A Microservice Service Catalog for Incident Response
- Domain Driven Design Catalog to Tame Microservice Sprawl
- Microservice Architecture and Your Logical Application
- Microservice Configuration Management
- Continuous Deployment and DevOps at Scale
- Register for DeployHub Team
- Reverse Proxy Setup for SaaS Deployments
- DeployHub Team User Guide
- The Hipster Store Tutorial
Ortelius Open Source Project
All Continuous Delivery and DevOps Blogs
- Continuous Deployment Blogs
- Understanding a Microservice Pipeline
- Microservice Continuous Integration – Where’s the Build?
- Working with Helm for your Microservices Releases
- Kubernetes Pipeline Challenges
- Managing Embedded Configurations
- Questions and Answers on managing a K8s Pipeline
- Running Safe Blue / Green Deployments
- The DeployHub Jenkins Plug-in
- Setting Up the Jenkins Plug-in
- The DeployHub CircleCI Orb
- Creating a Continuous Feedback Loop
- Release Agents – the Enemy of Continuous Deployments
- DeployHubs Release Architecture
- Why we need Application Packages for CD
- Agentless Deployments with DeployHub’s Engine
- Version Jumps and Tracking
- Microservice Configuration Management
- Database Updates in Your Continuous Delivery Process
- Database DevOps and DeployHub