Skip to main content

Deployment

Arkitekt aims to be highly costumizable in its deployment strategies, ranging from using Arkitekt on a single machine to deploying it on a cluster, the cloud, or even a hybrid of all. This document aims to give an overview of the different deployment strategies and their advantages and disadvantages. This document is not meant to be a step-by-step guide on how to deploy Arkitekt, but rather a high-level overview of the different strategies. Beginners setting up arkitekt should follow the first steps guide.

General Considerations

Before we dive into the different deployment strategies, we want to give you some general considerations, that you should keep in mind when deploying Arkitekt.

On the production readiness of Arkitekt

Arkitekt is currently in an early stage of development, and we are still working on making it production ready. Right now we can only discourage you from using Arkitekt in a multipe user environment, as we are still working on making it secure and scalable. If you are interested in using Arkitekt in a multiple user environment, please contact us, as we would like to know how you are using Arkitekt. The following considerations are meant to give you an idea of what you should consider when deploying Arkitekt in a multiple user environment.

How many users will use Arkitekt?

The first thing you should consider when deploying Arkitekt is how many users will use Arkitekt. If you are the only user of Arkitekt, you can deploy Arkitekt on a single machine, and you don't need to worry about redundancy or scalability. The same holds true if your team is small, and lets be honest, anything below 20 people. If you have a larger team, or if you want to make Arkitekt available to the public, you should consider deploying Arkitekt on a cluster, or in the cloud, please contact us because we would like to know how you are using Arkitekt.

How much data will be stored in Arkitekt?

Another thing you should consider when deploying Arkitekt is how much data you will store in Arkitekt. Through its reliance on Minio Arkitekt has support for multiple storage providers and you can establish highly involved storage strategies like tiering. Most likely you will want to use a combination of "hot" and "cold" storage, where "hot" storage is fast and expensive, and "cold" storage is slow and cheap. Please refer to the Mikro documentation for more information on how to configure storage for the Mikro service.

How much data will be streamed through Arkitekt?

This is another thing you should consider when deploying Arkitekt. If you are planning to stream a lot of data to and from Arkitekt, you should consider having a fast network connection, and a lot of bandwidth, as well as a lot of fast storage. Our showcases all were possible with a 1Gbit/s connection, but this might not be enough for your use case. The truly mission critical part of the platform is again "minio", as it stores all the data that is streamed through Arkitekt. In rare cases you might be limited by the speed of the API layer, but this is not very likely for smaller team sizes.

How much computational power will be required?

This is another thing you should consider when deploying Arkitekt. While for the most part "computation" is happening on the client side in the Arkitekt Apps, if you are deploying Plugin Apps on the Arkitekt Server (and your underlying docker host), you should consider the computational power required to run these plugins.

On Plugin Apps and GPU Support

Currently we only have limited support for sharing GPUs with Plugin Apps, and we are planning to improve this in the future. Especially with the new Kabinet service, we are planning to provide better support for GPU sharing. If your are interested in running multiple GPU intenstive Plugin Apps on Arkitekt, please make sure that you have enough GPUs available.

Deployment Strategies

Arkitekt was build with the idea in mind that it should be highly customizable in its deployment strategies. This is why we have built Arkitekt in a way that it can be used to maintain Arkitekt from within a python process (development), or as a local deveopment setup (through the CLI), via a GUI installer