I had a front row seat at Microsoft to watch the first two application model transitions. Early mainframe and minicomputer systems were monolithic, with data storage, application code, and terminal services all in one box. When the microprocessor and Ethernet networks emerged during the 1980’s, they enabled lower-cost computers to work together and communicate over local area networks. PC’s and Unix workstations began to connect to servers, leveraging a new, multi-machine, client-server programming model for business applications. Client-server applications emerged with a graphical user interface coupled to a back-end SQL database (frequently Oracle Database or SQL Server).
Client-server applications were built very differently from monolithic applications, with the presentation code running on the client computer and business logic on the server, typically encapsulated within SQL stored procedures:
FaunaDBI watched the client-server journey begin over 30 years ago, while working on my first Microsoft product, the Ashton Tate/Microsoft OS/2 SQL Server.
Client-server applications flourished for only a brief period but they created a new generation of easy-to-use, graphical applications that delivered computing to hundreds of thousands of small businesses for the first time. The combination of Visual Basic client applications calling SQL Server stored procedures built the Microsoft server business and created an entire industry of software vendors and value-added resellers. While client-server has been a legacy approach for over 20 years, many businesses continue to run updated versions of these same client-server applications.
Client-server became legacy because of the Internet and the web. Client-server applications were built for local area networks using chatty, proprietary protocols that worked in a local-area network but were inappropriate for the long distances required by the Internet.
The Internet and three-tier applications
In the spring of 1995, Bill Gates redirected Microsoft’s focus to the Internet with his famous Internet Tidal Wave memo. At the time, I was running Windows NT Program Management so I attended many “Billg Internet Planning” meetings. This was the beginning of a tumultuous period for Microsoft and I watched and participated in everything — the good, the bad, and the ugly. Together with Microsoft, I learned many lessons from the Internet experience and the antitrust episode that followed. One of the important lessons is how technical revolution creates new win-win opportunities for everyone.
The revolution of the global Internet brought a new generation of open standard protocols and formats. These new technologies required different infrastructure. Initially, simple web servers delivered static websites. But commerce and other applications quickly drove the emergence of a new, three-tier application model:
FaunaDBThe three-tier application model combines a web server that speaks Internet protocols with an application server for business logic and a database. The database, app server, and web server are located within a single data center or cloud region. They work together to create the fully formed web page, which is then rendered in the browser on the client. In practice, client-side JavaScript usually provides local client interactivity, at a minimum for field validation. The level of local browser interactivity has increased over time and JavaScript has driven key industry standards such as REST for remote APIs and JSON for data formats.
Unlike client-server, the three-tier application model has aged quite gracefully and is now used to provide API services in addition to web pages. The evolution of a standard API interface based on REST has enabled complex business logic to be encapsulated within globally available services that are callable by any application with the appropriate security credentials. The three-tier application model is commonly used to provide REST API services:
FaunaDBThe browser in the sea of serverless APIs
When services are delivered as an API, automatically scaled within a cloud, and priced based on usage, they are known as serverless services. With severless, customers don’t need to manage the server infrastructure. Serverless services are available to any appropriately authenticated device, anywhere, and they are billed based on a relevant usage metric.
Today, we find ourselves in a connected world with a variety of powerful mobile and portable computing devices. All of these devices now support compatible browsers that are capable of providing an end user experience that approaches or in some ways exceeds the quality of a native application on that device. An example of this is Google Docs, which uses the browser to provide a seamless, collaborative experience across devices.
At the same time, new SaaS applications are being reimagined as a complete set of Internet-compatible APIs that deliver an ever expanding variety of different services using usage-based pricing. Payment, content management, logistics, order management, 3D printing, you name it, they are all becoming APIs that are callable from anywhere: other servers, mobile applications, and browsers. The cloud accelerates this adoption by enabling serverless computing, and new tech companies like Stripe, Twilio, and Algolia have emerged as leaders in this new class of usage-based services.
After a long evolution, the browser has become a ubiquitous, programmable client that lives in a globally connected world of serverless APIs. This combination of a ubiquitous client together with a sea of serverless APIs has enabled the new, client-serverless application model:
FaunaDBIn client-serverless, the end-user application runs on the client and calls a wide variety of services. The client handles the presentation while the business logic is encapsulated within callable services. Native iOS and Android applications are examples of client-serverless but the browser is where the action is and Jamstack is growing rapidly. As client-serverless matures, it will grow to support consumer and business applications of any size or complexity.
Client-serverless also applies to servers and microservices that are orchestrating business processes. In this case the server application or workflow engine acts as the client making calls to remote services using serverless APIs.
Jamstack and the client-serverless database
The JAM in Jamstack stands for JavaScript, APIs, and markup. In a Jamstack application, the browser markup is static HTML and is readily accessible from a nearby CDN. The application is instantiated by JavaScript within the browser and the presentation logic runs as a JavaScript browser application. The client application makes calls to remote service APIs. Jamstack delivers a great experience for any client, anywhere, and enables a highly productive developer workflow.
The Jamstack approach enables very powerful client applications to be developed. Like all applications, Jamstack client-serverless apps create data that needs safe, secure, transactionally consistent database storage. But unlike three-tier, Jamstack applications require a secure database that is available anywhere on the Internet. Existing SQL and NoSQL databases are all built to sit behind an app server, so they are not directly accessible to Jamstack client applications. No existing database meets the requirements needed by the new generation of client-serverless applications.
Jamstack requires a database that was built for the client-serverless world. In a sea of serverless APIs, what Jamstack needs is a serverless data API.
Fauna is unlike any other database. Fauna was designed to provide secure, anywhere access database services to any client. It delivers strictly serialized consistency, the highest level of transactional consistency to ensure application correctness, and it provides this as a global, ubiquitous service using a protocol inspired by the state-of-the-art Calvin algorithm. Similar to client-server stored procedures, business transactions using Fauna are performed by user-defined functions within the database. Fauna UDFs replace stored procedures, and while Fauna is a relational database, it doesn’t use SQL. Instead, it exposes a flexible document model that is appropriate for JavaScript developers and it uses the industry standard GraphQL API to efficiently return data.
Serverless APIs are redefining what is possible for today’s application developers. These possibilities are accessible to businesses modernizing their current systems as well as those building completely new client-serverless applications. For example, Fauna customers like Nextdoor and Hannon Hill are using serverless back ends to scale their existing infrastructure for global reach. Boutique studios such as Matter Supply and Bejamas as well as startups such as Faros are building entirely new experiences with the serverless, Jamstack, and Fauna ecosystem.
Every revolution in application architecture has spawned a new database that enabled developers to build applications that were not possible before. I am excited to help the Fauna team deliver the database that was built for the client-serverless world. Fauna is the data API for client-serverless applications.
We are just beginning to enter a new world of ubiquitously accessible client-serverless applications. Just like the client-server and three-tier architectures did, the client-serverless application model will create tremendous opportunity (and disruption) for every kind of customer and vendor in the industry. A new generation of developers is leading the way with Jamstack.
Bob Muglia is a business executive and R&D specialist. He was the CEO of Snowflake for five years, starting in May of 2014. Prior to Snowflake he spent two years at Juniper Networks and 23 years at Microsoft. Early in his career, Bob helped to start the SQL Server business and he managed Microsoft divisions including Visual Studio, Office, and Windows Server. From 2007 to 2011, Bob was the president of the Server & Tools Division, growing that business to over $17B.
—
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.