I wonder how they picked the name, probably drawing random words from a bucket. We've gone from solidly exact names to vaguely descriptive ones, then to completely unrelated and now apparently to actively misleading.
(I'm one of the founders at Airplane.) It started as a reference to "lightweight control plane[0] for your company" - but also the domains were loosely available.
Congrats on the series B and very interesting approach with the Views.
Developer tools, especially ones around code should be open-source. If you like the idea of productionizing one-off scripts, building flows, and managing secrets and schedules in an integrated platform, we have made the same observation as the Airplane team but in a fully open-source manner: [1]. Being open-source in this space offers a lot of synergies, you can for instance build a community around sharing the modules that compose your flows: [2]
In addition, if your primary languages are Typescript, Python or Go, we offer a more integrated experience by parsing the script parameters directly to generate the input spec and the frontend. We are developing our own UI builder as well, more to be announced in the next month. We just released our helm-charts for easier self-hosted deployments: [4]
Open-source does not mean we do not have a sustainable business model. We offer enterprise license for specific plugins and hosted solutions as well. The difference is that you can read our code, audit it and self-host the full platform with less frictions. Kafka and Airflow are also open-source but the commercial company backing them are thriving. Plus if we were to disappear, the project would continue to go forward.
> The company reported a loss before certain costs such as stock compensation of 16 cents per share, with revenue coming to $139.4 million in the quarter, growing 58% from a year earlier. That resulted in a net loss of $117.6 million for the quarter.
The company behind AirFlow is AirBnB. Yes it’s “thriving”. But not based on AirFlow.
Isn’t that “just” a hosted version of Airflow? If it is, that’s a different value proposition/risk assessment. If Astronomer goes out of business, you just take your code and host it somewhere else.
Why do we glorify raising money instead of congratulating companies for successful, profitable business models?
There is no way that I would depend on a closed source solution from a company with no proven business model.
Let me take that back. When I was a dev lead where our company made up 60% of our vendors revenue, we refused to sign a contract with them until they agreed to put their code in escrow and under certain conditions we had a right to their code.
Putting the code in escrow with a third party like Iron Mountain doesn’t give you access to the code unless the company folds or the product is discontinued.
I’ve been on the other side at another company where we were forced to put our own code in escrow by a large customer. I suggested we do the same for this vendor to our director he had the lawyers do everything else.
In fact when I was on the other side, our company did go out of business (got acquired for scraps), the escrow conditions were triggered, I was laid off as soon as we got acquired and went to work for the customer as a decently paid contractor.
It's AGPL. If you do not need any enterprise feature like SSO, you do not need to "call us", it's free. But if you fork it and re-expose it to users, you will need to make your fork open-source.
Our business model is that we are the only ones that can grant a commercial license because we hold the copyright and we provide plugins that only make sense at the enterprise scale such as SSO and exportable audit logs.
So in a sense, if you are an enterprise and need to pay us, what is the difference ? Well you can audit the code and experiment with it prior to deciding if you'd like to pursue with us, and not have to go through a salesy pitch to self-host and stress-test our orchestration runtime.
I do not know if your commented was targeted at Windmill or Airplane but our pricing is very clear and upfront. It's 10$/mo/user for the premium hosted version. You can read the code, use and self-host the product freely and without our blessing. The enterprise contract is a call us because that's how enterprise contracts work, they need complex agreement with various clauses.
To give them credits, Airplane was first. But we have very different ambitions imho. We have open-sourced our flow spec: https://openflow.dev and have a larger vision of becoming a standard for orchestration as established as Airflow or Temporal but simplified and principled, which is completely out-of-scope for a proprietary product.
At a high-level, yes - the "scripts to apps / workflwos" tagline that Windmill advertises on their homepage is something Airplane does as well. That was what we initially launched with about a year ago. We also now support the ability to create more complex UIs in Airplane as well.
So for example, if you wanted to create an admin panel / customer dashboard at your company that has the following functionality, you could do all of this in Airplane:
* Display customer data that's retrieved from a SQL query or REST endpoint
* Allow users to select customers and view more details about their usage
* Have a button next to each customer that says "delete customer" which kicks off a Python script that deletes that customer's data
(Appreciate the feedback! We clearly need to continue to improve how we explain the product. :))
It's probably easiest to explain in terms of what a developer does on Airplane:
1. Dev writes code (e.g. see our Getting Started for views[0]) - this can be simple Python scripts, JS views, shell scripts, etc.
2. Dev uses the `airplane` CLI locally to run and test the code
3. Dev runs `airplane deploy` or pushes to GitHub to deploy the code to Airplane
4. Dev's teammate (or dev) can now visit app.airplane.dev to run the code (views, tasks, runbooks) - the execution defaults to Airplane's servers, but you can also use our self-hosted agents[1] to move the execution (data plane) to your own cloud environment.
It's similar to GitHub actions in architecture (but for a different domain).
2 - correct, depending on the task type we still call through to node etc. But the CLI also provides a dev UI and other niceties specific to Airplane.
3 - correct, the code is built and pushed to us, similar to Heroku.
Our value prop ultimately is that 1) you can build tools like admin dashboards, data migration scripts, one off devops operations, etc, into production grade web apps and 2) you can do this using code!
To add on to what Josh said, the main value of Airplane is that we automate a lot of things that would normally require you to write a lot more additional code. So for example, if you build an admin panel using Airplane instead of doing so from scratch, we'll provide the following for you:
* A rich React component library that's optimized for internal tooling (tables, charts, etc)
* Permissions, audit logs, and approval flows that are easily configurable
* Integrations into various systems that an internal tool would normally have to integrate with (e.g. identity providers like Okta, Slack for notifications, etc)
So if you'd expect building that admin panel to take a few days or weeks of work, ideally with Airplane we can reduce that down to a few hours instead.
E.g. I'm using a signup flow w/ Airtable to check off / approve new sign ups. Person signs up, we see the profile, sometimes fix some details, and move it into the official Airtable of profiles — but would love to use Airplane instead since I'm trying to move off of Airtable for these sorts of things and use a "real" database. Using Views and a webhooks/triggers would be nice for the future when we just want to "auto approve" or move to db and airtable in parallel, etc..
joshma, should I use Airplane instead of creating cronjobs? I first heard about airplane the other day when I was googling alternatives to cron, or cron GUIs.
cron is a popular starting point on Airplane! We see our users creating tasks that are semi automated, but then adding manual tasks later (but then automating those tasks as well). The nice property of Airplane is that it's very composeable and extensible over time.
To add on to what Josh said, using Airplane for scheduling gets you a number of benefits over cron:
- Serverless - no need to maintain a cron server or worry about where the job is running
- Notifications - get notified in Slack or email if a failure happens
- Logging - we'll record every run, what happened, etc
- There are also a bunch of convenience features as well, e.g. having a native SQL integration so if you just want to run e.g. a query on a schedule, you can do so in minutes of work.
We're Airplane customers, after evaluating Windmill and trying some AWS feature that might be similar but was too hard to configure. We had two focuses when choosing Airplane and they've been met so far thanks to both their good product and to their amazing team who were responsive & understanding to changing things to make our requirements work.
1. Super easy to use actions & internal UIs, that allow end-users to run things without following Confluence rituals/SOPs. So many things that used to be "ask an engineer to do this when they have time" are now just buttons or interactive screens. But engineering still has control: anything that can can an incident or that is hard to reverse, Airplane automated the approval workflow so that a qualified person can approve it - whether it's a task or a button in an internal UI. Also, several scheduled runbooks/workflows that we could have set up a system to run - but why do that (+ maintain it forever) if it takes 20 minutes to configure in Airplane?
2. Cannot introduce more risk than it reduced (because we _did_ have risk from people doing these things by following written procedures). Everything gets logged, critical things are reported as Datadog events + Slack messages, our tasks and UIs exist in multiple environments (and go through source control) so we can test them like real software. All tasks run on _our_ infrastructure, using our IAM roles (which we've worked with Airplane to get to their minimal form, where they can't touch anything non-Airplane'y - and they changed the default installation to match, so if you start using Airplane you'll benefit from that too) and security groups (which reach dedicated load balancer listeners that can validate the requests). We have set permissions to be as strict as Airplane allows, connected to Google Workspace user groups (and so audited regularly).
Obviously whenever doing Build vs Buy: we could have built this. We could have also soldered our servers' circuitry on our own. But if someone needs something quick to automate their work, it takes less than an hour to set it up from scratch now and it's all straightforward.
You get five seconds to make me look longer. Took me forever to sort of understand what airplane is, after getting over the cognitive hurdle of figuring out that this is not about aviation....at all.
57 comments
[ 3.6 ms ] story [ 130 ms ] threadCongrats to the Airplane.dev team, even though the product has nothing to do with airplanes :)
"Ok, then what is it?" you ask
> Developer infrastructure for internal tools. Airplane is a developer-centric approach to building internal UIs and workflows.
In that sense it has the same security considerations as other SaaS products.
[0] https://www.cloudflare.com/learning/network-layer/what-is-th...
Developer tools, especially ones around code should be open-source. If you like the idea of productionizing one-off scripts, building flows, and managing secrets and schedules in an integrated platform, we have made the same observation as the Airplane team but in a fully open-source manner: [1]. Being open-source in this space offers a lot of synergies, you can for instance build a community around sharing the modules that compose your flows: [2]
In addition, if your primary languages are Typescript, Python or Go, we offer a more integrated experience by parsing the script parameters directly to generate the input spec and the frontend. We are developing our own UI builder as well, more to be announced in the next month. We just released our helm-charts for easier self-hosted deployments: [4]
You can also try it for free at [5]
[1]: https://github.com/windmill-labs/windmill
[2]: https://hub.windmill.dev
[3]: https://windmill.dev
[4]: https://github.com/windmill-labs/windmill-helm-charts
[5]: https://app.windmill.dev
I don't agree. I want the freedom to choose what tools I use, and what their development/profit models are.
By what definition is a company “thriving” that is losing money?
Confluent (Kafka)
https://siliconangle.com/2022/08/03/confluent-reports-strong...
> The company reported a loss before certain costs such as stock compensation of 16 cents per share, with revenue coming to $139.4 million in the quarter, growing 58% from a year earlier. That resulted in a net loss of $117.6 million for the quarter.
The company behind AirFlow is AirBnB. Yes it’s “thriving”. But not based on AirFlow.
Or is that exactly the point you are making?
There is no way that I would depend on a closed source solution from a company with no proven business model.
Let me take that back. When I was a dev lead where our company made up 60% of our vendors revenue, we refused to sign a contract with them until they agreed to put their code in escrow and under certain conditions we had a right to their code.
Putting the code in escrow with a third party like Iron Mountain doesn’t give you access to the code unless the company folds or the product is discontinued.
I’ve been on the other side at another company where we were forced to put our own code in escrow by a large customer. I suggested we do the same for this vendor to our director he had the lawyers do everything else.
In fact when I was on the other side, our company did go out of business (got acquired for scraps), the escrow conditions were triggered, I was laid off as soon as we got acquired and went to work for the customer as a decently paid contractor.
Our business model is that we are the only ones that can grant a commercial license because we hold the copyright and we provide plugins that only make sense at the enterprise scale such as SSO and exportable audit logs.
So in a sense, if you are an enterprise and need to pay us, what is the difference ? Well you can audit the code and experiment with it prior to deciding if you'd like to pursue with us, and not have to go through a salesy pitch to self-host and stress-test our orchestration runtime.
> Based on your pricing page, those helm charts cost "call us" money to use. Am I reading that right?
I couldn’t tell from your reply whether you were explicitly correcting him.
But it’s clear now, that I made a bad assumption about your pricing.
So for example, if you wanted to create an admin panel / customer dashboard at your company that has the following functionality, you could do all of this in Airplane:
* Display customer data that's retrieved from a SQL query or REST endpoint
* Allow users to select customers and view more details about their usage
* Have a button next to each customer that says "delete customer" which kicks off a Python script that deletes that customer's data
It's probably easiest to explain in terms of what a developer does on Airplane:
1. Dev writes code (e.g. see our Getting Started for views[0]) - this can be simple Python scripts, JS views, shell scripts, etc.
2. Dev uses the `airplane` CLI locally to run and test the code
3. Dev runs `airplane deploy` or pushes to GitHub to deploy the code to Airplane
4. Dev's teammate (or dev) can now visit app.airplane.dev to run the code (views, tasks, runbooks) - the execution defaults to Airplane's servers, but you can also use our self-hosted agents[1] to move the execution (data plane) to your own cloud environment.
It's similar to GitHub actions in architecture (but for a different domain).
[0] https://docs.airplane.dev/getting-started/views
[1] https://docs.airplane.dev/self-hosting/agents
1. OK
2. Dev uses the `airplane` CLI as opposed to running `npm`, `python` etc locally?
3. Dev runs `airplane deploy` as opposed to deploying to Heroku?
I think it would be nicer for us if you explained your value proposition in terms of what tools/steps I'd be replacing if I choose to adopt Airplane.
3 - correct, the code is built and pushed to us, similar to Heroku.
Our value prop ultimately is that 1) you can build tools like admin dashboards, data migration scripts, one off devops operations, etc, into production grade web apps and 2) you can do this using code!
* A rich React component library that's optimized for internal tooling (tables, charts, etc) * Permissions, audit logs, and approval flows that are easily configurable * Integrations into various systems that an internal tool would normally have to integrate with (e.g. identity providers like Okta, Slack for notifications, etc)
So if you'd expect building that admin panel to take a few days or weeks of work, ideally with Airplane we can reduce that down to a few hours instead.
How many layers of 'magic' to facilitate devs deploying do we really need and is it wise to depend on so many?
Is there a way to trigger the tasks via webhooks?
E.g. I'm using a signup flow w/ Airtable to check off / approve new sign ups. Person signs up, we see the profile, sometimes fix some details, and move it into the official Airtable of profiles — but would love to use Airplane instead since I'm trying to move off of Airtable for these sorts of things and use a "real" database. Using Views and a webhooks/triggers would be nice for the future when we just want to "auto approve" or move to db and airtable in parallel, etc..
- Serverless - no need to maintain a cron server or worry about where the job is running
- Notifications - get notified in Slack or email if a failure happens
- Logging - we'll record every run, what happened, etc
- There are also a bunch of convenience features as well, e.g. having a native SQL integration so if you just want to run e.g. a query on a schedule, you can do so in minutes of work.
1. Super easy to use actions & internal UIs, that allow end-users to run things without following Confluence rituals/SOPs. So many things that used to be "ask an engineer to do this when they have time" are now just buttons or interactive screens. But engineering still has control: anything that can can an incident or that is hard to reverse, Airplane automated the approval workflow so that a qualified person can approve it - whether it's a task or a button in an internal UI. Also, several scheduled runbooks/workflows that we could have set up a system to run - but why do that (+ maintain it forever) if it takes 20 minutes to configure in Airplane?
2. Cannot introduce more risk than it reduced (because we _did_ have risk from people doing these things by following written procedures). Everything gets logged, critical things are reported as Datadog events + Slack messages, our tasks and UIs exist in multiple environments (and go through source control) so we can test them like real software. All tasks run on _our_ infrastructure, using our IAM roles (which we've worked with Airplane to get to their minimal form, where they can't touch anything non-Airplane'y - and they changed the default installation to match, so if you start using Airplane you'll benefit from that too) and security groups (which reach dedicated load balancer listeners that can validate the requests). We have set permissions to be as strict as Airplane allows, connected to Google Workspace user groups (and so audited regularly).
Obviously whenever doing Build vs Buy: we could have built this. We could have also soldered our servers' circuitry on our own. But if someone needs something quick to automate their work, it takes less than an hour to set it up from scratch now and it's all straightforward.