- What problem are you trying to solve with this?
- Cloud computing has completely changed the way people build software. It has given us building blocks that can be composed to build complex applications in a fraction of the time it used to take.
At the same time, however, the bar has risen. Global users aren't just for enterprises, traffic and data volumes are higher, and customers expect zero down time service. There is also more pressure than ever to get to market quickly, and to respond to changing environments.
Doing this all yourself on a cloud platform is certainly possible, but it requires a dedicated staff of skilled engineers to do it. You've got to think about deployment pipelines, monitoring, logging, tracing, backups, redundancy, network configuration, security, cost management... the list goes on.
Thousands of businesses are investing in solving these problems but the reality is that their customers aren't paying them for this - they've just become table stakes. We think the problem is that the cloud is still too low level. It was the step from assembly to C but what the world wants is Ruby on Rails... and that's what fold is trying to do.
- Don't cloud providers like AWS, Azure or GCP already solve the problem?
- They do go part of the way to solving the problem, of course! Compared to managing your own hardware setting up on the cloud is much quicker and easier. While they completely handle the logistics of infrastructure management though, they don't remove all of the operational overhead.
For example, you don't need to know how to acquire and rack in a server, but you still need to know exactly what resources you require and how to distribute your application across them. You don't need to know how to build a local network out of switches and cables, but you do need to understand networking concepts and how to configure one. These are skills that most teams don't actually have, and it shouldn't be a requirement for every organisation in the world to develop expertise in these areas.
For many organisations, serverless is a step in the right direction, but it leaves much to be desired. It's difficult to develop and test things locally and your code typically ends up quite tightly coupled to the serverless environment it was written for. This is because most serverless products are leaky abstractions. You might not have to think about servers, but you still need to think about infrastructure - i.e. the platform you're building for. This is why serverless applications end up coupled to the platform they were built for.
Last but not least, the cloud developer experience leaves a lot to be desired. We've all been there, on attempt 14 with a 20 minute cycle time and the pipeline still showing red. No one wants to do that for a living.
- How is this different from PaaS offerings like Heroku?
- PaaS offerings like Heroku do a great job of making infrastructure easy. They go a long way to reducing the operational overhead of deploying and managing applications. The key difference is that fold doesn't try to make this easy, it tries to completely remove it from the list of things you need to think about.
Fold tries to do this by creating a complete end to end workflow for development and deployment. You can build and run your services locally and they will behave in the exact same way as when they're deployed.
Completely removing the operational concern from your backend opens the door to some really interesting ideas further down the line. For example, it should be possible to pick the appropriate infrastructure based on your application usage and automatically optimise it for you.
- Doesn't using a tool like fold risk vendor lock in?
- Fold aims to be as unobtrusive as it can while still being able to infer your infrastructure requirements. Currently, you interface with it through an SDK which does show up in your code. This does create a risk of vendor lock in and we would love to find a way to improve this.
This risk is mitigated in two ways at present. Firstly, fold does not have any opinion about how you structure your application. It only requires an entrypoint that is built with the fold SDK. The entrypoint simply wires up components you have written in a way that fold can understand. This makes the changes required to switch to a vanilla HTTP server or similar very minimal.
Secondly, fold services and their dependencies are configured using Dockerfiles. This makes it easy for the fold platform to run the application anyway it likes, but it also makes it easy for you to do the same.
- Why should I risk using a new solution like this?
- Fold is still under development and will certainly lack in features and polish when compared to mature offerings. What we can do right now that others can't is provide attentive support and advice to help you get your application up and running. We would love to talk to you about what you're trying to build and want nothing more than to make the tools that help you build it.
So even if you don't stick around for the long run, or fold doesn't quite cut the mustard yet, we think you'll get a lot of talking to us and trying out the platform.