Back in August, I published an article talking about the future of serverless. At a high level, the gist is that the future is infrastructure from code (IfC) that adapts based on production traffic.

I spoke about it a bit on the Screaming in the Cloud podcast as well.

It has a lot of promise and the idea of focusing only on your business logic is certainly appealing. Or so I thought.

After I published my thoughts on IfC being the way of the future, I had a few companies reach out to me saying the future is closer than you might think. I spoke with a couple of them and have been working on building some proof of concepts with the tools available today. More on this later.

As I started building, it didn’t take long for me to form some early opinions.

And while I’m still early in my opinion making, I wanted to share my realizations because I no longer think it’s going to be as easy as I once did. The earlier we talk about it, the earlier we can make informed decisions to shape the future.

Developers Won’t Like It

As I dove into my first proof of concept, I had a hard time adjusting my mindset to this type of development. Having worked with serverless for years, I have it drilled into my head that code X belongs with infrastructure Y.

It’s part of the mental map I build as I work out a solution. I am accustomed to correlate infrastructure with my code.

But that’s not how infrastructure from code works.

You have to release the control of the infrastructure to the framework. Trust that it will decide the correct resources to create based on the infrastructure you’ve written.

If there’s one thing I know about developers….they have trust issues.

Not in a bad way. But time and time again I see devs who reinvent the wheel because they think they can do it better. They don’t trust that what out there is good enough for their use case. They think their product is special.

Sound familiar?

This will be a significant hurdle in the adoption of infrastructure from code. Trust. Letting go of the notion that I can do it better and just focusing on solving the business problem.

Honestly it sounds like an ideal situation, but practically people are going to have a hard time adjusting.

It’s Not Just Solving Business Problems

Even though it sounds cool to say you’ll only be writing code to solve business problems, you’ll still be doing some lower-level design as well.

There’s obviously data modeling that will never go away. Knowing access patterns and building an appropriate data model is something that can’t be abstracted.

But components like publishing and subscribing to events must be taken into consideration. While the infrastructure you’re using might be abstracted, the fact that you need to publish an event when a business action occurs is still present.

This was a big misconception that I had. I thought part of the whole “infrastructure from code thing” would make it so I didn’t need to consider low-level components like events. I’m not sure what I thought would replace it, but that is certainly not the case.

Intentional design of how data flows and gets shared across services is still very much a part of the future. Solutions architects are still needed!

Maintenance Will Be Tricky

Full disclosure, I have some not-so-ideal habits when it comes to troubleshooting serverless issues. I usually identify the endpoint or event handler that has issues, find the backing resource, then jump to CloudWatch.

If it looks like something I can quickly fix, I change the code in the console and verify. Then I go back and make that change in source control and open a pull request. Not in production, of course. Please do not do this in production!

The real key to the success I’ve had doing this is that I can quickly find my resources from a known entry point, like an API endpoint. I can look at my spec, see that it ties to a specific Lambda function, and go straight there.

This goes away if you let your framework build your infrastructure from the code. You spend time tracking down which resources were created and deployed (if you can), and even if you find it, you might not have access to change code on the fly.

If a Lambda function was created, maybe it was created as a container function. Or maybe your endpoint was created in AWS AppRunner where you don’t have access to the live code.

Honestly, it might be a good thing. You end up relying on observability tools rather than digging into the console, which is a safer practice for production software. The turnaround for fixing issues is a little longer, but it does prevent you from accidental drift.

Conclusion

There’s an interesting balance that IfC vendors need to make here. They need to abstract enough away where consumers feel the benefit, but they need to provide enough control where they can still make detailed decisions.

I was originally under the impression that infrastructure from code was going to be a game changer. After using some of the options that are out there now, I still believe this to be true. However, it comes with caveats.

If you don’t like change, you’re going to have a bad time. Current serverless developers will push back on adoption because they feel like it’s taking away their control.

IfC is not going to be a silver bullet to all our programming problems in the future. We still need to build things like retry mechanisms, idempotency, and saga workflows.

Infrastructure from code will not take away technical prowess from developers.

If anything, IfC will help the mastery of certain development skills. By clearing out the clutter of infrastructure decisions, developers can focus more on complex patterns and new constructs.

The future is bright for serverless and IfC. I genuinely believe adaptable infrastructure based on traffic is not too far away. But what will that mean for application maintainability and other operational concerns? Time will tell.

Stay tuned for a post where I benchmark three IfC vendors and compare their available features and implementations. So far, I have seen three very different assumptions with very different outcomes. It’s exciting to see all the possibilities we could have in the future based on our use cases, priorities, and willingness to trust in others.

Happy coding!