If you are passionate about outdoor activities, you should know about various types of clouds, particularly cumulonimbus. When it comes to digital clouds, it doesn't get any easier. While some people believe that the only option apart from being “in the cloud" is to be “not in the cloud," it's essential to have a more nuanced understanding. So what exactly does “cloud native" mean? What are the different types of clouds? And why do some people warn against the “fake cloud"?
Let's start by quickly describing four main approaches.
Some say it's the traditional model. Others call it historic.
In this model, you own the hardware, install the systems, and support and upgrade them yourself. You have complete control over all aspects, but with that control comes the responsibility. You are also accountable for designing and providing resources like infrastructure (i.e., servers) in a cost-efficient way. On the other hand, you are independent and have a clear understanding of how your data is utilized.
It's still not a cloud. This approach is similar to the old “on-premises" approach, except you don't own the hardware. You still do most of the work, like installing software, maintaining it, and securing data. The difference is that you are not the hardware owner, so it's not your problem when it breaks. Actually, when it breaks, you do 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 secure physical 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 software components like operating systems, databases, dashboards, and some managing and reporting tools.
Let's look at this approach from the perspective of a software vendor. Your customers use your application installed on their own servers or in a “hosted" environment. However, they reach a point where they indicate their preference to no longer handle the application's management themselves. They find it time-consuming, face complaints from their IT staff who are reluctant to provide round-the-clock support, and simply want to avoid the hassle. They approach you with a request to migrate the application to your environment as it is, and they are willing to pay a monthly fee for this service.
At this stage, your customers may be using different versions of your software, some generic and others personalized. Some customers may even request physical separation of their systems from others, either due to legal or security considerations or simply because they have reservations about trusting cloud-based solutions.
To meet these demands, your objective is to provide each customer with a dedicated instance of your system. From the customer's standpoint, they expect the same deployment in terms of version number and customization as they had in the on-premises environment. They also anticipate similar security measures and data separation from other customers.
It's important to note that as a software vendor, you may become a customer of IaaS or PaaS providers to fulfill the requirements of providing your customers with your new cloud-based solution.
The drawback of employing a single-tenant approach is that allocating a separate hardware instance for each customer is not particularly cost-effective. The multi-tenant approach solves this problem.
As a software vendor, instead of creating distinct instances of your application for each customer, you can modify the application to be used by all customers in exactly the same way. In this scenario, all customers effectively utilize the same components, hardware, and storage. The isolation between customer data is achieved at the application level rather than through physical separation.
To illustrate this concept, consider Gmail as a straightforward example. All customers log in to the same mail application, but they can personalize their mailbox, filters, notifications, and other settings without being able to view each other's emails.
In a multi-tenant approach, customers do not have access to physical servers or low-level components. What they pay for is the services provided by your application, which is why it is referred to as 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.
So far, we've covered the basics, so let's delve deeper into the concept of “cloud-native."
Some well-known tech companies have made audacious claims, suggesting that they can make your business “cloud native" simply by migrating your systems to the cloud without any changes to your existing application.
This claim falls short. Just as purchasing a smartphone doesn't automatically make you a “digital native," and flying to Mars doesn't make you a Martian, moving systems to the cloud alone doesn't earn the “cloud native" status.
In essence, “cloud native" refers to a specific methodology of designing, developing, and running applications to harness the potential of cloud features. These applications are elastic, scalable, and distributed in nature.
It means loosely coupled components, often implemented as microservices, a modular design, and statelessness. It also means that the components work in a virtualized environment and scale dynamically in response to fluctuating traffic, data volumes, and the number of users.
“Cloud native" is a catchy phrase, indeed, but remember that migrating to the cloud doesn't make your application so. Understanding the different approaches to cloud computing is essential in today's ever-changing landscape as it saves you from being merely “cloud naïve" instead of “cloud native".
Make an appointment for a discovery meeting and find out how we can help you.
