Selecting an Architecture

The right architecture for your deployment of Posit Package Manager depends on your team and operational requirements. As you consider architectures, you must understand how Package Manager fits into your existing patterns for deploying and maintaining applications, as well as any operational requirements for redundancy and/or isolation.

Package Manager organizes and centralizes Python and R packages across your team, department, or the entire organization, providing IT control and visibility into package use. Additionally, controls can be put in place to restrict or allow specific packages, based on your organization's policies. Package Manager can also provide an air-gapped source for packages for high-security environments.

Architecture considerations#

Below, we'll cover some of the factors you need to understand in order to choose the right architecture for your team.

Hardware sizing#

Package Manager focuses on storing and organizing packages. For that reason, disk space is the most important consideration for Posit Package Manager as opposed to CPU and RAM. Normally, Package Manager fetches data lazily, however, for air-gapped networks, all data must be downloaded up front, which requires more storage. See the storage requirements for air-gapped environments for more information.

Some good initial resource specs for an environment that is not air-gapped might be:

• Minimum (1 core, 2 GB of RAM, 100 GB disk)
• Recommended (4 core, 16 GB of RAM, 500 GB disk)

The Minimum configuration can support a single small team that is working primarily in Python or R with one configured Package Manager repository. The Recommended configuration can support multiple repositories and can be used by a team or multiple departments.

Load and throughput#

Each client accessing Package Manager could be downloading dozens or hundreds of packages a day. There are also other usage patterns such as an administrator uploading local packages or the server building packages for Git builders. Consider the number of clients and scope of package and repository needs to give an idea of the load and throughput required to support your planned architecture.

Expectation for uptime#

Availability, or uptime, of the service informs architecture decisions and affects the buffer that you build in. It can also determine whether segregating into several nodes is preferable (i.e., deploying across multiple availability zones).

Existing tools, skills, and organizational structures#

A successful deployment of Package Manager requires a team with the right skills and tools to manage it. Organizationally, you may have existing tools and processes in place for managing infrastructure that you can leverage. For example, Package Manager with Kubernetes is managed using Helm. If this tooling is unfamiliar, it’s advised to consider other architectures that are in line with your organization’s expertise and existing processes.

Package Manager architectures#

When you have a clear picture of your team's needs, you can start evaluating the best architecture for your team's Package Manager deployment.

A single Posit Package Manager server is how many teams get started. This architecture is the simplest, without any requirements of external shared storage. If you do not require high availability, just increasing the server size of a single Package Manager server and scaling vertically is a great scaling strategy.

Below we show a matrix that provides a starting framework for thinking about which architecture best fits your needs. It is very likely that your organization has additional criteria that are critical to making this decision. For example, you may have specific software deployment patterns that you need to follow, like always deploying apps in a container.

In general, we recommend selecting the simplest possible architecture that meets your current and near-term needs, then growing the complexity and scale as needed.

FAQ#

Common questions and answers are available in the Architecture Frequently Asked Questions section.