Cloud Native is Serverless-First
Inevitably, one of the first questions I field from new clients is, “Why do you recommend Serverless over Containers?”. My initial response is that I recommend following a Serverless-First approach, so that we can make this architectural decision with as much information as possible. I then add that we can make this decision per service as well.
Cloud Native is lean and one of the lean principles is to defer commitment as long as possible. I certainly won’t tell you that you can’t build your cloud-native system with containers. But in most cases you probably don’t need to. First, you may not even know for certain if your value proposition is even worth building. Second, you probably don’t know which services will actually benefit from containers and which will not. So let’s experiment with real users before we commit to a decision.
If you are new to containers, then it could easily take 6–12 months before your team can run workloads in production with confidence that they wont accidentally take down the entire cluster. This is definitely not a lean timeline. On the other hand, a serverless-novice team can put functions in production almost immediately. These may not be the cleanest, most cost-effective functions, but at the early stages of a product that is not the objective. At this point we want to be lean, move fast, experiment and learn.
Serverless-first is lean. A team can quickly become self-sufficient because the power of serverless tooling enables them to fully automate every last drop, so they can iterate daily or even hourly. The team can skip the learning-curve and take control of the full-stack, with confidence that it will scale and wont collapse, because they are leveraging fully-managed services, such as AWS Lambda, Kinesis and DynamoDB.
But the decision to go serverless-first is not final. It is a reversible decision, because serverless architecture is disposable.
Again, if you spend 6–12 month just trying to get out of the starting gate with containers, then you will likely have become emotionally invested in that approach because of all the time and effort that was involved to make it work. As a result the decision to use containers is usually not disposable. Over and over again, teams tend to double down on unworthy product ideas, because of the upfront technical investment.
Serverless-first requires little upfront technical investment. It is completely disposable architecture. We don’t pour our hearts into learning how to run technology. We focused on validating the value proposition. Once we learn, we move on. It’s just code.
Hopefully the value proposition proves worthwhile! If it does, then there is an opportunity to revisit previous decisions with more knowledge and likely a bigger budget. Maybe some small subset of the services is worth refactoring to containers or maybe not. In my experience the vast majority of services, if not all, are best left serverless.
After discussing serverless-first, the questions usually turn to the likes of, “Doesn’t serverless have limitations?”, “Isn’t serverless expensive?”. My short answer is, only when trying to use it in the old ways. The longer answer is, not if we go Event-First, which I will cover in further postings.
For more thoughts on serverless and cloud-native checkout the other posts in this series and my books: Software Architecture Patterns for Serverless Systems, Cloud Native Development Patterns and Best Practices and JavaScript Cloud Native Development Cookbook.
