Fermyon Adds Database Capability, Automated DNS

Serverless WebAssembly company Fermyon has added a couple of important capabilities to its Fermyon Cloud service and its Spin development environment.

The first is a SQL database service, based on the open source SQLite dialect of SQL. This joins the existing key value store feature, announced previously, to provide another way for developers to store state for their applications.

When developing an application, a local SQLite instance is provided that gives developers an isolated sandbox environment to prove out their code. When the code is deployed, this local SQLite database is seamlessly swapped for a distributed SQLite-compatible database provided by Turso.

“Adding Turso to the mix now means serverless developers can develop full stack applications as well as more narrow microservice applications without involving DevOps,” said Glauber Costa, founder and CEO of Turso, in a statement.

The database service is private to the application, and there are no credentials required in the application code itself, providing a highly secure deployment by default. Developers can't accidentally expose the credentials, such as by checking code into a publicly visible repo, because they never see any credentials in the first place. Security is handled by Fermyon's platform, automatically.

Secondly, Fermyon has added a custom domains function so developers can bring their own domains to Fermyon's Spin. Using a technique similar to how Netlify works, developers provide an apex domain record and Fermyon Cloud handles the rest. DNS records are configured automatically, and appropriate TLS certificates are created using LetsEncrypt.

If developers want to move outside of what Fermyon Cloud and Spin offer and use an external datastores such as PostgreSQL, MySQL, Redis via language libraries and connectors, that's still possible. Yet, while there are some obvious limitations, SQLite has proven to be good enough for a lot of applications that need to store some state in a structured fashion, and in a familiar way.

It aligns with what Ferymon co-founder and CEO Matt Butcher calls convenience-oriented development. “Our approach has really been to look at what developers are asking for? Right? How do we remove speed bumps off of their existing development patterns?” he said.

“I think we can streamline away from the developers so that they don't have to deal with day to day operations in addition to not having to think about it much when they're building the application,” Butcher added.

The automated switch from local to deployed application without changing the code showcases the potential of Wasm's component model. It removes a lot of tedious wiring together of infrastructure components that frustrates developers. It enhances security, making the secure way the default and low-friction way.

It also highlights the value of providing infrastructure services to developers in a way that removes any need to deal with infrastructure operations. If this platform engineering function can provide a seamless experience to developers, it removes a lot of friction as well as enhancing the security and robustness of applications. Why should application developers need to care about authentication credentials when they can be provided by an infrastructure layer? Why should they futz about with TLS certificate automation when it can be handled automatically? Why is it possible for developers to configure DNS wrong?

Many of these functions used to be very difficult to achieve. Automated DNS management is challenging, but companies like Netlify have demonstrated that a better way is possible. Before LetsEncrypt, automated TLS certificate management was much harder and most websites didn't use it. Now most do. Once something becomes embedded into the default way things are done, everyone benefits from the increase in security and reliability.

One risk here is that Fermyon strays too far from what developers want and it becomes a restrictively opinionated PaaS. We've seen similar approaches before, and they have an unfortunate tendency to ossify. In the fast-moving world of software development, a platform needs to be able to adapt to how developers work today, not what was considered best practice a decade or more ago.

If Fermyon can continue to be guided by what developers have already established is a convenient and useful way to work, that should help. The challenge will be, as always, telling the difference between what seems like a good idea at first and what actually is a good idea later on.