Flightcontrol: A PaaS that deploys to your AWS account

https://www.flightcontrol.dev/

by handfuloflight • 10 months ago

171 96 10 months ago

flightcontrol.dev

crazycheesu• 10 months ago

So this is basically a webgui for the aws cli ?

vends• 10 months ago

Looks like it offers a much higher level of abstraction than that.

Seems closer to Heroku/Vercel but running in your own AWS account.

_joel• 10 months ago

So AWS Beanstalk? :)

holografix• 10 months ago

So it’s a neo-Heroku?

cmdtab• 10 months ago

I tried flight control but it was a bit buggy and rough. My docker image worked differently on their platform compared to other PAAS.

Lot of issues with slow AWS provision or missing APIs on AWS side so it would take hours to delete resources created by them.

flybayer6• 10 months ago

When did you try it?

kolanos5• 10 months ago

Found this in their roadmap [0]:

Managed ECS-EC2 clusters in preview
AWS has a long standing issue with the ECS agent randomly disconnecting, resulting in orphaned EC2 instances which can cause traffic or deployment degradation.
We have attempted to solve this a few ways in the past, but there were still critical edge cases falling through.
So we bit the bullet, and developed a robust, full featured ECS cluster management solution to solve this problem once and for all.
It's currently in private preview. To get early access before we roll it out to everyone, contact support.

I found elsewhere in the Flight control docs where they recommend ECs+EC2. While I'm not surprised to hear about issues with ECS+EC2, given the reported issues above I don't know if I'd recommend it in my docs. Fargate is a far better option for most use cases, at least in my experience. Unless you need specialized instance types, like GPU workloads.

[0] https://roadmap.flightcontrol.dev/changelog

arpinum• 10 months ago

This could have been some custom cdk constructs. Then at least you can plug in SQS / SNS / DynamoDB / CW / IAM all in one solution. Flightcontrol doesn't seem to offer these.

catlifeonmars2• 10 months ago

I’ve been getting great mileage out of service catalog products. They’re a great middle ground between custom CDK and in-house PaaS. You can even use them as CloudFormation resources so they compose well and users are agnostic to which CDK language (or Terraform even!) that is used to write them. I’m currently experimenting with using them to expose terraform modules as CDK constructs.

coredog643• 10 months ago

Service Catalog is on my top 5 list of terrible AWS developer experiences, and I've used practically every mainstream service.

tuananh• 10 months ago

i remember deis, it was amazing self-hosted heroku. too bad they were bought by microsoft.

and then there's also flynn.

bilekas3• 10 months ago

Your team gets bogged down with complex Terraform scripts, manual configuration, and endless CI/CD pipelines.

I really hate marketing speak like this. Terraform is there specifically to solve the Aws infrastructure complexity.you create your system once and minor changes if needed.

Flightcontrol fully automates infrastructure provisioning, CI/CD, and deployments. All within your own AWS account where you retain full visibility and control

Why does everyone think this is a desirable thing? Excluding adding to your aws price, you're now vendor locked in for your pipelines also.

I'm not seeing any benefits here for any already established company, maybe a small start-up of fresh graduates who don't want to learn Iac/DevOps ?

MrBuddyCasino4• 10 months ago

Terraform is there specifically to solve the Aws infrastructure complexity.

I don't know if anyone here remembers the Ant build system, but writing your own Terraform spaghetti strongly resembles the days of Ant, before Maven came along. Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.

Y-bar• 10 months ago

Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.

This hits home so much!

I remember last year when I asked our Cloud Ops to add an additional EC2 instance and adjust sizes on two others. It took twelve work hours and resulted in +3k -2k changed lines "because they had no way of doing it now without merging seven hundred other changes.

bilekas3• 10 months ago

Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.

I have to disagree a little here, if you're already in AWS, then an investment in fixing your terraform structure is not just worth the money, but gives you a better understanding of the infrastructure architecture, you also retain ownership of your deployments. What happens if Flightcontrol go down for whatever reason? Or are sold off like other's we've seen, or god forbid you need some fine tuning that isn't in the Flightcontrol's website. You're now depending on, and maybe even paying for, an external company for devops support to do something you already know how to do.

It seems to be in the long term, that time is definitely not better spent elsewhere.

CuriouslyC2• 10 months ago

There are two devops patterns that WORK:

1. All centrally managed. Engineers hand off repos and devops own the instantiation. Devop is a core team with an infra monorepo.

