So you've got an innovative idea for a platform that will revolutionize how people build their products by automatically handling many core elements for them, allowing them to move faster with fewer burdens slowing them down? That's great – go get funding! Not so fast, because what you're proposing is a Platform-as-a-Service (PaaS) product, and that comes with a big responsibility. Your customers will be utterly reliant on you for their businesses to survive, and if something happens to your platform they could be left stranded.

This is a challenge that every PaaS product has, and today I want to talk about how we at Encore reason about it and the solution we've decided to go with.

The Challenges of PaaS Integration

In the tech world, there are numerous PaaS products that range from invisible to deep integrations. Think of this as a scale going from no lock-in to the deepest vendor lock-in you can imagine, like being reliant on a custom programming language for instance.

An example of an invisible integration would be Fly.io. It provides excellent hosting for your applications, providing databases with no code changes required to your app – just add some configuration to point your application at its database. If you've deployed to Fly and they suddenly go out of business, your application can easily be moved to another platform – just backup your data, change your configuration files, and deploy onto a new platform. This might only take you a couple of hours to do.

An example of a deep integration would be AWS, mainly because the services on AWS require you to use their APIs. For example, to build an event-driven application you need the ability to send and receive a message asynchronously. This means you have to get the SNS and SQS client libraries for the language you're building in, and design your business logic around their limitations.

Now if you want to move from AWS to GCP, you have to rewrite the parts of your application that use the event-driven architecture and any other AWS APIs that crept into your codebase. Depending on the size of your application, this could take in the range of weeks to months to do.

Fundamentally this is the difference between invisible and deep integrations. Invisible integrations solve high-level problems for you, and solve them well, but are fundamentally limited in how much they can do for you. Deep integrations can solve the same high-level problems, and much more beyond, but often require more highly specific code to be written against them.

This is the category where Encore falls, we are a deep integration PaaS product. This is because we rely on you using our API abstractions in order for Encore to provide a painless way to deploy your application to any environment (and cloud) with all the required infrastructure provisioned and configured automatically. (If you want to learn more about Encore check out our docs.)

Untangling the Fear Factor in PaaS Adoption

Building on top of an invisible PaaS is often a no-brainer for a lot of companies. It solves a problem for them straight away and doesn't have any real vendor lock-in. This means they can move off it with a minimal amount of effort in the future.

However, the second you start looking at a deep PaaS, all bets are off. Businesses will be very cautious about building on top of these, and go through a lot of rigorous "vendor evaluation" to ensure they have the guarantees they need to build on top of you. Because if they integrate deeply and your product disappears one day, it might be enough to kill their entire business – as their customers will have gone somewhere else by the time they can rewrite their applications.

Think about the last time you were picking where you were going to host your systems in the cloud. Did you look at AWS and GCP? – Of course, you did. Did you consider the new startup based out of Brighton, UK, called CloudlyBeaches? – Probably not, why not? (Ignoring the fact I just made them up.) I suspect it's because you wouldn't trust they would be around in 5 years time.

This really is the crux of the matter, the big players in any industry who have been around for decades have implicitly earned our trust that they will still be there for decades to come. Whereas new companies haven't proven themselves yet, and the smaller the company the less we're willing to trust our fate on them.

Another fear of deep PaaS products is often the question of them not being flexible enough. That one day you'll hit a roadblock where the product doesn't support something you need to do, and then you're stuck with a lengthy migration off them.

Large providers have the scale that suggests they would already have built every option you will need into them, or will already have a documented workaround on Stack Overflow (or their own blogs). Whereas smaller providers might not have the momentum behind them yet to have that documentation in place, and they certainly won't have every bell and whistle in place yet.

This is what deep PaaS startups, like Encore, need to really solve for and build into their DNA from the start. Otherwise, they will never be able to compete with the incumbents.

Open Source: The Silver Bullet?

Our solution to these problems is three tenants that we follow in everything we design:

1. We build everything required to run our customer's applications in the open. We even provide a how-to guide on how to migrate away with a simple one-line command to build a docker image of their backends.
2. We ensure that nothing stops our customers from directly using any "unsupported" cloud service by simply bringing in their API library and setting up the infrastructure for it themselves. Exactly like they normally would if they weren't building with Encore.
3. For production use cases we host nothing. This means every part of our customer's applications, and all their data, is hosted within their own cloud accounts in GCP or AWS.

This means, if we were to disappear tomorrow their business would still be up and running without us, and they could continue to build new versions of their backends and deploy them without our help.

