It’s great to find a tool that perfectly solves your problem. Rewriting code to swap in a new tool months later when things didn’t pan out? Not so great.

This is especially relevant for tools made by startups. Within a few months they might be out of business or have pivoted to something entirely different. Where does that leave you?

Migration costs can’t be completely avoided. There are many good reasons for this.

1. The way you use a tool matters. The more niche features of a tool you rely on, the harder it’ll generally be to migrate away.
2. Most software isn’t designed to be interchangeable. Tools that conform to a standard spec come closest. But most software isn’t like that.
3. There’s other costs to consider. Even having a standard spec doesn’t remove all migrating costs! PostgreSQL hosted on bare metal will have different performance / durability / cost / maintenance overhead compared to a managed service, with a very different setup process too.

That’s just a few. While migration costs aren’t avoidable, they are visible beforehand. One of our core tenants at LaunchFlow is that users should never feel stuck on our platform. Let’s talk about lock-in and the costs of migrating away from our tool, an infrastructure-from-code library. For an introduction to LaunchFlow, see this post.

Infrastructure Lock-In

LaunchFlow Environments deploy and manage infrastructure in your own cloud account. This means that even if you stop using our service, your infrastructure still works. You can even continue to use our client. This is a big deal! Not owning your infrastructure can mean weeks or months of re-designing and re-provisioning down the line.

We store the connection details for all your resources inside your own cloud. If you ever stop using LaunchFlow, they’ll still be there. Suppose I provisioned and were using a CloudSQLPostgres instance using LaunchFlow:

import launchflow as lf
 
postgres = lf.gcp.CloudSQLPostgres("my-postgres-cluster")

This would create a postgres database hosted on Cloud SQL in my GCP account, and LaunchFlow resources provide a simple method for accessing the underlying resource through a standard client. Using the library, you’d write code like this to interact with your database:

engine = postgres.sqlalchemy_engine()
with engine.connect() as connection:
    ...

Want to completely remove your dependency on our client? It’s easy to get the connection info yourself:

# All connection info is stored in your cloud
with fsspec.open('s3://path/to/connection/info.yaml') as f:
    connection_info = yaml.loads(f.read())
 
engine = sqlalchemy.create_engine(...)
with engine.connect() as connection:
    ...

Framework Lock-In

We aim for LaunchFlow to be more of a library than a framework. We don’t dictate how you should write your code. Instead, we have utilities to integrate with existing frameworks like FastAPI and Django, and always provide easy access to the standard resource clients. This gives you control, and minimizes the code you have to rewrite if you decide to switch away. Say you have the following FastAPI code using LaunchFlow:

import launchflow as lf
from fastapi import FastAPI, Depends
from redis.asyncio import Redis
 
elasticache = lf.aws.ElasticacheRedis('my-redis-cluster')
 
app = FastAPI()
 
@app.get("/{key}")
async def example_redis_usage(
    key: str,
    redis_client: Redis = Depends(elasticache.redis_async),
) -> str:
    return await redis_client.get(key)

Since the code uses the standard Redis clients, no application code needs to change if you stop using LaunchFlow.

Conclusion

Our goal in building LaunchFlow is to enhance the capabilities of our users without constraining them. Send us your thoughts and ideas if you think this can be done better!

You can reach me at michael@launchflow.com or on LinkedIn.