Thomas Erl wrote this wonderful book on the SOA’s 8 principles of service design quite a while back. Together with Hophe and Woolf’s Enterprise Integration Patterns that’s basically almost all you need to know by heart, when starting out as a rookie (integration) developer.

No matter what software architecture used, the things learned from these books should always be applied. So, also in this new serverless era, the same applies.

But, the hardest part of every software architecture is the data architecture. You can fantastically modularize functionalities and integratie them at will, but if the data behind the modules is one big blur of relational mess, good luck with your APIs, principles, patterns and Devops then!

Is SQL Server (or any other relational database) actually witholding us from creating true serverless, reusable and autonomous APIs? Will the Graph or DocumentDB or CosmosDB help us out? Is big data coming to the rescue? Schema on read? CQRS? Blockchain based transaction ledgers?

Probably 80% of data in any given relational database is not relational. So why use a SQL Server database then? Why shoot ourselves in the foot right at the start?

If we want to become true serverless, not only do we need to adhere to the principles of service design and integration patterns, but also need to rethink our data architecture.

Eventual consistency looks like a nice concept, but in a real-time world quite hard to implement and make successful. But maybe it’s our only option? In any case, the use of relational data storage will in my opinion decline quickly. SQL Server will *have* to morph into something new, with less emphasis on the relational aspect. I know Microsoft have already started that transition.

Getting the right architecture guidance on serverless in combination with data storage is going to be crucial in the coming time.

Cheers, Gijs