2. Devops capable engineers are embedded into teams, and each project owns its own infrastructure with golden path guidance.

The hybrid version, central management of most stuff with project specific devops burden, is the worst of both and causes no end of problems.

throwaway61352• 10 months ago

I guess in an ideal world, a service like this would be a layer on top of Terraform. Changes in the admin page would be applied using Terraform, and update the config in your own Git repository. I think this would be much easier to sell, even if they choose to make it "write only" to avoid potential complexity of managing user defined configs.

They could get customers initially by promising a simple start to get "on the cloud", but would keep customers due to support, scaling, monitoring, ci/cd and maintenance. Cheap startups could use it as a one-time tool, but I think a lot would see the added value they bring.

bionsystem• 10 months ago

Non-ops teams in big corp / public services are often fed up by their own IT (slowness, incompetence) and want to deploy, budget lines for recruiting devops/sysops is sometimes different than software/platform licenses, even if the solution is sub-optimal.

Disclaimer I'm an SRE/sysops and went through a bunch of those projects where sometimes entire department see (often shadow) IT from contractors as the only solution moving forward.

master_crab2• 10 months ago

Terraform used to solve the AWS infrastructure problem. But at a certain scale it becomes the problem.

balls187• 10 months ago

Is this an issue with Terraform, or "infrastructure-as-code" in general?

hanikesn• 10 months ago

Terraform is there specifically to solve the Aws infrastructure complexity

No, terraform passes AWS complexity 1:! onto you, it just allows you to tackle it in an ordered fashion.

mannyv• 10 months ago

Terraform isn't there to resolve the complexity of aws, it's there so you can manage tour aws deploy more easily.

In fact, terraform exposes the complexity of AWS, since with terraform you need to hook everything up manually.

And avoiding vendor lock in is an illusion. Everyone is locked in to some extent. Just design things so you can move providers by understanding your system and architecting it correctly.

Not taking advantage of extra capabilities vendors provide you is just stupid. SQS/lambda is great. Why avoid it, because one day in the far future you might move to GCP? Protip: if you move to GCP (or Oracle cloud, or IBM cloud, or CloudFlare, etc) you're going to rebuild everything anyway.

For larger companies this will get shut down, because the idea of some random team deploying to the cloud by themselves is a security breach that hasn't been reported yet.

bilekas3• 10 months ago

In fact, terraform exposes the complexity of AWS, since with terraform you need to hook everything up manually.

Clearly you've never had to deal with deploying large systems on AWS because if your account even has provisioning permissions, whish is usually a huge security risk in enterprise environments, the chances of you messing something up are all on your familiarity with Aws console. And if you get something wrong you're stranded without any kind of rollback. Terraform gives you rollback ability as well as validation against your requirements.

BoorishBears• 10 months ago

I liked Flightcontrol, found it more reliable and less finicky than Cloud Build + Cloud Run, but it was too expensive for me.

They introduced a cheaper plan since I tried it, but it's missing the main feature that I actually think makes FC worth it (preview environments)

I know not everyone wants to get in on the Vercel Cartel model of excessive free-tier generosity made up for by 1000% markups at scale... but $400/month is tough to swallow when you barely need $50/month of compute to handle your production workload.

gervwyk• 10 months ago

Same problem, used them for about a year. Nice experience but too pricey. also escalated our aws fees, perhapsa good idea, but too pricey for what we need.

hshdhdhehd• 10 months ago

Nice idea. I work at SP500 corp and we have platform teams provide this. I always wondered if it could be a startup. My reservation with tbis is tbe classic one: not open source. But I totally get why it isn't. Although FOSS might work as the value (at work and here too) is in having someone in a Slack channel that can help if a deploy gets stuck. The code is kind of a terraform-esque of sorts.

eclark• 10 months ago

I think 'Batteries Included' would interest you, then. Like this, it's installable on AWS. It's a whole platform PaaS + AI + more built on open source. So Kubernetes is at the core, but with tons of automation and UI. Dev environments are Kubernetes in Docker (Kind-based).

- https://github.com/batteries-included/batteries-included/ - https://www.batteriesincl.com/

thevivekshukla• 10 months ago

In general I love the PaaS experience and I can see the value Flightcontrol can potentially provide to the companies that work mostly with AWS. The free starter plan for individual is tempting to try out Flightcontrol, BTW what is the service limit for free plan? I could not find it.

