Build What Matters

I'm at the serverless architecture conference in London this week. It's great to be around some of the brightest minds in serverless. I've met some friends I haven't seen since re:Invent and made some new ones as well.

As I was sitting in a session earlier this week I began to think about the content I've been seeing lately around serverless. The majority of what I see is either a getting started tutorial or a highly advanced, insightful post that takes years of practice to reach. It's great content on both ends of the spectrum, but it leaves many builders in that middle ground out of luck.

If we follow the beginner tutorials over and over, our app capabilities might not grow with the demands of the product. If we follow the advanced guides too early, we end up with overengineered and prematurely optimized code that's prepared for situations we might never run into. So what do the rest of us do who aren't beginners or super-advanced serverless engineers?

Build what matters.

How Do You Know What Matters?

Simply put, what matters is solving your business problem. Specifically, what can you do to solve the business problem in a different way than your competitors? What is your value-add that makes your solution better?

Determining how you're going to uniquely solve a business problem is infinitely more important than having self-healing, optimized serverless code right out the gate. Software is never done. Getting into a mindset that you'll incrementally improve it over time is the best thing you can do once you start venturing beyond the introduction to Lambda courses.

I recently saw a tweet talking about a presentation from Boris Tane where he was talking about incremental delivery.

The message in his presentation was to deliver a continuously better vehicle. Instead of starting off trying to build a car and spending months and months building it from nothing, start small. Deliver a skateboard. Then improve the design and deliver a scooter. Then a bike. Then a motorcycle. Ultimately your expertise will develop enough that end up delivering a higher-quality car in less time than if you started with that as your goal.

By starting small and delivering something that solves the business problem quickly and easily, aka delivering a skateboard, you get your solution in front of your consumers early. Plus, you build your expertise in the problem area. This expertise helps drive meaningful design decisions that will ultimately impact not only the customer experience but also the architecture of your final product.

Starting Small

I've written several times about the importance of iteration. I've even written about my own journey with iteration in serverless. The best way I've found to be successful is to do it, do it right, do it better.

Solve the business problem first. Be scrappy. Go quick and dirty. Learn about what it takes technically to solve the problem.

Then, make it ready for long-term production usage. Instrument it with observability in mind. Work out the defects. Optimize the code.

After that, add to it. Add features to your already strong application. Make it better with the lessons you've learned. Enhance the tooling to make it easier to support.

Let's take an example.

In November 2022, Luc van Donkersgoed was on the Real World Serverless podcast talking about how PostNL implemented their event-driven architecture. He described how they built a custom event broker to validate and route events to consumers. They built their own schema registry that managed breaking changes, event versioning, and tracked how many consumers subscribed to certain versions of events.

It was (and still is!) incredibly impressive. When I heard it, I wanted to build the exact same thing right away for the product I was working on. I had a similar use case and it was already a proven pattern, so why not?

Well for one, my team didn't have the same level of experience as Luc's team. The domain expertise it took to get to that point took years to develop. So I started small.

We could use EventBridge natively to start with. There was no need to build our own event broker. We were just getting into supporting an event-driven architecture, we needed to get our comfort levels up and let the AWS-managed service take the wheel for a while. Simple publishing and subscribing to EventBridge events was our skateboard.

After we were comfortable with asynchronous workflows, we could then start validating schemas. I built an internal npm package that validated event payloads against hard-coded json schemas. We started using this package before publishing messages to the event bus. Then event consumers started using the package to validate the payload as well.

From there, the plan was to create a portal to allow developers to register their events instead of hardcoding them in an npm package. Then we would build the event broker to orchestrate all the moving parts.

No matter how far along we were in the journey, one thing remained consistent: the business problem was always solved. We just kept doing it better.

Summmary

It takes time to develop expertise. When building in tech as broad and fast-changing as serverless, sometimes it's best to discover the best patterns yourself. Don't take all the amazing talks, blog posts, and podcasts you see as instruction to "do this way right now". Take them as references to guide you along your own journey.

It's easy to get caught up in the excitement of the success of community leaders. But they didn't get there overnight. They learned on their own, following the guidance and references of others just like the rest of us.

So take in as much amazing content as you can. Learn from it. Use it to help you make decisions. But don't bite off more than you can chew, you might find yourself wishing you shipped that skateboard after all.

Happy coding!