Comparison
GetFlowing vs DevOps platforms.
Deployment platforms solved the deploy. GetFlowing is aimed at the two problems either side of it: producing the change in the first place, and looking after the application once it is running.
Short answer
A DevOps or hosting platform takes code you have already written and reviewed, and runs it. GetFlowing also produces the change: implementation as a reviewable pull request, tests attached before merge, the container build, the AWS rollout with health checks, then monitoring, incident context and the maintenance that follows. Planning is available for changes worth agreeing first, and skipped for the rest.
Still yours to solve
What a deployment platform leaves with your team.
Deployment platforms are good at their job. The question is how much of the delivery problem their job covers.
- Agreeing the change before it is built, so a release is not the first time anyone sees it.
- Writing the change, and finding the review capacity for it.
- Writing and maintaining the tests that decide whether it is safe.
- Keeping the pipeline configuration working as the application changes.
- Investigating an incident with the application context that caused it.
- Working through the maintenance backlog after the release.
Side by side
Where each platform starts and where it stops.
A deployment platform begins at a commit that already exists. The rows above and below that line are the comparison.
- Start
- With a deployment platform
Out of scope, and reasonably so. The platform starts at a commit.
- With GetFlowing
Ask for the change and agents begin on it. Larger work can be described and agreed first, so the release is not the first time anyone sees it.
- Implement
- With a deployment platform
Yours to write, and yours to find the review capacity for.
- With GetFlowing
Agents work on a branch in your repository and open a reviewable pull request.
- Test
- With a deployment platform
Your pipeline configuration, written by you and maintained by you as the application changes underneath it.
- With GetFlowing
Test suites run on the change and the results are attached before it can merge.
- Build
- With a deployment platform
Usually included and usually good, configured through a file in your repository that you own.
- With GetFlowing
The container image is built, checked and stored in a private registry.
- Release
- With a deployment platform
The part these platforms do best: a deploy on push, with previews and a rollback.
- With GetFlowing
Production deployments pause for approval, then roll out to AWS behind health checks, with the decision written to the audit trail.
- Operate
- With a deployment platform
Platform level metrics. Application context, incident investigation and the maintenance backlog stay with your team.
- With GetFlowing
Traffic, latency, errors, uptime and logs sit beside the deployment history. A failed release opens an incident and raises a ticket with the GetFlowing team in the same step, and findings become the next task.
When a deployment platform is enough.
If you have engineers producing reviewed changes and only need somewhere dependable to run them, a deployment platform is the simpler answer and the cheaper one. GetFlowing fits when producing the change is the constraint rather than shipping it. Your existing GitHub workflow runs are still read for context, so keeping your own pipeline does not conflict with this.
Platform questions
Deployment, pipelines and what surrounds them
Hosting, CI and CD, the cloud GetFlowing deploys to, and what happens when a release is unhealthy.
Is GetFlowing a hosting platform?
Not only that. GetFlowing containerises your application, pushes the image to a private registry and deploys it to AWS, so it does cover hosting and release. It also covers the work a hosting platform leaves to you: planning the change, implementing it, testing it and maintaining the application afterwards.
Do I still need to assemble a CI and CD pipeline?
The pipeline is part of the platform. Tests run on every change with results attached to the pull request, the container image is built and versioned, and the rollout to AWS runs health checks before traffic moves. Your existing GitHub workflow runs are still read for context, so keeping your own workflows does not conflict with this.
Which cloud does GetFlowing deploy to?
AWS. Applications are containerised and deployed to AWS, with a generated URL for each application, optional custom domains, logs, health monitoring and rollback available from the same place that shipped the release.
Who notices when the application stops working?
The platform does. A monitor checks the running application and opens an incident when it is not serving correctly, then resolves that incident automatically when it recovers. A failed deployment opens an incident and raises a support ticket with the GetFlowing team in the same step, with the container final logs attached. A hosting platform gives you the metrics, but somebody on your side still has to be watching them.
What happens when a release turns out to be unhealthy?
Health checks run as part of the rollout and production traffic only moves once the release is healthy. After release, traffic, latency, errors and uptime are monitored, logs and incident context sit next to the deployment that caused them, and a rollback is available.
Something not covered here? Email hello@getflowing.ai and we will answer directly.
Private beta
Bring software delivery into one system.
Build something new or take control of what already exists. Get the planning, engineering, deployment, and operational capability of an experienced software team.