Serverless and Vendor Lock-in

Serverless computing is a revolutionizing force in the world of cloud infrastructure. Yet, as with any technological advancement, it brings its set of challenges. One such challenge that often surfaces in discussions is vendor lock-in.

What is Vendor Lock-in?

Vendor lock-in occurs when a company becomes so reliant on a particular vendor's products or services that transitioning to another provider becomes impractical, expensive, or nearly impossible.

Vendor Lock-in and Serverless

When a business fully commits to a single vendor's offerings, it inherently ties its operations to the specific functionalities, pricing models, and limitations of that vendor. This becomes problematic if:

1. The vendor's products no longer align with the company's evolving needs.
2. A more efficient or cost-effective solution emerges in the market.
3. There's a change in the vendor's operational stability or cost structure.

Going serverless, this concern magnifies as the services are tightly integrated. For instance, should a company heavily invest in AWS's DynamoDB, Lambda Functions, S3 Storage, or SNS/SQS, transitioning to a different provider could mean rewriting or rearchitecting significant portions of their infrastructure.

Mitigating Vendor Lock-in

Addressing vendor lock-in doesn't necessarily mean avoiding it altogether. Instead, the focus should be on minimizing its potential impact. Here are some strategies to consider:

Software

A robust architectural approach, such as Clean Architecture, emphasizes abstraction to decouple provider-specific elements.

Designing for distributed and event-driven systems to complement the inherent nature of cloud environments will also assist in future transitions.

I suggest starting every project with the switch (e.g. from AWS Lambda to AWS ECS) in mind, and making sure it can be done with reasonable effort.

Here is an example from a python lambda that uses AWS DynamoDB for persistence.:

# Entity
class StatisticsReport:
    def __init__(self, id: str, title: str, values: list, metadata: dict):
        self.id = id
        self.title = title
        self.values = values
        self.metadata = metadata

# Usecase
class StoreStatisticsReport:
    def __init__(self, repository: StatisticsReportRepositoryInterface):
        self.repository = repository

    def execute(self, report: StatisticsReport) -> None:
        # Check the semantic validity of the report
        self.repository.store(report)

# Adapter (key value store abstraction)
class KeyValueStoreAdapter(StatisticsReportRepositoryInterface):
    def __init__(self, client: KeyValueStoreClientInterface):
        self.client = client

    def store(self, report: StatisticsReport) -> None:
        data = self.convert_to_dict(report)
        self.client.put(data)

    def convert_to_dict(self, report: StatisticsReport) -> dict:
    	return {
            "id": report.id,
            "title": report.title,
            "values": asdict(report.values),
            "metadata": asdict(report.metadata)
        }
        
 # Vendor
 class DynamoDBClient(KeyValueStoreClientInterface):
    def __init__(self, table_name: str):
        self.table_name = table_name
        self.client = boto3.resource('dynamodb')
        self.table = self.client.Table(self.table_name)

    def put(self, data: dict) -> None:
        self.table.put_item(Item=data)

If we change the key value store tech, there are good chances, that we only need to write a new vendor class and update the DI setup and config.

Infrastructure

Using cloud-agnostic Infrastructure as Code (IaC) frameworks/tools can be beneficial, but they come with their own challenges. For instance, these frameworks -besides being third-party tools themselves- might need extra plugins, introducing even more third-party components.

Based on the specifics of a project, sticking to the solution hat is maintained by the vendor (e.g. AWS CDK) or choosing a less agnostic solution like Terraform can be a balanced approach.

Other Types of Lock-ins

Vendor lock-in is just the tip of the iceberg. Companies also need to be wary of:

• Technology lock-in: Over-reliance on a specific technology or tool.
• Version lock-in: Being bound to a particular version of a software or platform, preventing updates.
• Architecture Lock-in: A company might design its systems and workflows around a particular architecture.

I would also suggest to read this great article from Gregor Hohpe on https://martinfowler.com/

Conclusion

The goal isn't necessarily to avoid lock-ins but to manage them effectively. The right balance allows companies to benefit from the speed and advantages offered by vendors like AWS, Azure, or Google Cloud, while also maintaining the flexibility to restructure, if needed, with minimal costs.