Provider Mode vs Fizz Mode
This guide explains the key differences between Provider Mode and Fizz Mode in Spheron, helping developers choose the right deployment strategy for their applications.
Overview
Spheron offers two distinct deployment modes, each designed for different use cases and requirements:
Provider Mode
- Enterprise-grade infrastructure
- High reliability and stability
- Production-ready environment
- Higher resource availability
- Premium features and capabilities
Fizz Mode
- Consumer-grade distributed network
- Cost-effective solution
- Community-driven infrastructure
- Suitable for testing and development
- Basic feature set
Detailed Comparison
1. Networking Features
Provider Mode
# Example Provider Mode networking configuration
expose:
- port: 3000
as: 80 # Can map to standard HTTP/HTTPS ports
to:
- global: true
accept:
- www.yourapp.com
- Supports ports 80 and 443
- Built-in HTTPS with self-signed certificates
- Subdomain-based access for port 80
- Load balancing capabilities with multiple containers by passing more than one count
- Higher bandwidth allocation
Fizz Mode
# Example Fizz Mode networking configuration
expose:
- port: 8080 # Cannot use ports 80/443
to:
- global: true
- port_range: 8443-8445 # Supports port ranges
port_range_as: 8443-8445
to:
- global: true
- Cannot use ports 80/443
- No built-in HTTPS
- Supports port ranges
- Basic networking features
- Variable bandwidth
- Can use
use_public_port
to expose your service so that container ports can be exposed to ports assigned by Spheron - Can be used to deploy P2P applications and clustering applications
⚠️
When using Fizz Mode, ensure your application doesn’t rely on standard HTTP/HTTPS ports (80/443), as these are not available.
2. Resource Management
Provider Mode
# Example Provider Mode resource configuration
profiles:
compute:
web:
resources:
cpu:
units: 4
memory:
size: 8Gi
storage:
size: 20Gi
gpu: # GPU support available
units: 1
attributes:
vendor:
nvidia:
- model: t4
- High resource limits
- GPU support
- Shared Memory (SHM) support
- Consistent performance
- Resource scaling options
Fizz Mode
# Example Fizz Mode resource configuration
profiles:
compute:
web:
resources:
cpu:
units: 0.5
memory:
size: 1Gi
storage:
size: 1Gi
- Limited resource availability - max 32 units of CPU, 128Gi of memory and 2000Gi of storage
- Variable performance - Can have downtime if fizz node is stopped by the user
- Updating resource in runtime is supported
- Shared Memory (SHM) is not supported
- You can change count to multiple containers in a single deployment
3. Logging and Monitoring
Provider Mode
# Real-time log following
sphnctl deployment logs --lid 123 --follow
# Service-specific logs
sphnctl deployment logs --lid 123 --service web
- Real-time log streaming - you can follow the logs as they are generated
- Advanced filtering options
- Service-specific logging
- Detailed event tracking - you can see all the events happening in your deployment
Fizz Mode
# Startup logs (Fizz-specific feature)
sphnctl deployment logs --lid 123 --startup
# Basic logs
sphnctl deployment logs --lid 123
- Real-time log streaming - you can follow the logs as they are generated
- Service-specific logging
- Detailed event tracking - you can see all the events happening in your deployment
4. Deployment Updates
Provider Mode
- Dynamic resource scaling - you can update the resource in runtime
- Live environment updates - you can update the environment variables in runtime
- Container image updates - you can update the container image in runtime
- Zero-downtime updates - you can update the container image in runtime without downtime
- Secure and more reliable - you can update the container image in runtime without downtime
Fizz Mode
- Dynamic resource scaling - you can update the resource in runtime
- Live environment updates - you can update the environment variables in runtime
- Container image updates - you can update the container image in runtime
Best Practices
When to Use Provider Mode
-
Security Requirements
- HTTPS requirements
- Custom domain needs
- Compliance requirements
-
Resource Intensive Applications
- ML/AI workloads
- Data processing
- GPU requirements
When to Use Fizz Mode
-
Cost-Sensitive Projects
- MVP deployments
- Personal projects
- Learning environments
- Low-traffic applications
-
Distributed Applications
- Edge computing or Edge GPU computing use cases
- P2P applications
- Decentralized services
Troubleshooting Common Issues
Provider Mode Issues
-
Port Conflicts
- Verify port mappings
- Use port 80 or 443 for your service if you want to use subdomain-based access
-
Resource Allocation
- Check scaling configurations
- Verify resource requests
- Can deploy multiple GPUs for a single deployment
-
Deployment Not Available
- Check the Replicas if it is 0 - wait for a few minutes for deployment to pull the image and start the containers, and check again
- You can check the logs for more details using the flag
--follow
to see if there are any errors in the logs if the deployment is not available - You can also check the events using
sphnctl deployment events --lid <lid>
to see if there are any errors in the events like pull image failure, start container failure, etc.
Fizz Mode Issues
-
Connectivity
- Use correct port ranges
- Check if the service is running on the correct port
- Can use
use_public_port
to expose your service so that container ports can be exposed to ports assigned by Spheron - this is useful for P2P applications and clustering applications
-
Performance
- Can deploy consumer-grade services with limited resources
- GPU deployment is limited to 1 GPU per deployment
-
Deployment Not Available
- If you see “Deployment details not available. No response from host.”
- Check startup logs to diagnose the issue:
sphnctl deployment logs --lid <deployment-id> --startup
- Startup logs will show the deployment initialization steps and help identify any problems
Last updated on