Embracing a Hybrid Approach for Scaling Serverless DevOps

We’ve spent a good deal of time over the last few serverless DevOps articles discussing pain points, automation, benefits, and best practices. Even armed with this information, you may still be facing a few challenges:

• Deploying many microservices
• Deployments that are tightly coupled
• Managing a growing serverless footprint
• Scaling your serverless DevOps automations and processes
• Onboarding new serverless applications into your DevOps process

If you don’t recognize these challenges, you will very likely encounter them in the future as serverless deployments increase and DevOps processes are pressed to evolve.

While DevOps gives you management over serverless, it can become a challenge and seem unmanageable.

There are several approaches to addressing this issue, and we discuss the three most common techniques here. Each has its pros and cons, but we find that at least today, one outshines the others as the most manageable of the methods.

3 Techniques Commonly Used for DevOps in a Large Serverless Environment

Technique #1: Add to Infrastructure as Code (IaC)

Technique Description: For each new serverless service you create, you add the service and related items to a centralized IaC file.

Good For: This technique allows you to manage your entire serverless footprint in one place and is easy to onboard new serverless applications/services.

Improvement Area: Adding to your IaC complicates deploying single services or updates to your microservices because it couples all of your serverless services together. It also results in a very large IaC file with 1000s or 10,000s lines of configuration, making granular control difficult and more challenging to search through and manage. There are also inherent limitations with AWS CloudFormation, for example, where the maximum number of resources you can provision through CloudFormation is 500.

Technique #2: Replication

Technique Description: For each new deployment or serverless service, CI/CD pipelines, IaC, and other components are replicated.

Good For: This technique is useful if you need to customize deployments for each service or application.

Improvement Area: The number of services you need to keep track of will grow at the same rate as your serverless footprint. It can become unmanageable very quickly.

Technique #3: Hybrid

Technique Description: Combine both replication and addition to your IaC to logically replicate your CI/CD components based on a logical separation of your serverless services.

For example, let’s say you have a system made up of a gateway, a core, and three connectors. Each of those components is made up of 10 serverless services. In this scenario, using the hybrid model, you would create five different CI/CD pipelines. Each CI/CD pipeline would have its own IaC file governing each component’s 10 serverless services. Together, the five individual components and pipelines make up the parts of the system, and each can be controlled and deployed individually.

Good For: This technique supports customizing deployments and reducing management overhead. Your DevOps management will not grow at the same rate as your serverless footprint.

Improvement Area: This technique will need to be reviewed and improved as your serverless environment expands, but even that work can be minimized with excellent documentation and application inventories. Additionally, grouping based on your applications and systems will allow you to govern them more efficiently within your organization.

In truth, there are few established best practices for scaling and managing DevOps in a sizeable serverless environment… yet. However, the hybrid approach is the one that we recommend, and we’re not alone. AWS also suggests hybrid DevOps management for large serverless footprints. The hybrid strategy makes the most sense in practice to balance a growing serverless footprint with the governance required to be successful with serverless implementations.

The Hybrid Approach in Practice

To get started with a hybrid strategy, split your systems and applications into logical components so that you can couple each part of the system together for DevOps and CI/CD. A practical goal would be for an overall ratio of 10:1 when comparing the number of serverless services to DevOps processes. Just make sure not to force it simply to reach that number. Use common sense when coupling your like components together.

For example, an Amazon API with three resources could have a separate AWS Lambda to handle each of the three resources on the API. In this example, you would couple the API Gateway and three Lambdas into a single CI/CD pipeline, giving you a serverless to DevOps ratio of 4 to 1.

Another example might be a Lambda that receives messages from SQS, transforms messages, persists them into DynamoDB, and sends a message to an SNS topic for subscribers to receive the event. In this case, you’d couple the single Lambda, one SQS queue, one DynamoDB table, and one SNS topic into one CI/CD pipeline. This is another 4 to 1 ratio, but it makes sense given the components and use case.

In the end, DevOps is the most valuable process you can use in a serverless environment — even a growing one. DevOps is crucial to your success with serverless technology. Preventing your DevOps management from getting out of hand, however, requires some thinking and planning. The upfront work and planning to scale your DevOps processes combined with solid documentation and inventories will keep DevOps manageable and productive in your serverless environment.

If you’re struggling with how to organize your applications and components for a hybrid DevOps management strategy, or you just have questions about it, give Big Compass a call. We’d be happy to review your processes and use our experience in serverless DevOps to help you simplify your DevOps management.