Contents

1. Intro
2. Focus
3. Management
4. Cost
5. Responsibilities
6. Vendor Lock In Myth?
7. Summary

Intro

I was going to write this about the Risks of Cloud Agnostic Architecture. However I think it best to stick with the positive and highlight the advantages of a Cloud Native Architecture instead.

The first thing you might be asking is...What is Cloud Native Architecture?

Cloud Native Architecture is designing your system, service or application, whatever it might be, to make use of the unique capabilities of the cloud and of your chosen Cloud Provider.

I consider this 'using the right tool for the job', you could use a hammer to get a screw into a plank of wood, but the right tool, the more specific tool, a screwdriver, would do a better job.

Focus

Let's take a database, a common requirement for almost any architecture.
There are an array of options depending on your chosen Cloud Provider, to name just a handful. AWS (Amazon Web Services) has Dynamodb, Aurora, RDS (Relational Database Service). Azure has Cosmos DB (which if you haven't heard of definitely check it out, it's a favorite of mine), SQL. Google Cloud has Spanner and Big Table and the list goes on and on and on.

Each has its own specific use case, or scenario it functions slightly better at than the others but they are all still a database.
You could also spin up your own database, on cloud servers or your own servers and manage that yourself. Which is how almost everyone worked with databases before the cloud and cloud providers became popular.

But a database, is still a database, in terms of infrastructure. I'm not referring to the data structures and modelling inside of a database here, just about the infrastructure.

Yours and your teams time, their focus is limited, you only have a finite amount of it. Only so much you can spend your focus and time on.
Would your business prefer that time to be spent on delivering value, delivering differentiators from your competition or spending more time on a building and managing database infrastructure.

Which is a problem with plenty of existing solutions, only a handful of which I mentioned before.

Management

Continuing on from Focus and our database example. Not only are there existing solutions to a database, but they are also managed for you.
Managed by teams who have the experience of running databases (or any other managed service) for many other businesses, at every kind of scale. That is one of the major benefits of the cloud, the providers will often have seen the scenario before with a different customer or because they have been running the database or service for a period of time before your use of it.

Not only do they have the benefit of experience, but it is also their focus, their teams focus, to make that database as good as it can be for the variety of businesses using it.
That is their focus, what is yours?

I recently got a little carried away with a load test, on a cloud native serverless system.
Which I had only previously tested with a few hundred events. I ended up putting 12,000 events through.

However I didn't need to worry as the system was using managed services, which tend to be charged on usage, they scaled up, absorbed and processed that load without breaking a sweat.
Because they were managed and will have definitely seen larger spikes of events than that, I didn't need to worry about the system coping or managing the scale myself.

Cost

Now this can be a double edged sword, Cloud Native Architecture tends to be priced based on usage which does have pros and cons.

There are plenty of stories where Cloud Budgets and limits haven't been put in place and people have ended up being billed large amounts due to something running wild.

However for every one of those stories, there are plenty of unheard ones about the benefits of usage based pricing.

For example, if you had air conditioning that you rarely used, but you kept it on and running at maximum all the time anyway, on the occasion you needed it, that would be inefficient and more expensive that it needs to be.
This is how I like to think of usage based pricing.

Why pay for a server or cluster, every hour of every day, when business as usual only needs a fraction of the computing power available? Would it not be better to only pay for what you use, when you use it.

I will caveat this section with making sure your architecture is efficient with its usage of cloud native services and designed well, will help massively with cost.

Also if you are worrying about your AWS bill I would recommend chatting to the duckbill group.

Responsibilities

As a business or as a member of a business, you have plenty of responsibilities and things to think about. The competition, your staff, the environment, the wider world and so on.

So why add one more thing for you to be responsible for? Responsible for if your system is scaling, if its managing and coping, if it needs your attention.

Now I'm not saying don't monitor your Cloud Native systems, definitely do.

What I am saying is that you probably have much less to be responsible for when using managed services, like we said before they are managed for you, with all the benefits that come with that.

The thing you do need to be responsible for yourself is designing your system up front and spending time on your Cloud Native Architecture to ensure you are using the best tool for the job and the unique advantages that your Cloud Provider gives you.

Vender Lock In Myth

You will often hear a disadvantage of Cloud Native Architecture, is that it means you are reliant on that Cloud Provider, you are locked in to that vendor.

Now it is true that because you are using Cloud Native systems you are tied to that vendor and it will be harder to migrate to another Cloud Provider, or in a disaster move over to another Cloud Provider.

However, I have yet to hear of anyone move Cloud Providers unless a large cost benefit has been agreed in advance. Furthermore, no matter how agnostic your architecture is, all the surrounding permissions models, and permissions themselves will all be different per Cloud Provider and need changing, as will any Infrastructure as Code for example Terraform. This all has to be Cloud Provider specific or Cloud Native by design.

If there is a disaster with your Cloud Provider (and that is a really big IF), how quickly could your data be migrated to a new Cloud Provider, how quickly any state? And what are the statistical chances of your Cloud Provider going down or having significant issues?

Summary

In summary, I believe utilising Cloud Native Architectures, which are often Serverless but thats another blog entirely, provide real benefits to your business and team.
It allows you to focus, to spend your limited time, energy and money on what you are best at, at differentiating your business and delivery value quickly for your customers.

Use the unique tools that each Cloud Provider gives you to your advantage, minimise the time you are spending on problems that don't make your business special, use the right tool for the job and leverage the clouds benefits.

Happy Building!