because writing is clarifying

because writing is clarifying

Subbu Allamaraju’s Journal

Penalties and Purgatory

I spoke on this topic at the ServerlessConf New York on October 8, 2019. Below are the slides and speaker notes. The thesis of my talk is to discuss a few questions:

  1. The community universally seems to agree that the combination of functions, events, and fully managed cloud-native services makes serverless what it is. Is this conclusion premature? What can we learn from contemporary solutions like Kubernetes?
  2. Can code size reduction alone into smaller deployable units help reduce the time to value? Is there an inflection point of such reduction increasing MTTR?
  3. How to do you make a case for tech adoption, and why it essential to understand how your business works?

Given that is is a 20 min talk, it stayed high level.

The Setup

Imagine you discover serverless today? You will find that the programming model is simple. You’re shipping small functions independently. This programming model is a microservices style taken to its logical conclusion. Then you will find that there are no servers to provision or manage radically simplifying the ramp-up and operational cost. Then you will find that the runtime model keeps costs transparent and follow the demand.

As promising as this direction is, it is important to challenge ourselves a bit and ask a few questions.

Slides and Notes

This talk grew out of my experience leading cloud migration at the Expedia Group. I had a unique opportunity to burn my opinions several times through over the last three and a half years. I had a chance to question my own beliefs, discard several of those, and form a few simpler ones. Hence you will find me taking a contrarian point of view on this stage.

Belief: Serverless is the future

Most of us at this conference, including those promoting alternative technologies, do believe that serverless is the future. Five, ten, or fifteen years from now, we can all look back to reminisce that we were there when it all started.

The programming model

But then let us look at the modern view of the serverless programming model. The programming model today consists of three things:

  • Functions as primitives in a constrained programming runtime to run stateless computational logic
  • Cloud-native services to do the heavy lifting for a wide variety of middleware services and state
  • Events and remote-procedure calls to glue everything together

Is this all we need to embark on the serverless journey? Back in 2019, I posed this question to someone in a cloud company, and the person answered yes. I didn’t believe it then, and I don’t think it is even now.

Why aren’t we there yet?

Serverless adoption has been on the rise. Where I work, we continue to witness an almost linear increase in function invocations over the past two-three years. We also hear AWS Lambda continues to enjoy wide-spread adoption from a large variety of organizations to solve unique and innovation problems.

Yet, why is the world not moving to serverless quickly enough? What could be holding us back?

Counter belief

Let’s examine a counter belief that sees serverless as an evil capitalistic pursuit to let cloud providers take all your code and data, and lock you into their claws. Though it is easy to make fun of this belief, this is real. Fear sells.

What properties can we borrow from Kubernetes?

For those that buy into that point of view, the alternative is a solution (Kubernetes) that provides distributed systems primitives on boring infrastructure primitives to let you run a variety of workloads on top.

While it is tempting to make fun of this approach in serverless conferences and meetups, how about we ask ourselves a simple question — what properties can we borrow from this approach? What can we learn, instead of picking a side? I won’t answer this myself, but I would encourage each of you to explore.

Landscape

Let’s look at other contemporary beliefs driving our thinking.

Belief: Small is better

We’ve been pursuing this idea that small is better through the adoption of microservices over the last 7–10 years. We’re witnessing tremendous gains of developer agility and lower time to produce value. This model has allowed every team to move at the pace they need to create value for their customers. A function-based programming model takes this approach to its logical extreme, where you’re constrained to write nothing but functions.

Code size and time to value

Yet, does a further reduction of code alone will continue to reduce the time it takes to provide value? I don’t think so. I believe there is an inflection point beyond which you may not see a further reduction in time to value.

A not-so-uncommon phenomenon

Here is some evidence from my experience studying production incidents. With thousands of applications running in production environments, I came across several examples where a fault in one part of the environment has an indirect impact on another part of the environment several layers away. Such incidents take time to detect and remediate.

Comprehension penalty

Without additional constraints, microservices-based architectures can lead to reduced comprehension of production environments, which can widen the gap between “as designed” (our assumptions of how things are supposed to work) and “as it is” (how things are working in the real world) states. This gap can contribute to increased MTTR.

(For more discussion on “as designed” and “as it is” states, see Forming Failure Hypotheses.)

Where are the app primitives in serverless?

This observation brings us to the question — have we found all the runtime primitives for a serverless future? Where are the application-centric primitives for:

  • run-time boundaries between applications, with clear demarcation of private and state and behavior?
  • service interfaces
  • non-fate sharing architectures?

Are there aspects we can learn from others? Are we throwing away most things we learned through the last 10–20 years? I don’t know the answers to these questions, but I believe that we must continue to explore.

OurCo vs the OtherCo

Let’s switch gear to tech adoption hurdles. Most developers I speak to share this belief privately. We often hear about tech adoption success stories at conferences and blog posts, while in reality, most of us worry that the places we work at don’t seem to be adopting the latest and greatest, including serverless. What could be going wrong?

Tech investment cycles

Imagine you went through an investment cycle (people, money, and time) to build a product. Sometime later, a tech innovation comes along. You may have to wait for your next investment cycle to be able to lay hands on that tech innovation. The point to recognize is that your investment cycles may not line up with the tech innovation cycles, and it is okay.

Multiple generations and migrations

The second hurdle we run into older code that does not seem to go away fast enough. Here is what usually happens.

You have a product built yesterday, which is producing value for your customers. It is mature, functional, and yet complex to manage as it has so many band-aids to keep it working. You get upset with this complexity and want to build the next-gen to incorporate all the learnings from the product you created yesterday. But you’ve not finished yet. You might still start to experiment with new ideas.

Survival penalty

The longer your company survived, the more generations of systems that you accumulate. You will be able to retire some, but those too take time. This phenomenon is the natural cost of staying long and going through multiple innovations to run any company. You need to develop business acumen to get comfortable with this.

Fear, anxiety or escalation won’t help

As developers, we tend to resort to fear, anxiety, or escalation. We worry about our teams not adopting the latest and greatest. We hope that some senior leaders at your company turn your wish into a dictum. You desire to be able to push people to adopt the ideas you believe. But these rarely work.

Influence can help

Influence can help. But how do you influence?

Understand how your business works

To be able to influence, you must learn to understand how your business works. Your business is typically turning a few things through a business model to produce value for your customers. The value may be revenue or some other benefit that your customers care about.

To influence, ask the following questions:

  • How does your business work?
  • How does it generate value?
  • What is your company currently pursuing?
  • How can you contribute to that pursuit?

Once you find answers to these questions, align yourself with that pursuit.

Conclusion

Where does this leave us?

First, stay humble. Don’t get attached to the side you picked. Picking sides may be fun and entertaining, but those don’t matter in the long run.

Second, prefer faster, better, and cheaper as much as possible.

Third, challenge the cloud primitives offered to you. No cloud provider holds the keys to all innovation.

Finally, align yourself with value generation to drive technology adoption.

Thank you

Thank you, ServerlessConf NYC.

If you enjoyed this article, consider subscribing to my journal.

See Also