I am also working on similar tool[1] but it's bit more niche to batch jobs type functionality but not just limited to AWS rather it's cloud agnostic.

[1]: Daestro - https://daestro.com

flybayer6• 10 months ago

There is no service limit on the free plan. It’s limited to a single user instead.

slig2• 10 months ago

It's a shame that "Preview environments" are only available on the business plan @ $397/m. I guess that it makes sense if you're expending $4k+/m on AWS.

pelagicdev• 10 months ago

Coolify is your best option here. It has preview environments and lots of other built-in features - just the cost of your server if you're savvy enough to get things setup yourself. https://coolify.io/

slig2• 10 months ago

Thanks, I was watching a video about Coolify vs Dokploy from "Dreams of Code", and I think I'm going to try Dokploy first.

the_real_cher2• 10 months ago

Seems like AWS should offer something like this.

evantbyrne3• 10 months ago

They do with app runner, but last I checked, for some reason services were capped at low CPU/Memory and didn't allow basic ECS features like attached storage. I think they also had another one... AWS is very fragmented and strange.

coredog643• 10 months ago

Dollar dollar bills y'all: https://aws.amazon.com/managed-services/

They offer two discrete services. One is a simplified AWS where the interface is something like Service Now and you don't have access to the environment to make control plane changes. The second (and newer) offering is that they will onboard to your existing AWS operating environment and assist with running your applications.

the_real_cher2• 10 months ago

I worked on one of the first aws managed services that integrated directly with service now back in the early 2010's at G.E.

They laid off my whole team because AWS started doing our job and better, LOL.

So I see OPs post and it brings back memories.

ramses0• 10 months ago

Pour one out for Flight Control, the $0.99 phenom of an app back in the early iOS days.

It came to mind due to the iOS 26 "Games" app reminding me of 12-y/o "Achievements" that now only exist as flags in a database.

atonse• 10 months ago

That was such an amazingly simple, well executed, and fun game.

Thanks for the reminder.

languagehacker• 10 months ago

There's definitely a market for something like this, because most software companies at a certain size end up needing to build something like this. The real question is, how much work will you need to do to fit your current software to their paradigm in order to get the benefit? For a newer project, there's likely little sunk cost, but for anything that's already productionalized, I don't doubt that the rework -- particularly around all the devops bits and pieces -- will likely be significant. And then of course, from a strategic standpoint, you need to balance the risks vs. rewards of hitching your wagon to Flightcontrol's set of conventions.

There will be a really solid chunk of projects that find good cost savings using this platform -- especially teams that are resource-constrained on devops and don't consider it their core competency.

CuriouslyC2• 10 months ago

Data point: I wouldn't use a service for this, but I can see that there are plenty who will. The defensible moat is pager duty as a service, every engineering org on the planet will push management for that.

infecto• 10 months ago

Can we fix the title? It’s not AWS PaaS but a PaaS built on top of AWS. I thought it was a new service being launched by AWS.

ChicagoBoy11• 10 months ago

I had the exact same reaction, and then when reading some of the copy thought to myself: "omg, can't believe they are being so degrading to how clunky their own dashboards and things are!" And then it hit me...

rco8786• 10 months ago

Ditto

dang• 10 months ago

We've changed the title now to what the page says. (Submitted title was "Flightcontrol: AWS PaaS")

Submitters: "Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html

jakespracher• 10 months ago

Use it and like it. If using aws is a requirement but you don’t want to get bogged down with their user experience it’s worth it IMO.

Have run into some aws quirks leaking out of their abstraction. But personally that has only made me say “man if they couldn’t figure out how to make this clean, I would have been toast dealing with it on my own”

dewey2• 10 months ago

Similar and not tied to a cloud provider: https://dokku.com

bpicolo• 10 months ago

Not similar - dokku doesn't support distributed compute. It's a platform intended for use on a single server.

josegonzalez• 10 months ago

Dokku maintainer here.

Dokku supports distributed compute via our k3s scheduler plugin. This can setup its own k3s cluster or connect to an existing Kubernetes cluster and deploys helm charts on this clusters for your app.

evantbyrne3• 10 months ago

I built something very similar to this a few years ago, sold it for way less ($3/service), and ultimately decided not to spend money marketing it. Building the product made it super clear that AWS costs were grossly inflated, which they hid with dark UX, and I wanted to help small teams and hobbyists. Today, if you are a small team that doesn't really need more than one large VPS, you should seriously consider Docker Swarm. Not to say that Flightcontrol looks bad. In fact, it looks quite nice. Something like this could save you a lot of money if you would otherwise need full-time devops.

