How app platform shares its resources

Question

Firstly thank you for all of the great services you provide. Really keen to use more DO but am getting the impression that it’s not quite where I need it to be. I’m keen to be able to create an architecture that’s made up of mostly private services and functions, with selected ones exposed (the gateways), and where as much as possible each service / function can scale independently of the others. With that said, am wondering: When an app on the app platform has various resources assigned to it (internal and external services, functions etc.), do they all share the same resources (IE memory, CPU etc.) available to the app as a whole? If a service is internal inside app platform, is there a way to call it directly from another app inside my DO account? Or is it only accessible by other services inside the same app? If it’s only accessible by other services inside the same app, can I make an external service inside an app “internal” by using a firewall with it to limit traffic from other apps? Are functions a good choice to handle variable workloads? I’d really like something that can handle any amount of traffic, but where the traffic scales up and down a lot. It kind of seems the “120 concurrent requests” limits this ability really. Can functions be made internal?

Bobby · Answer

Hey!

Great to hear about your interest in building an architecture with DigitalOcean’s App Platform and Functions!

I will try to cover your questions in order:

In the DigitalOcean App Platform, resources are not shared across the entire app in the traditional sense where everything operates under a single compute instance. Each component (services, static sites, databases, functions, etc.) you deploy can be configured with its own resources in terms of memory and CPU. This setup allows for individual scaling settings per component, enabling independent scalability. However, the overall resource allocation and scaling behavior will depend on how you configure each component within your app.

2. Internal Service Communication

Internal services within the App Platform are designed to be accessible only by other components within the same app environment. This ensures a level of security and network efficiency for microservices architectures. However, if you need to communicate between different apps within your DigitalOcean account, you would typically expose the necessary endpoints internally,eg.:

https://docs.digitalocean.com/products/app-platform/how-to/manage-internal-routing/

3. Making External Services “Internal”

Currently, the App Platform does not support the direct firewalling of services in the way traditional infrastructure might (like with Droplets or Kubernetes clusters where you can apply network policies or firewall rules at a granular level). The “internal” and “external” designations are more about how services are exposed to the internet. For intra-app communication, you’d use internal services for security and performance benefits. For inter-app communication, you would use the internal routing.

4. Functions for Variable Workloads

Functions are indeed designed to handle variable workloads, scaling automatically to meet demand. The “120 concurrent requests” limit is per function and is meant to ensure fair usage and resource availability. For most use cases, this limit provides a good balance between scalability and cost-efficiency. If your workload requires higher concurrency or you’re experiencing throttling, consider deploying multiple functions or using additional app components like containers or services that can scale horizontally.

5. Internal Functions

As of the time being functions in the DigitalOcean App Platform are primarily designed to be triggered by external HTTP requests or internal events within the app. There isn’t a specific designation for functions as “internal” or “external” in the same way services are categorized.

For more complex architectures, you might also consider the DigitalOCean Managed Kubernetes service:

https://docs.digitalocean.com/products/kubernetes/

Your approach to using mostly private services and selectively exposing external services is sound and aligns with best practices for building scalable, secure applications.

Good luck with your project!

Best,

Bobby