If your hobby is any kind of outdoor activity, you must be able to tell different kinds of clouds (especially cumulonimbus). When it comes to digital clouds it doesn't get any easier.
There are people who think that the only alternative to "in the cloud" is "not in the cloud", but we should know better than that.
So what exactly does "cloud native" mean? What are the different types of clouds? And why some people warn us against the "fake cloud" ?
Let's start with quickly describing four main approaches.
No cloud = On premises
Some say that's the traditional model. Others call it the historic one.
You own the hardware. You install the systems by yourself, you support and upgrade them. You control everything, but you are responsible for everything, too. You are also independent and you know exactly how your data is used.
You are also responsible for designing and providing resources like infrastructure (i.e. servers) in a cost-efficient way.
Hosted
It's still not a cloud. This approach is similar to the plain old "on-premises" approach, only the owner of the hardware, is not you. You still do most of the work, like installing software, maintaining it, securing data. The difference is that you don't own the hardware and it's not your problem when it breaks. Or actually, when it breaks you still have a problem, but you don't (and can't) solve it by yourself. What exactly is the offering? Depending on the provider it may be "Infrastructure as a service" (IaaS) or "Platform as a service" (PaaS).
In the IaaS model, you are given a physical secure location with all necessary infrastructure components (network, firewalls and so on) as well as servers and storage according to your needs.
PaaS extends IaaS by providing you also with software components like operating systems, databases, dashboards and some managing and reporting tools.
Single-tenant cloud
Let's look at this approach from a vendor's perspective.
You are a software vendor and your customers use your application installed on their servers or in a "hosted" environment. And let's assume, that at some point your customers say: We like your solution, but we don't like running it by ourselves anymore. It takes too much time, our IT guys complain that they don't want to support it day and night, we just don't want the hassle. Please take it to your environment as it is. We will pay you a monthly fee.
At this point different customers may be using different versions of your software, some of which are personalized, some are generic. Some customers also urge you to physically separate their systems from the other ones - for legal or security reasons - or just because "they don't trust clouds".
So basically what you need is to provide each of your customers with a separate instance of your system.
From customer's point of view, they get the same deployment (in terms of the version number or customization) as they had in the on-premises environment, with similar security measures and separation from other customers' data.
Note that now you may become a customer of IaaS or PaaS providers yourself, in order to be able to provide your customers with your - now cloud-based - solution.
Multi-tenant cloud
The obvious disadvantage of a single-tenant approach is that assigning each customer a separate instance of hardware is not too cost-efficient.
Multi-tenant approach solves this problem.
In this scenario you are again a software vendor and provide customers with your application. However, you don't want to assign each of your customers a separate instance of your application. Instead, you decide to change your application so that all of your customers use exactly the same application. So now all your customers effectively use the same components, on the same hardware and on the same storage. Only now, the isolation between customer data is provided on application level rather than physically.
Let's see at Gmail as the most straightforward example: All customers log in to the same mail application, they can personalize their mailbox, filters, notifications and so on, and they don't see each other's emails.
In multi-tenant approach customers have no access to neither physical servers, nor to low-level components. What they pay for is services of your application - hence the name: Software as a Service (SaaS). In this model they don't care about anything - they pay a monthly fee and the application is supposed to work, period.
Cloud native?
So far so good, but what exactly does "cloud native" mean?
Only recently I read an article in which one of the well known bigtechs boasted that they can make your company "cloud native" - by moving your systems to the cloud without making any changes to you current application.
That's not how it works. Buying a smartphone doesn't make you a "digital native" just like flying to Mars doesn't make you a Martian.
"Cloud native" means an approach, a way of designing, developing and running applications so that they could take full advantage of cloud features. Such applications should be designed in a way that results in their elastic, scalable and distributed nature.
That means loosely coupled components, often microservices, modular design and statelessness. It also means keeping in mind that the components will work in virtualized environment and must scale dynamically according to current traffic, the amount of data or the number of customers.
Migrating to the cloud doesn't make your systems "cloud native". But it's a catchy phrase.