Cloud native is one of those words that make some people shake their heads and call BS. In some contexts I am one of those people. It does however also have its place, because building solutions that are cloud centric does come with a number of benefits and enables solutions that were very hardif not impossible pre-cloud.
Sure, you can script the setup of a server from scratch, but it requires quite a bit of work, it takes time to execute and you still end up with an environment that requires updates and patching as soon as the script is a week old. In a cloud setup good practices, in the form of DevOps mainly using the CLI makes this very obtainable. Actually the current environment I am working with combines an ARM template and a few lines of script so we can spin up an entire environment in about 15 minutes. The only manual step is setting up the domain and SSL cert, but even that could be scripted if I wanted to.
Simplicity through serverless
Serverless is of course also a feature of cloud technology. It has quickly become one I love because it is, in a sence, the single responsibility principle taken to its conclusion. Building a regular WebAPI does not make you fall into the pit of success, simply because structuring functions well is difficult, and pretty much always leads to breaking the SRP in some degree. Creating one function at a time, with only the required dependencies and zero ceremony is likely to give you a much better foundation. A main focus of good software design really is dependency management, so being nudged in the right direction is hugely important.
In our case we went all in on JavaScript, and for our use case just having one language and especially one way if modeling has made life easy. We don't have too many complex rules or models, so here simplicity wins over having a more expressive language. The awesome thing is that in any case, we can adapt, because we are free to write some functions in eg C# if the need arises.
No more “SQL Server for everything”
Polyglot persistence is another paradigme that wins out by a cloud setup. If you have to install and maintain a bunch if databases yourself or wait for your it-department to do it, you will with good reason be reluctant to do it. When you can provision different databases as PaaS services it is trivial to do, and maintenance is no longer an issue. Simply put it allows you to pick the right tool for the job, without making you suffer for it.
I used to do what most developers did, and based everything on SQL server, because it allowed for rich querying, transactions and a fair amount of flexibility. It clearly came at the cost if spending a lot of time managing schemas, mapping data and solving performance issues, but there was no better way available at the time.
On Azure I get CosmosDB, which with the SQL API lets us save json, which means deeply nested models in the same shape as objects. So we spend less time bridging technologies, which makes us perform better, while the queries also perform better. We still have rich querying capabilities, transactions and we can even choose different API's if we need table or graph models. This in itself is important, but for the overall architecture the ability to add Redis for caching, table storage for huge amounts of tabular data or even a good old SQL database for doing BI is the real gamechanger.
Lastly there are all the other services that are available and can quickly be added as needed. An example I often think of is all the times I have seen solutions with custom "queues" implemented on SQL server. Again this was done to avoid adding a server that should be maintained, but at the cost of performance and not least bugs, because making a robust queue is not trivia. I am so glad those days are over! On top of all this comes Azure Vault, SignalR, IoT, ML, mobile, logic apps and I could go on and on listing specialized services, but suffice to say I love how architecture is no longer about limiting yourself, but about choosing the right tools.
Subscribe