Serverless Systems
Serverless systems run specific workloads on managed functions and services rather than a server you provision and patch, billed for what runs rather than what stays switched on. GullySystem builds and sizes these for the workloads that suit them.
Where Serverless Is a Good Fit
- Traffic that spikes sharply and unpredictably, such as a form that only gets busy during a campaign
- Background work like generating a report, resizing an image, or sending a batch of notifications
- Scheduled tasks that run for minutes at fixed times rather than continuously
- A new feature where the eventual load is unknown and paying for idle capacity makes no sense yet
What We Build It From
Functions for Event-Driven Work
Code that runs in response to an upload, a queued message or a scheduled trigger, without a server sitting idle between events.
Managed Queues and Storage
Work handed off to a managed queue so a user's request finishes quickly while the heavier task completes separately.
Managed Databases
A database service that scales and is patched by the provider, sized and priced against running the same database yourself.
Where It Is Not the Right Fit
- A steady, high-throughput workload running continuously, where a fixed server is usually cheaper
- A process that must run for a long, uninterrupted stretch of time
- A feature where the first response after a period of inactivity must be instantly fast
What We Watch Once It Is Running
- Invocation counts and duration against the cost that pattern is producing
- Failure rates and timeouts on each function, since a silent failure here has no server log to notice it
- Cold-start frequency where response speed after inactivity matters to the user
Frequently asked questions
How do we know if serverless suits our workload?
It comes down to how your traffic behaves over a day. Spiky, occasional or scheduled work suits serverless well. A workload that runs near-continuously at a steady volume is usually cheaper and simpler on a fixed server, and we will say so rather than push serverless where it does not fit.
What drives the cost of a serverless setup?
How many separate functions and triggers the system needs, whether it must coordinate with an existing database or application, and how much monitoring and alerting is built around it, since a serverless system still needs to be watched for errors and cost spikes.
What drives the timeline for a serverless setup?
Mostly how many distinct workloads are being moved or built this way, and whether existing code needs restructuring to fit an event-driven trigger instead of running continuously.
Will this make our cloud bill unpredictable?
It changes the shape of the bill rather than guaranteeing it is lower. Pay-per-use pricing suits workloads with genuine peaks and troughs; a workload with continuous traffic can end up costing more than a fixed server would. We model the cost against your actual usage pattern before recommending it.
Can serverless functions connect to our existing database?
Yes, provided the database is reachable from the provider's network and can handle a burst of short-lived connections, which is something we check and, where needed, put a connection pool in front of.
Who owns the function code and configuration?
You do, delivered as source code and infrastructure definitions in your own repository, with the underlying cloud account in your business name.
What do you need from us to scope this?
A description of the specific workload, an idea of how often it runs and what triggers it, and access to any existing system it must read from or write to.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private