achandlerwhite• 10 months ago

Can you elaborate on Docker Swarm? I thought it lost out to Kubernetes and was effectively dead.

evantbyrne3• 10 months ago

Swarm never died. Kubernetes was designed for an entirely different level of scale and there is inherent complexity in that. Whereas starting a production-ready container service with Swarm only takes a few commands on a fresh Docker installation.

lightningspirit• 10 months ago

I've been using Docker Swarm for almost 6 years now deploying entire stacks for customers on top of it — it's stable and incredibly cheap to maintain.

gregorvand• 10 months ago

Trust suggestion: make it easier to find photos of the founders, than the investors.

esafak2• 10 months ago

Wait ... where are the founders?

burkaman• 10 months ago

Here, I guess: https://www.ycombinator.com/companies/flightcontrol

It is very strange to have headshots of individual investors on the page that would normally have pictures of your team.

flybayer6• 10 months ago

Good suggestion, our company page is updated to include the founders

coolgoose• 10 months ago

I am still happy with northflank. A bit more infra provider independence is nice to have. (we are actually moving from gcp to aws )

8cvor6j844qw_d6• 10 months ago

Skimmed the docs but does Flightcontrol allows a cost cutoff?

I wanted to go with AWS but ended up with Digital Ocean / Vercel for personal stuffs due to concerns on AWS horror bills.

flybayer6• 10 months ago

No, but we support cost budget alerts.

endriju• 10 months ago

I think the problem with these general-purpose PaaS on top of Cloud is exactly that they're general-purpose. You will run into limitations and issues as soon as you start doing things only 5-10% of their customers need, like for example running privileged docker containers in kubernetes or wanting to manage parts of your infra with terraform. I'd much rather see tools helping me deploy one particular niche use case in Cloud really well. BTW I'm trying to follow this mantra while building https://staticbot.dev

roncesvalles• 10 months ago

And their value prop that you need expensive hard-to-find AWS DevOps Engineers to run your AWS infra is just fear-mongering.

I think people vastly overestimate how hard it is to learn AWS. It may seem daunting at first but it only takes like a week -- one good YouTube series to cover the basics like IAM, and a lot of playing around with the GUI console, CloudFormation, and pestering support till it all clicks. Multiple backend devs in your team should be able to own your CloudFormation/Terraform scripts and your cloud infra. I basically did exactly this in my new grad SWE job.

Just fucking learn it. You don't need to hire someone for every little thing. Don't treat AWS like some complex arcane machine that only a 3x AWS-certified "Cloud DevOps Engineer" with 10 years of experience should touch. And for the love of God don't add more 3rd party layers like TFA. Most of the world is raw-dogging AWS, why is your company an exception?

johnthuss• 10 months ago

Amazon has their own PaaS offering called Elastic Beanstalk, with support for running docker containers and other popular platforms. It's not complicated to set up and is customizable if you need to tweak things. Any idea how Flightcontrol compares to this?

whs• 10 months ago

We acquired a company that use EB and they have no dedicated DevOps engineer. It was bad because every deploy is a full VM boot which takes a long time and you can't do things you can do with Argo Rollouts. We migrated them to EKS.

I casually asked our account manager "Do you know any local customer with EB success story?" Their answer was "Do you want to be one?"

smt88• 10 months ago

EB is buggy garbage. We switched to FlightControl to get a similar experience without the bugs and headache.

jimt1234• 10 months ago

Flightcontrol gives our team the power to manage bare metal AWS ...

"bare metal"? Hmmm. I think we have different definitions of that phrase.

this_user• 10 months ago

All we need need now is "PaaS as Code" (PaC) services as the next iteration of DevOps stacks that increasingly border parody.

birdalbrocum• 10 months ago

Why web developer culture is so annoying when it comes to naming things? Serverless? It is actually a server. Flight control? Nothing to do with airports or flights or whatsoever.

dewey2• 10 months ago

"Deploying" a new feature into "staging" also doesn't have to do anything with a battle. Naming is hard and most project names just pick a fun name.

Your point about "serverless" I can understand, but "Flight control" seems like a great name for a product like that.

kube-system• 10 months ago

Creating new words from existing words or concepts is how language works. In fact, "airport" is an example of this... ports were originally for boats.