We believe this model provides the required safety net for businesses to build systems on top of Encore and get all the benefits, without the normally associated PaaS risks. The model ensures that, in an event where we are unable to support them or provide the exact functionality they need, they are free to either take their time to migrate to a different solution or contribute changes to the project to solve their own problems. Or they can even fork Encore and build the fork out in the direction they desire.

*If you feel companies don't like using open source and see it as a risk, may I just point you at this XKCD.

Proprietary Components: Adding Value Without Lock-In

However, being fully open source carries a huge business risk to your own company. – Why would people pay you when they can just run the code themselves?

This is where we believe closed-source components come in as a complement to the open-source core. To create meaningful revenue, you need to provide huge value-add with a proprietary code base. Something which the customer will want to pay for as it improves their iteration time, prevents outages, reduces bugs, makes it simpler to operate cost-effective cloud environments, etc. Basically it needs to reduce business overheads, increase productivity and effectiveness, and ideally provide meaningful cost savings as well. All in all, we believe a paid product needs to offer at least a 10x return on investment to be viable.

This is a tricky thing to solve without breaking the three tenants we listed above – that whatever we provide in the proprietary components of our PaaS can't be mission-critical to the running of their application.

At Encore, we believe we've come quite a long way toward providing meaningful value with our closed-sourced components, without impacting the running applications. (Don't take our word for it though, see what customers are saying here.)

For example, Encore's systems for provisioning, configuring and deploying infrastructure in your cloud account, based on the static analysis performed by our open-source compiler, are not open-source. The value add Encore provides here is removing the need for developers to write infrastructure provisioning scripts, such as Terraform, and it gives them quick and free preview environments for all pull requests without any manual configuration needed.

Another example is how Encore automatically captures full traces for your applications and provides access to traces both locally and from our cloud dashboard. This is something you would normally have to set up and maintain manually, using something like Jaeger to visualize.

However, none of this is mission-critical or creates a hard dependency on Encore. You can still manually maintain provisioned infrastructure in your cloud account, create scripts to manage your own preview environments, and set up your own observability infrastructure if Encore becomes unavailable to do it for you.

I.e. we've taken away large amounts of undifferentiated work, but in a way where you can start do to it yourself if you want to. This means that if Encore were to disappear, most of our customers would only have a large increase in DevOps work. This can be painful to be sure, but it can be managed by moving some developers off product work and onto platform work, and eventually hiring dedicated platform engineers.

Trust and Transparency

By all indications we're seeing that this approach to reducing the fear companies have of new PaaS products is working. Ultimately we hope it gives customers assurance that we're building a product they can depend on and that they can out-survive Encore if they need to. It enables a high level of trust without requiring a decades-long track record.

But gaining trust is of course only half the story for any PaaS. Once you've got customers to trust your platform, you need to maintain it too! This means being transparent about your failures and shortcomings. And it means setting realistic expectations. So if a customer asks you for some feature, don't just say yes to please them. First understand why they need it, how important it is to them, and then be transparent about where it realistically fits in your product roadmap. – Your customers would much prefer you say "No, sorry we can't support that.", rather than facing the disappointment of saying "Yes we'll get that out next quarter!" and then you never do it.

At the end of the day, your product needs to be great and meaningfully improve the lives of your customers. But now you have a path to earn their trust so they will be more likely to come and buy your product. And the more people buy your product, the more credible and trustworthy you become, and you enter a positive feedback loop.

If all goes to plan, you survive for decades and become the incumbent that the new plucky startups are trying to dislodge!

Your Feedback, Our Growth

I hope that this blog post has been useful to you, or at least interesting to read. The challenges of building and relying on PaaS products are real, and shouldn't be downplayed. For startups like Encore, addressing these issues upfront is crucial. We've opted for a model rooted in open source, which we believe reduces lock-in fears and provides a strong foundation for our users' applications.

However, this conversation doesn't end here. There are multiple perspectives, ideas, and solutions in this space, and we want to hear about them. Our ultimate goal is to foster a PaaS ecosystem where innovation thrives, and risks are appropriately managed. This doesn't mean just building and delivering Encore — it also means listening, learning, and adapting.

So whether you have thoughts on our approach, your own experiences, or ideas for a different path, we'd love to hear them. Join us on Discord and let's keep this dialogue going. Because it's through these shared insights and discussions that we can truly grow and learn from each other.

About The Author

Dominic is a founding engineer at Encore with a decades-long background in building large-scale distributed systems at fintechs like Monzo.

Dominic regularly writes about Go, distributed systems, and backend development. If you enjoyed this blog post, you should sign up for our newsletter to make sure you don't miss future posts.