Rule 3: We believe that mixing business logic with configuration is a sub-optimal tradeoff
Developing complex AI-infused applications is hard enough but when you are also forced to set up and configure all the services you need to bring them to life, it becomes a drag on your Time-To-Value (TTV). We’ve worked with and listened to companies large and small and when you do this, common themes emerge. AI Developers don’t care for the most part about all the knobs and dials of cloud infrastructure and if they do, it is very late in the high-volume ramping phase. Forcing AI app developers to conflate their business logic, and its logical boundaries, with configuration and deployment concerns due to premature factorization into microservice components or functions just seems like a really bad tradeoff. Unfortunately, there have not been many options. In this blog, we will dream about how you can solve this problem and discuss what is missing to turn that dream to reality. When shipping velocity is at risk, a new solution needs to emerge. Let’s dive in.
How do you not mix business logic with configuration?
Developers should create at a high level of abstraction, one that they are comfortable with and one that comes naturally to them. Additionally, it should be the job of the cloud platform and AI runtime to ensure that both MVP and production are a success. The connection between the two should be nothing harder than a big red “deploy button.”
Instead, the AI Developer is forced into picking parts of the tech stack and setting them up, almost on day one. “Thank you for signing up for MyCSP. What availability zone do you want to set up you system in?” From there, it only gets worse. Developers will then need to set up their Identity and Access Management (IAM), Virtual Private Cloud (VPC), Networking, Database as a Service (DBaaS), Load Balancers, Container Orchestration (e.g., Kubernetes), Serverless Computing (e.g., AWS Lambda), and more. Every one of these services is fraught with configuration mistakes that can impact usability, performance, and even security.
Alternatively, AI Developers either aren’t able to - or are precluded from - cloud configuration in their organization, so create what amounts to an initial experiment that shows positive results but without being able to connect business logic to infrastructure peculiarities. They have to wait on MLEng or MLOps teams to deploy ‘for real’ - again slowing TTV or even dead-ending many promising results as they disappear into the black-hole of tickets the ops teams are chasing. By the time that MVP makes it to Production, the world has moved on, and even if still relevant, the original business logic behind the application may not translate to Production setups and value is lost again.
The proper solution needs to find the right mix of abstraction, likely higher than Platform as a Service (PaaS) and combined with a AI Runtime that runs, operates, and maintains all the proper services need to today’s AI-infused application. This allows experiments and MVPs to demonstrate real world value sooner, while not requiring explicit, premature technology choices to limit results.
What would it look like to not mix them at all?
Today, let’s say your RAG application needs a vector database. The developer should be able to leverage this in their code with a simple call from Python, Node, or other and not have to worry about cluster management, disk space, memory utilization, software versions, certificates, network latencies and more. The configuration management of such a system is already a full time job and is likely not a core competency of the AI Developer or their mission.
We’ve seen glimpses of this in other spaces. Heroku was known for making app development simple. Streamlit (acquired by Snowflake) was loved for its simple “deploy button”. However, in the AI space no clear winner has emerged. There are places to get a model hosted, too many to count actually. There are even services to get a Vector Database as a service API. Unfortunately, these are small cogs in the overall work needed to be done and many of the existing solutions are still targeted at software programmers exposing most of the configuration many are trying to get away from.
The proper platform would likely need both a very high level of abstraction, say Python or Node, and it would be combined with an application level set of holistic services including state stores (vector databases, SQL services, object store services) and on-demand compute services without needing to think about how to containerize app code or configure network and security configuration.
What is the right solution for the AI Developer?
Seaplane’s core focus since our inception has been on delivering modern apps globally. With the addition of our Python SDK and AI-infused runtime, we've opened up a new realm for AI creators to tap into the power of pain-free, global edge-cloud deployment. Our aim has always been to keep things at a high-level, an application-oriented vibe, ensuring that as many folks as possible can build and run things. Our abstraction level is much higher than your typical PaaS without compromising any functionality – that's always been our approach!
Can I build a RAG application? Page of PythonCan I build a complex batch application on 1 million records? Page of PythonCan I build a complex LLM Recommendation Engine? Page of Python.
In order to build any AI-infused application, just write a page of Python, type “seaplane deploy” and you are in production everywhere in the world, today.
Get Access Now!
Seaplane is where AI-infused applications take flight in 2024 so join us for this ride by signing up below. We are currently in Beta so make sure to sign up to secure your place in line and we’ll get to you as fast as we can.
Bring Your Apps to the World