New terminology may sound strange to people who are not familiar with it, but if people start to adopt it, it becomes a normal and accepted word. Basically every word has gone though this process at some point.

And brand names are often witty puns or irrelevant words, intentionally. Using descriptive words for a brand is legally a bad idea, because this can disqualify you for trademarks. The point of trade marks is to uniquely identify the offering -- if you named it descriptively you risk losing this. Apple computers are not fruit, and Windows computers are not transparent glass. If you named your computer "computer" you wouldn't have a brand, and nobody would be able to know what to refer to your computer.

nemothekid2• 10 months ago

I wonder how many of these exist at every company. At $dayjob we have built something similar over the years. We have a custom load balancer that will query ECS, provision certificates with lets encrypt and even provision domains inside Cloudflare. We also have deploy previews, and various services on lambda function urls. We used to use mesos but transitioned to ecs, so we even have a homegrown "chronos" for running scheduled jobs on ecs.

SOLAR_FIELDS• 10 months ago

This is the end result of the “but kubernetes is too complicated” argument. You end up hand rolling all of the things it gives you out of the box. I’m sure you have your reasons for not using kube, but every one of those things you mentioned you get in a standardized way with kube

nemothekid2• 10 months ago

We were on Mesos before so k8s complexity wasn't the deciding factor. If I cared about being could-agnostic, I would have gone the kubernetes route. The main factor was we decided to move as much as possible to aws managed services so that we wouldn't be responsible for their operation. Once we have made this decision, then paying the premium for EKS over ECS Fargate didn't make much sense.

From there a lot of our custom software is just adapting the AWS platform for our taste. For example, we define a lot of our routing configuration using docker labels (similar to Traefik), so we needed a reverse proxy that could handle that.

coredog643• 10 months ago

so we even have a homegrown "chronos" for running scheduled jobs on ecs

EventBridge scheduler is finally available in GovCloud

tracker1• 10 months ago

Wow, they are definitely targeting Heroku with this... specifically calling them out towards the end of the page.

That said, I'm surprised that Azure and GCP don't already have similar service offerings... I'm not sure about nixpacks over direct Dockerfile usage though. Would also be nice to see a WebASM package system as well for single ip/socket services and web-service request handlers. Simplify the application layer as much as possible and make logging via line-separated json on stdout the norm... add layers to relay logging and handle TLS termination. IT just makes sense... it also makes sense to bundle services onto fewer servers based on actual ram/cpu usage. Maybe an easy button for redundancy, and that's it.

There's a lot of appeal in what fly, deno, cloudflare and others are offering but to a broader range of options than just JS focus with WebASM as a minor afterthought with weird limitations in practice.

arccy• 10 months ago

at least for GCP, isn't that cloud run?

kolanos5• 10 months ago

Just reading over the docs, you'll need a lot more GCP services than Cloud Run to encompass what Flightcontrol is managing for you. The Cloud Run analog is Fargate. Which is only the container orchestration piece.

kolanos5• 10 months ago

Looks like you can use your own Dockerfile or a container registry. Suspect nixpacks are just a recommended starting point for people looking to get up and running quickly.

MrDarcy• 10 months ago

Is the paas built on Kubernetes?

kolanos5• 10 months ago

Looks like it is ECS with either Fargate or EC2. If you don't need more control over your containers, Fargate is a good default.

freshnode• 10 months ago

Using it. Moving off it.

RDS public by default (!), and the private config just removes the public IP address rather than puts in private subnet. Causes it to fail CIS benchmark which is requirement for FTR.

When I raised it I was told I was wrong.

I think there is a good future for the product but one size fits all config comes with downsides. IMO Would be better if it was IaC but with pre built "blocks" app, cache, etc, which you could easily customize. I also think the pricing is too steep for your average scaling bootstrapper which is where Heroku et al shined.

flybayer6• 10 months ago

RDS has been default private for probably 6 months or longer.

Would be better if it was IaC but with pre built "blocks" app, cache, etc, which you could easily customize

We are working on a major new product version that does exactly this ;)

bdcravens• 10 months ago

While I'm sure the implementation isn't the same, Cloud66 has been doing this for a long time.

windex• 10 months ago

AWS is like one of the sci-fi portals, one moment you are carefully exploring it and the next moment it's crawling all over you and then pulling you in while you shout about costs.

Flightcontrol: A PaaS that deploys to your AWS account

Related Stories