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:
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
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:
1. Resource Sharing in the App Platform
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.:
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:
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