Fauna sponsored this post.
The Serverless term has never been more problematic. Often when a phrase starts to take hold, the confusion is at its highest point. The basic definition of Serverless is supposedly well understood — it’s Faas (Functions as a Service), right? I’ll write my code in a function, and it will be executed and operated by “someone” else. The running joke is that it will run on a server, in a container.
To me, the term means much more than that.
Serverless-First describes a movement. A desire to reduce the amount of Ops I have to do, reduce the configuration, improve the Time-To-Value, and focus on key features as I speak to my business partner — let me address the user need. Serverless-First means I choose a service for compute, data, eventing, orchestration, analytics and monitoring that is serverless. In 2021, we have moved beyond compute. Serverless is now across the stack. And I want my Cloud Provider to run it — I demand several 9’s reliability and I want pay-per-use. Serverless-First means I will travel at a relentless pace to create business value; I don’t care what’s under the hood (well, I do — but it’s not my responsibility).
But I’d like to re-visit Serverless-First in 2021 and open up the discussion a little. We’ve talked a lot about compute and functions; let’s broaden it out and talk about data, organization and outcomes.
Core Building Blocks
The function (or Lambda) could be looked at as a core building block. But we should view it more broadly; it’s also a core fixing agent. It’s what binds all the parts together. In 2021, I believe we will start to see more higher-level abstractions. Higher-level services like AWS EventBridge and AWS Step Functions proved in 2020 that they are ready. Will we see more higher-order services? The event should be the core building block of Serverless-First systems. Events designed well will be meaningful to customers, and value can be associated easier.
For data, the rise of event-based systems and “micro-transactions” has seen an increasing demand for very different systems to manage transactions. Data analytics has a separate path and an equally challenging journey, but handling customers’ transactions is vital. Trying to scale databases to handle unexpected load will become a standard requirement. As we will discuss later, database services like Fauna, Cosmos DB and Aurora Serverless excel in this space.
The level of expectation for our engineers rises by the month. The Developer Experience must be more efficient and effective than a Formula One pit team. Of course, this is probably different for every single company. It’s a combination of skillset, toolset and process. What is not unique is the developer-centric view we must take — make the job easier for the developer, not the compliance team. Platforms must allow developers to become power-users and leverage the coding skills they have. Approaches like Fauna, CDK, and Serverless Framework all give developers power tools to get to the critical business-differentiating work.
Benefits and Challenges
The Serverless-First mindset is often talked about but rarely defined. The demand for shorter Time-To-Value will naturally result in companies who are comfortable in the cloud taking the next step to Serverless-First. Let’s explore this transition a little closer:
If I come across a “Container team,” a “Database team,” or an “eventing team,” then I would ask each team what their purpose is. If the answer is “we stand up containers”, then this is a challenge. Laser-sharp business focus is required for the demands of digitization in 2021. Every Serverless-First team should be chasing a business KPI. With the reduced operational burden of Serverless, this is possible. It’s okay to have an enablement team tied to something like events or databases, but they should be creating value with Value-Stream teams, not abstracted away from the customer.
We should observe a much greater clarity of purpose in teams with Serverless-First. There should be less “undifferentiated heavy lifting” — much less time spent doing things that are invisible to the customer. Not all timelines will be quicker, but things will feel different.
Finally, the feedback loop will be cleaner. By which I mean things will feel closer to “real agile” or “small a” agile (let’s not talk about Agile). So, not a massive department of 300 people working on something and it takes three months to find out what happened. No, a smaller team that can build and provide feedback in days. It may still take them months to do certain things, but we will observe a faster, lighter footprint as the team moves forward.
There are two significant challenges with cloud adoption. The first is “We are fine on-prem”; but that is well covered, and besides it’s tough to get any cloud or serverless benefits on-prem. The second is “Legacy cloud” — we are in the cloud, but with a lot of legacy implementation. Both are problematic, but the challenge is not technical. Mindsets need to advance quickly; the burn-rate will not reduce until the inertia or technical debt is managed. It’s not a disaster having an older, migrated system — but it mustn’t grow. Remember, it’s Serverless-First, not Serverless-Only. There should be a constant effort to move the architecture forward.
Serverless-First will start to spread beyond the engineering team. There may be different models for Infrastructure, Data, Security, Finance, Training, Audit, etc. The same basic cloud principles apply, but often we need to dig deep and reflect on how well they have been implemented. If corners have been cut on cloud principles, then serverless may expose this. The good news is that it presents an opportunity to move forward. Security is one area that a traditional approach may work for on-prem to cloud IaaS, but it won’t work when adopting serverless.
The Rise of the Managed Service
Serverless-First could also be described as “Managed Service as a Service” or “Backend as a Service”, but let’s get beyond the XaaS model. We need to be thinking about Serverless Architecture, which means we need to consider the entire system.
We have reached a point where we are happy to abstract away core functionality to “cloud platform vendors.” This is the space between a pure cloud vendor and a SaaS company. This is a very niche space that provides high-quality service, world-class functionality, zero operations and a competitive price-point (must be pay-per-use).
Code Is a Liability
The phrase has been about for decades, but it has always been challenging. I think we are at a time when many engineers are starting to understand that business impact trumps everything else. Even if you can code something in five days, you still have to support it. It’s a better business decision to use a service for many reasons. Of course, it depends on what company you work for. Engineers understand that sometimes it is your job to assemble components and create a system. It’s better to be in a position where you can focus and write well when you have to write code. Generating thousands of lines of boiler-plate code is not a good day’s work.
The dreaded word “digital” has made a comeback in 2020. The rate of change has accelerated beyond any expectation due to the unfortunate circumstances around the pandemic. Most business partners are keen to accelerate their digital journey. Our time is better spent in partnership and creating the end state instead of building components that are only marginally better than the managed service you can integrate in minutes.
Amazon famously talks about “avoiding one-way doors”. When you spend considerable time and effort building a component, you have invested and it’s hard to walk away. Using a managed service should be a two-way door; it’s possible to walk back out if your requirements change. A better way to describe this is “evolutionary architecture” — a term that has also been around a long time, but it’s difficult to achieve with technologies from yesterday.
In the modern era, systems need to meet the business need with a much higher demand than ever before. Engineers have a different mindset — we want to meet that business need. The evolution over the past 10+ years now has us where we can trust various components and focus on aggressively iterating forward. The days of pouring millions or billions into an IT roadmap should be behind us. Let’s be smart and stop building the same thing again and again. Let’s embrace Serverless-First as a way to move quickly.
2021 is shaping up to be a big year for serverless and Serverless-First. One of the main challenges we must address is the perception of serverless. It’s a mindset, not a technology. Offerings like AWS Lambda, Fauna, Google Firebase and AWS Step Functions provide incredible capability — have you tried them? Serverless Architecture is going mainstream, and you don’t have to wait. Build a system today, and I promise you, your Time-To-Value will astound you.
Feature image via Pixabay.