Cloud Concurrency Endgame
Cloud Functions may be the future of computing, but today they suffer from big problems.
The State of Concurrency
The most impressive concurrency model of all-time is found in Erlang/OTP. Erlang is a programming language, and OTP is a framework; together, they help developers create massively concurrent and fault-tolerant distributed systems. (aside: Elixir is a re-imagined front-end for the Erlang VM; check it out!). Erlang allows programs to spawn and manage thousands of incredibly lightweight threads: on the order of 100 bytes each. It’s given the development world a taste of massive concurrency with high logical connectivity and testability.
The State of Cloud Computing
Cloud computing is evolving rapidly. While cloud computing originally meant provisioning a physical computer (Amazon EC2 for example), the standard unit of cloud computing is becoming smaller. We’ve shifted from physical machines to virtual machines to containers. Likewise, our applications have shifted from monolithic architectures down to services down to microservices. Today, we are seeing the rise of Cloud Functions (AKA Functions as a Service, FaaS, or ‘Serverless’ Computing).
Cloud Functions are literally functions that run on servers; they are effectively nanoservices. Cloud Functions are incredibly lightweight and stateless, so they can be run on an as-needed basis.
If and only if a Cloud Function is triggered, it runs in a new thread (more or less). If your function isn’t running, you have zero threads running. If 1000 of your function are running, then you have 1000 threads running. This would never be possible in a container service because containers are much too expensive and heavy-weight. With Cloud Functions, you aren’t spawning anything but a function call, and almost all the overhead is wiped away.
However, Cloud Functions today are a far cry from Erlang’s concurrency model. We may be able to spawn threads on Erlang levels in the cloud, but we aren’t yet able to manage them like Erlang can. Erlang allows developers to manage concurrency across many functions in an extremely fault-tolerant way: it’s the ultimate in depth. Cloud Functions today only offer the ultimate in breadth: practically unlimited scaling at the cost of extreme logical disconnect between functions and low testability.
Cloud Computing in 2030
In the next decade, I assume that we will move more and more towards Cloud Functions. I predict that our coming dependence on Cloud Functions will encourage the development of tools to help this transition. Stateless (functional) languages will allow these systems to be built on a language level, and tools will automatically deploy these systems in an ideal way. Eventually, these tools will get so good that our applications (from programmers’ perspectives) will begin looking a like monoliths again; however, stateless languages will mandate that these applications can be destructured into Cloud Functions. We will see an era of distributed applications that take an optimal amount of resources with development tools that make it automatic.
Cloud Computing in 2020
I have a very optimistic view of Serverless. Serveless attempts to make Cloud Functions easier to develop by increasing logical connectivity. It feels like it comes from 2020, but not quite 2030. It’s out now; check it out.