Everyone probably knows about applications. But how about the concept of Cloud Native? Perhaps many of you, well almost everybody, have heard something and will have an opinion. Okay, then, what are native applications and the Cloud Native Approach really? Is it worth developing new applications or upgrading existing ones to the Cloud Native model to overcome technology debt and improve legacy system?
In this article, I will try to answer the above questions and show why the Cloud Native approach can be a key element in the success of any organization’s digital transformation.
Let’s start with the basics that is, the types of applications
Before I move on to Cloud Native and application deployment, let’s consider the types of applications or cloud deployments we have. For our purposes, let’s divide them into two categories:
1. Brownfield (upgrade of existing system)
Brownfield involves creating, modifying, and implementing software when legacy systems are in place, and we want, or need, to develop or improve them.
Integrating a new feature into existing software, adding a new module to a current system, or updating code to increase an application’s functionality are processes that fall under the category of brownfield.
Challenges with this type of modernization:
- you need a great deal of knowledge about existing systems, services and data on which to build a new solution,
- an in-depth understanding of the capabilities of public cloud services will come in handy,
- we may have to redesign a large part of an existing complex system to meet new business requirements,
- we should have a precise understanding of the limitations of IT and the business.
In addition, working with existing code can slow down the programming process, therefore also increase the overall cost of development.
2. Greenfield (building cloud applications from scratch)
This time, we develop software from scratch. We don’t have the limitations of existing systems. We don’t have to use what’s already there or change outdated code, or adapt to cloud platforms we’ve been using. Building a new website or web applications from scratch, configuring new cloud environments for CI/CD (continuous integration/continuous delivery), implementing a new rules engine, and creating a new SaaS (Software as a Service) solution is what Greenfield does.
Will it be easier? It may or may not. Here, too, we face challenges such as:
- lack of a clear goal, which increases risk,
- the need to define all needs and aspects, which can be time-consuming,
- lack of or difficulty in obtaining timely decisions from interested and responsible parties,
- too many options for software development and creating scalable applications, it is not always clear what approach to take.
Both approaches vs. cloud applications
When working with the public cloud and developing and modernizing cloud applications, we deal with both types of deployment (brownfield and greenfield). In both cases, we can use a Cloud Native approach.
When creating solutions from scratch (application development processes), we are free to choose the deployment model, ensure that the application is flexible enough, use any services or choose any cloud technologies. In the systems we modernize, with public cloud deployments, we will mostly have to deal with migration to the cloud or integration of cloud solutions with on-premises.
Cloud migration can and most likely should be preceded by an upgrade of cloud applications.
It is often possible to migrate a one-to-one application to the cloud in what is called a Lift and Shift model. It will work, but it’s worth looking into upgrade options. Sometimes, small and low-cost changes will make it work better or much cheaper in the cloud. Among the projects we’ve completed, we have a few where the goal was to modernize the application. In one case, the work took about two days, and the cloud costs dropped by 94%.
One piece of advice
With both types of systems, before deploying in the cloud, ask for a consultation from someone who has experience with the public cloud, can advise you on cloud transformation strategy and is familiar with the cloud environment. I am convinced that such consultation will more than pay off even if you decide to abandon cloud.
What are Cloud Native and native cloud technologies?
When migrating to the public cloud or creating solutions from scratch on the cloud platform of our choice, we can simply use virtual machines or clusters. We can even share them directly with the whole world. I definitely do not recommend such a solution, but it is possible. However, the advantages of the public cloud (which I discuss in more detail at the end of the article) and the cloud environment, and what you can get from the cloud’s scalability, will not be utilized then.
Let’s get to the point and use the Cloud Native approach.
Native approach to cloud technology
As for Cloud Native, there is even a foundation that is working on this approach. Among other things, it runs the CNCF Landscape initiative, which already consists of almost 200 different projects. There, you can probably find everything you need for happiness. Or unhappiness. But as a developer, do you need to know all these databases, APIs, gateways, meshes, or monitoring and orchestration solutions? No.
The definition of Cloud Native is available here [link]. Containers, microservices, meshes, declarative APIs, and immutable infrastructure are listed there. For me personally, the idempotency of solutions is still important.
You’re probably asking yourself right now: what services should I use to get Cloud Native solutions? Virtual machines? How about containers (eng. Containers)? Or maybe Serverless? It’s not really about the choice of service. Insisting solely on containers and Serverless services doesn’t quite make sense.
What matters most is how we create the systems and applications and how we manage, maintain and develop them.
Creating scalable applications in cloud environment
There are different models for public cloud deployments. The Cloud Native approach is among the most mature. And perhaps the most demanding. While Cloud Native architecture will not always be the best if you want to take full advantage of the potential offered by cloud capabilities, it is good to keep the following in mind:
- infrastructure automation, application development processes as well as their implementation,
- performance, concurrency, speed of response,
- auto-scaling, or application flexibility,
- fault tolerance,
- diagnosability, i.e. access to metrics, logs, tracing,
- automatic deployments, i.e., reducing the time needed to deploy new versions,
- idempotence.
Idempotency of solutions is very important. Remember that we design Cloud Native applications with fixes in mind, not bugs. Remember that a given service can be restarted many times. Horizontal scaling means that the number of service providers will go up and down. Queries can be repeated, and they can be handled by different instances.
We can achieve the above goals by leveraging the advantages of native applications.
Cloud native applications – the goal of development in cloud computing
Most often, the most important thing is reliability because reliable services mean satisfied customers. And here we come to Reliability Engineering, or SRE (Site Reliability Engineering). It’s a good idea to ask yourself three questions and answer them:
- What does it mean if your service is available?
- At what level should my services be available?
- What will happen and what will I do in case of failure?
For now, nothing is promised to the customer. SLA (Service Level Agreement) is the domain of vendors, not engineers.
How to approach it? How do we define it? Three indicators will enable us to do so:
- SLI (Service Level Indicator) – what is acceptable to us. We measure, for example, whether 97.5% of responses took less than 50ms in the last hour.
- SLO (Service Level Objective) – whether and over what period we maintain the objective defined in the SLI.
- SLA (Service Level Agreement) – this is what we promise and sell to our customers. It defines the percentage of service availability to the customer in a specific unit of time.
And now, something important. We’ll ask the customer if they need a 100% SLA. He will almost always answer yes, but practically always, the answer is no. Achieving 100% will be very difficult and very expensive. Remember, too, that you are providing your cloud services over a network, and that network rarely has an SLA of 100%.
Native programming, or how to achieve the goal?
Do we containerize it or not? How about Serverless and specific services from cloud providers? There is no single answer to this question. It depends on several factors that influence it. Ask yourself these questions:
- Do I have an application ready?
- Do I want my application to be easily transferable between different clouds and on-premises providers?
- Do I want to use the services and capabilities ensured by the public cloud provider in the best possible way (e.g., dynamic application scaling)?
Answering these questions will make it easier to select the right native application components and design a cloud architecture.
Containers, the first step in the modernization and development of native applications
1. I have a ready-made application in the cloud
If you answered yes to the first question in the previous paragraph, it’s probably worth considering containerization. Your application will still need to be changed, but the migration will certainly be easier than with Serverless.
2. I want my application to be easily moved between different cloud and on-premises providers
Did you answer yes to the second question? Then ask yourself this question again, think about it again. Still, the answer is yes? Then, think again about whether “portability” between suppliers is really worth sacrificing, such as the speed of delivery of a solution to the market. Your competitor may think otherwise. If you are still sure of your choice, okay, containerize the application.
You have decided on containers; you already have a modernized application, and certainly, you are not one of the three people in the world who have not heard of Kubernetes. Containers, the cloud – many people immediately associate these technologies specifically with Kubernetes. However, it is rarely the best solution for deploying containers in the cloud. For me, Kubernetes is the penultimate option for cloud deployments. Right before virtual machines.
Before creating a cluster, consider how many services you will deploy and how often you will do deployments. Unless you are working on a really large scale, I would advise against Kubernetes. The entry threshold and knowledge needed to manage clusters properly are really high.
But let’s go back to the question about the desire to move between public cloud providers. If it is not necessary, in my opinion, a better solution would be to use native managed services such as AWS Elastic Container Services. They can do virtually the same thing, and they are cheaper.
When you need to run a smaller number of services, and they are simpler, look towards services such as AppRunner on AWS or CloudRun on GCP.
Before we go further, I will summarize the advantages and disadvantages of containers.
Advantages:
- easier migration (“portability”) between different environments,
- simpler migration to containers,
- Virtually full control over the application,
- Full application scalability,
- The ability to use any programming language,
- easier monitoring.
Disadvantages:
- We pay even if we don’t use it,
- slower scaling,
- often the need to take care of the hardware infrastructure,
- it’s hard to start well,
- Time-consuming administrative work on the containers themselves.
Serverless services to create scalable applications or upgrade existing ones
At the moment, indeed, a great many companies, from the smallest to large corporations, are using Serverless technology to create new application architecture and modernize existing solutions. It’s really a very mature technology. What are we talking about?
Serverless are technologies and services that remain on standby all the time to serve requests, and you pay only for the resources that are realistically used. Servers aren’t on 24/7, and you don’t pay for their inactive time. If you don’t create user accounts, then your application costs you practically nothing – and, most importantly, it is still able to handle incoming requests from your users on an ongoing and continuous basis.
One digression here. Some time ago, one of the cloud providers began to add the word Serverless to the names of services even though they do not really work that way. Referring to the beginning of the article – before you start working on cloud applications, be sure to ask for a consultation from someone who knows what they are doing.
Also, in the Serverless model, you don’t manage the infrastructure. You don’t have to upgrade anything. You practically get a scalable and highly available cloud environment for free. Often, the services also have built-in backup (backup) mechanisms.
I think it’s really worth looking in that direction as well.
Advantages of Serverless:
- we pay only for actual use, not for readiness to use,
- very high flexibility (microservices)
- automatic scaling,
- time to market faster with a solution,
- no need for infrastructure management,
- good separation of responsibilities,
- high availability.
The disadvantages, on the other hand, are:
- vendor lock-in,
- time limits,
- no or difficult control over the runtime environment,
- building complex applications can be difficult.
So what should you choose: containers or serverless?
The advantages and disadvantages listed above can certainly be debated. However, they will not always lead to the goal of choosing the right technology to deploy a cloud application.
Personally, always, with any new application, I start by trying to use serverless services. And it is almost always a good decision.
A few tips at the end
If:
- You are migrating the application,
- You need to be able to migrate between different public and on-premises cloud providers,
- you need processes that run for a long time.
Select Containers.
If, on the other hand:
- You care about getting your application up and running quickly,
- you want to have, without expending much effort, automatically scaled solutions,
- you don’t want to pay a lot,
- you need high availability.
Select Serverless.
Why modernize systems using the public cloud?
That’s right. This question should be asked to anyone going to Amazon Web Services(AWS), Gooogle Cloud Platform(GCP) or Microsoft Azure.
What are your expectations? What do you want to achieve? These are the most important questions.
What advantages for my business processes do I look for by using cloud services?
Here they are:
Reducing costs
Reducing costs is a key component of a cloud migration strategy. Migrating to the cloud requires careful selection of services and alignment of resources with actual application needs. Failure to understand this can lead to overutilization of cloud resources and increased costs.
New opportunities
The public cloud offers a wide range of services that can meet various business needs. You probably don’t have them in your server room. Depending on your requirements and specific project, you can choose the right cloud services that best fit your needs. I guarantee that after some time spent with the cloud, you will discover many possibilities to improve your work or business.
Flexibility
It is one of the most significant advantages of public clouds. Need resources? In the public cloud you’ll get them with a few clicks or commands in the console. In addition, in the cloud we can automatically scale resources according to your needs, which allows you to optimize the use of resources and ensure continuous application availability. You will also eliminate resources you no longer need without any problems.
Speed, agility
Whether you only need a simple PoC (Proof of Concept) or a full-fledged production project, you’ll get the infrastructure you need immediately without the need for complex tenders. Cloud services offer flexibility of resources depending on your current needs, making them an ideal choice for all projects.
Reducing the workload
Don’t like spending time pulling network cables between neighborhoods in a big city or continents? Who likes updating virtual appliances or database servers? How much time would you spend running infrastructure across two continents? In the cloud, we can get rid of all these challenges — that and more.
All at once, of course, will not be achieved. At least not always. Let’s start with small steps in the chosen direction.
Summary
Does modernizing an application by migrating it to the public cloud make sense? Very often, yes. Much depends on how you approach performing the migration.
A simple move of an application to the cloud will give us less profit than a migration carried out with modernization.
Should we always upgrade an application before deploying it in the public cloud? Of course not. It will not always make sense. If the workload is disproportionately high compared to the results obtained, we should not do such an upgrade.
If you decide to migrate in conjunction with upgrading or creating an application from scratch, consider choosing the right deployment model. What if Cloud Native is containers or Serverless? Unfortunately, there is no one-size-fits-all answer to this question. Except, the famous “it depends.”
I always aim for Serverless, but it won’t always be the best choice.
Designing native applications is not easy. However, the right application architecture will allow you to take advantage of the benefits of Cloud Native applications.
When modernizing an application, the process of analysis before taking any action plays an important role. It is what helps answer many of the questions related to modernization and deployment in the public cloud.
