When putting together RestlessIDE (the soon-to-be best web-based development environment!) I had a lot of different thoughts floating around in my head. I have been a huge fan of web-based development for a long time. Back in the 2016-2017 timeframe I used an Acer Chromebox as my main dev setup, with Cloud9 IDE being my daily driver. It had its quirks but was generally a solid experience. Then Amazon bought and killed it for some reason.
I then tried switching to one of its competitors (they’re still around, so I won’t name names. YET!) and the experience was more mixed. The editor itself was mostly fine, but the terminals tended to lose connectivity regularly; you’d see text but couldn’t type, and would need to reload the page and hope it worked out. Things generally felt just a little bit off. Shortly thereafter, I retreated back to Linux and VS Code, thinking my dream of permanently-online editors was done.
After a few years, I started to get that itch again. Poking around I saw the scene had changed quite a bit. I logged on to the one I had been using previously and found that they had actually bifurcated their product, with the one I had been using (and paying for) now the “legacy” version with a whole separate login and a worse overall experience since they hadn’t been putting much time into improving it. The new version did have a nicer UI, but it had become infected by a disease I call Cloud Pricing.
The more I looked around, I saw the same thing with pretty much every other service. Let me explain.
To the Cloud!
An interesting thing happened back in 2006: Amazon opened up Amazon Web Services (or AWS) to the outside world. While not the first service to offer the hourly pricing model, it quickly took the developer world by storm just due to Amazon’s scale. Now every two-bit startup in the world could get servers with a simple API call and scale their infrastructure as needed to meet any level of customer usage. Just starting out? Get one EC2 instance, maybe a micro. Get more traffic? Move up to a small. Hit the front page of Digg? Let’s load balance some 2XLs!
Over the years this hourly pricing model became very popular among other companies in the infrastructure space. First of all, many of them were built on AWS, so they needed to pass along those costs somehow. And second, it gave an easy point of comparison to people trying to shop prices. And saying you cost $0.119 per hour sounds a heck of a lot better $85.68 per month.
The problem with this model is that it is metered. You pay for usage (which is fair, to a point) but you also never know at the beginning of each month what you’ll be paying in the end. And if you’re anything like me, the surprises are not often in your favor. The metered approach also has led to “usage” being redefined in ways that don’t benefit consumers. Once you’re committed, you’re basically forced to pay whatever the service provider says, or your infrastructure goes away.
Using AWS as an example, they started off with a handful of services. Two of the earlier ones were Simple Storage Service (S3) and Elastic Compute Cloud (EC2). The former let you upload files into buckets and have them available wherever you need, either privately or publicly with convenient download URLs. The latter let you launch virtual machines of different specs for different hourly rates. The math was relatively simple for each. On S3 you pay a certain amount per GB per month, and with EC2 you pay for the time that the server is running. Light bulbs went off and people did the math, working those costs into their own business models.
Then those costs began to creep up.
It turns out, S3 also charges a bit for data leaving Amazon’s network. Just a little bit, as long as your public link doesn’t get hit by a botnet for some reason and downloaded 1,000,000 times. And EC2 was expanded and grew into a whole constellation of add-on services, each with their own charges. To store data permanently, you would use Elastic Block Store (EBS) volumes. ($) To manage splitting traffic between multiple EC2 servers you’d use an Elastic Load Balancer. ($$) If you want to host a static site in S3 and need a certificate (who uses naked HTTP these days?) you’ll need to put it behind CloudFront ($$$).
Of course it makes sense that you pay for all of these services, because you’re using them after all. But the lack of predictability and sometimes arbitrary-feeling upcharges can be frustrating.
Moving Upstream
This hourly pricing model has broken out of the raw infrastructure industry and into other providers who build on top of that infrastructure. Case in point, CodeSandbox.
CodeSandbox is a “competitor” to RestlessIDE. I use the air quotes around “competitor” because they are 8 years old with 10s of millions in funding and a mature product, and I’m a guy in a WeWork. But also because the first thing I hear from people when I show them RestlessIDE is “hey, isn’t that a lot like what CodeSandbox does?” (For those interested, the answer is that there are superficial similarities, but much different approaches. I like ours better.)
I first heard of CodeSandbox a few years back when I clicked on a URL to someone’s sandbox for some frontend Javascript tool. It was really neat, like an interactive console with a really good code editor. It felt just like a proper IDE. But I noticed that it didn’t have that one thing every IDE needs: A terminal. Curious.
The next time I saw them was when I was doing competitive analysis for this RestlessIDE. I saw that they had a new type of offering, a VM sandbox, and that these had a terminal. Also that they were much more limited in terms of how long you could use them. 40 hours a month on the free plan and 100 for the $12 a month Editor plan, with additional hours being billed at $0.15 per. So a typical 160 hour work month is $21. That doesn’t sound too bad. But then there are the details.
What is a workspace, and why do they have a certain number of members? Wait, does this mean that I need to split my 100 hours (up to) 20 ways? Does a workspace let me use multiple sandboxes with different libraries and code in each one? There are also VM tiers priced on the bottom of the page; where do those figure in? Are they in addition to the $12 a month VM credits? If I need to keep a particular sandbox alive 24 hours a day (because my client in Greece wants to check out my dev site, and I need it to be there whenever they choose to look) I’ll need to pay (checks math) $93?
What I’m seeing here is a top line number that seems very reasonable, but a whole lot of uncertainty in terms of what that actually includes, and a deep suspicion that if I migrate my team to this tool for doing actual work I’ll get a big surprise at the end of the month. Or I might not. I just can’t tell by looking at the pricing page.
I think what happened is that the unlimited Browser Sandboxes are the OG offering without the terminal, where all of the code can be served by a CDN and all the work is being done by your browser. This is perfect for working with frontend code, which is why those sandboxes were passed all around back in the day. The problem was that as cool as these were, it’s tough to do Real Work without access to a terminal and backend programming environment. CodeSandbox created a new type of sandbox (VM Sandboxes) which did have this capability, but then ran into the age-old problem:
I costs money to put containers on the web.
The team needed to figure out how to bundle these in a palatable way with a low price, while also making it financially sustainable for themselves. So they offered a generous free tier with the hope that once people tried it out they would upgrade to the paid version. A lot of the numbers shown on the pricing page like the number of members, etc, are sort of window dressing to increase the perception of value around what you get with higher tier plans. The real meat is the number of hours of VM Sandbox time.
Please, I mean nothing here as a criticism of CodeSandbox, it’s a good tool. One friend that I surveyed is a happy customer on the paid plan and uses it for prototyping all sorts of frontend projects, and finds the bundled starter kits great for doing that. I’m just talking about cloud pricing in general, and am using them as a specific example of how it’s difficult. And they’re better at publishing prices than most. Most pricing pages have one column for free (for new users with almost no usage) and two columns with some variation of “Call Our Sales Team.”
What are we doing here?
In the spirit of Getting the Model Right, I had to sit and think about what I was trying to do with RestlessIDE. What I settled on was this:
Create an environment where development teams could move their processes to the web without compromises.
In order to achieve that, cloud pricing had to go. I thought about how we buy things in the real world. When you buy a computer, you expect to be able to use all of that computer for as long as you want. If you buy a hosting account for your website, you expect it to just stay online as long as you pay your monthly bill.
This is how humans process things.
It’s important to make your pricing model mesh with customer expectations, while also covering your own expenses. If you want to stay in business, of course.
So RestlessIDE uses Hosts, which are virtual machines you rent on a monthly basis. They have different specifications at different price points, and can include globs of memory if you need to keep a bunch of Workspaces online at the same time, large hard drives if you want to archive projects for years, or even GPUs if you need to work on AI or crypto projects and want some of the CUDA goodness.
Once you have a Host, you can stuff it full of Workspaces or other services like databases, caches, or even remote desktops, and keep them online as long as you’d like. There is a bit more management overhead in that your Host has a fixed amount of resources, and you may need to turn off a service you aren’t using to make room for one you want to use, but that is very similar to what you need to do every day on your own machines.
Is this the right model? I think so.
Everybody uses services differently. What I loved about those earlier cloud IDEs was the fact I could create a new Workspace for every project and just have them all just be there when I needed them. As a consultant, I’ve worked on many dozens of projects. Some big, some small. Some where the client disappears for 3 years only to pop back with a spate of new requests.
I need to be able to be able to jump into a codebase quickly without needing to remember how to get it to work.
I don’t like to think about what version of NodeJS that particular project used, and then need to nvm over to it for that one task. Or where the development database happened to be when I worked on that project. (I go through a lot of computers!) Having it all sitting there in a container somewhere whenever I need it is wonderful.
Under the cloud pricing model, there was always some sort of limitation I’m pushing against. Either you have to pay per workspace, or they shut themselves off after 30 minutes, or you can only actually keep them alive for a certain number of hours per month before hitting overages.
But other people might have different priorities. If you’re just looking to jump in to some quick frontend code quickly, CodeSandbox is a great way to do that, and very affordable.
I’m trying to make RestlessIDE a platform that can serve a daily driver for working developers and their teams. Where we anticipate needs and find solutions to them for you, and bake it all in so that you can just get on with your actual work. And yes, one where you know what you’ll be paying every month.
Conclusion
Any arrangement you come up with will have upsides and downsides. I presented my plan to the Backend Standup crew and they were curious about certain details. “So you’re saying, if I want to have a 4th workspace, I need to rent a whole server?” It’s a very reasonable question, but in context it makes sense. The per-workspace price would be about $10, whereas the smallest host is $15 and can also hold probably 10 more workspaces. 4 workspaces is a slightly awkward amount, but numbers 5-10 will be super cheap!
Frames of reference are important. Coming up with a coherent pricing strategy involves a variety of factors:
- Putting yourself in the shoes of your customers, and thinking through how they will use your application.
- Figuring out where your own costs lie, and making sure they’re covered.
- Understanding what your target market can bear in terms of price, and how they perceive value.
You can’t lean too hard on any one of those without falling over, and possibly getting replaced by someone who understands them better.
Til next time.
(Photo by Pixabay)
Top comments (0)