Some often see stateless as a path towards scalable and cloud-native applications. Both Stateful and stateless applications solve different problems. But resorting to stateless in every use-case, as a silver bullet, is naïve. Despite all marketing buzz, stateless workloads running in public become very expensive, very quickly.

What’s wrong with serverless?

According to Sachs, serverless is, and that could be very expensive in many new use-cases. If you use AWS Lambda and there is an event for which you call a local Lambda function, the function starts up, and it knows nothing. It has to ask a database for all of its contexts. It makes a bunch of database queries, it does one operation, returns the result and then forgets everything. When you get another event, the entire process is repeated. Again and again and again.

A good example of how things can really become expensive and worst, he gave an example of the smart traffic lights in Palo Alto. It was generating 30,000 data points per second. It was around 30-50 megabytes per second of data for one city. In comparison, Twitter experiences around 5,000 tweets per second. So a little city in California has 10 times the load of Twitter. If that’s too much data to store, it’s even more data to transport.

To handle those kinds of data rates with serverless in the cloud would cost them more than $10,000 per month.

As the data rates increase, it could become very expensive due to the repeated round trip through the database. It can get even worse if you want to build autonomous applications that are self-contained and if you want to go to the edge.

On the contrary, stateful is cheaper, it’s faster to develop and it has much higher performance.

Building a stateful platform with Stateless advantage

Founders of Swim Inc. have been building platform and architecture for distributed and embedded systems at Sensity Systems, which was acquired by Verizon for their ambitious smart city projects. The work, Sensity creators did make them fully aware of the pain-points developers face when they build such applications.

“We were converting outdoor lighting infrastructure to smart lights with cameras and sensors. They were building massively distributed lighting control and energy management applications, said Christopher Sachs, Co-Founder and Chief Architect at SWIM.AI, “What we found was that the traditional model for building apps that worked great for database-centric cloud applications didn’t work very well for real-time intelligent, massively distributed applications.”

They had to strip out the database and message brokers because they couldn’t keep up. They realize that there was a general problem that then we’ve been building software in the same way for 30 years, everything is stateless and backed by databases. That makes sense if it was really just about serving up documents. But it doesn’t work if you have highly dynamic, highly distributed applications. The current model became more of a burden than an asset to scalability.

The team set out to build swim, a new software stack from first principles because the complexity of building distribution software is out of control. When we looked at it from first principles, we saw no reason why it had to be so expensive and so complicated.

They ended up with a rather unique architecture that was stateful. Swim was born.

Swim is an end-to-end platform. It consists of a small, two-megabyte software stack that is fully distributed. It provides for its own persistence; it uses a software transactional memory system that provides for its own persistence without using an external database. It does point to point messaging, without having to go through an external message broker. It has performance analytics functions without having to use a job manager like Hadoop and business logic without having to use an external application server.

Swim provides all those capabilities in an integrated stack, that developers expect from entire cloud

On top of that, Swim also has a real-time UI framework which makes it easy to build end-user applications. We also have a version of Swim that runs in web browsers and we have real-time UI widgets and make it easy to visualize real-time data.

Whether its traffic lights, multiplayer games or transit systems, Swim makes it all very efficiently with its integrated stack running on inexpensive Raspberry Pi cluster. It would cost pennies per month.

It also improves performance. The simple fact is that CPUs operate at nanoseconds, whereas networks operate at milliseconds to hundreds of milliseconds. You get the obvious performance boost with Swim, as you don’t have to wait on the network for everything.

Going Open Source

Swim Inc decided to open source all of this work under a permissive license so anyone can take the stack and use it as they please. However, they have also build a business model around it where customers can buy Swim based Solutions, with much needed extra features including automatic scaling, monitoring, and management; comprehensive usage & performance metrics; dynamic load balancing; customizable advanced security policies and Expert support & guidance.

You can build if you want, or you can buy if you need.