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.

Button with a link to a file with a sound record of Blog article text Cloud Native Approach: Modernize or build cloud applications from scratch?

 

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.

Cloud Native, Cloud Migration

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.

Containers, Cloud Native, Kubernetes

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.

Cloud Native, Serverless

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.

Cloud Native

_All posts in this category

blogpost
Articles

Lesson Learned Explained: Implementing a Continuous Innovation Program in the Defense Sector

In the fast-paced aviation and defense industry, one of our clients faced a key challenge: how to accelerate the adoption of modern technologies and maintain competitiveness. The solution? Implementing a Continuous Innovation Program as the foundation of a new business model. A crucial aspect of this program was the continuous testing of state-of-the-art technologies to bring increasingly innovative products to market.

Read more
blogpost
Articles

How to leverage AWS key benefits to get real business value with Cloud Application Modernization

It's not rocket science, and it's pretty obvious that businesses need to keep up with the fast-changing digital landscape to remain competitive. Cloud application modernization is a critical strategy for updating outdated and legacy systems to leverage cloud computing benefits like those offered by Amazon Web Services(AWS). With this blog post, I decided to explore ones directly related to application modernization and the overall advantages of the cloud. Also, I will address the most common question of whether it is worth to modernize existing apps?

Read more
blogpost
Articles

How can artificial intelligence influence the vision of the future and cloud computing development?

The beginning of the year is a time of intensified summary of the past months, as well as preparation of plans for the upcoming ones. During this period, there are many more or less accurate predictions about what we can expect shortly in the multiple cloud providers offer.

Read more
blogpost
Articles

Azure Cloud Security: How to ensure the Zero Trust Model and use AI to our advantage?

Since the global popularization of remote work in recent years, IT security teams are facing ever-increasing challenges to ensure effective and secure access to organizations’ critical assets, resources, and data.Elaborate phishing attacks, through which user credentials are being exposed, allowing for lateral movement attacks or installing ransomware on mission-critical infrastructure. Zero-day vulnerabilities enable malicious actors to disrupt accessed services.

Read more
blogpost
Articles

Is the Edge a new Cloud?

Nowadays, many organizations that adopted the cloud are looking into the Edge as a natural extension for their cloud-based solutions. On the other hand, the ones at the very beginning of the Cloud journey are way more aware of the Edge and the Cloud, so they are considering the usage of both technologies at the very beginning.

Read more
blogpost
Articles

Quantum Computing: Where Schrödinger’s Cat gets cozy in the Cloud

Join me for a journey that will take us from the realm of reality as we know it to a world where a cat can be both: dead and alive, and a particle can be in two places at once. Fasten your seatbelts as we explore the fascinating world of quantum computing and its role in cloud computing.

Read more
blogpost
Articles

Will hybrid cloud and multi-cloud defend you from vendor lock-in? Do you really need to be wary of it?

Vendor lock-in is a concept overly often associated with the IT industry, and in recent years, especially with cloud computing, although it is not inextricably linked with them. Economists considered it in a broader context long before the world first heard of AWS or Azure. From a customer and user perspective, it has tended to be viewed negatively, often creating reluctance and fear of using a particular service or product.At first glance, the problem is not trivial in the public cloud area. Even the main beneficiaries of the phenomenon, i.e. the largest cloud providers, have decided to raise the issue on their official websites, so clearly something must be...And whether it actually is, we will check in this article. We'll look at the risks of vendor lock-in for organizations planning cloud adoption. We'll also consider whether using multiple vendors (multi-cloud ) simultaneously can be a good recipe for improvement. In addition, we will take a look at the hybrid cloud.

Read more
blogpost
Articles

The critical role of cloud-based data platforms. Reshaping manufacturing data management

Cloud-based data platforms revolutionize manufacturing data management by efficiently handling vast amounts of data in real-time. Manufacturers can collect data from various processes, analyze it with advanced tools like AI/ML algorithms and BI, and make informed decisions. These platforms offer key benefits, vital elements, and integration with Data Strategy.

Read more
blogpost
Articles

How can AI Data Discovery help manufacturing companies?

We are all blessed to live in very exciting times. Exponential technological progress over the last couple of decades has influenced not only our personal lives but also heavily impacted business. Trends are obviously evolving occasionally, but it is safe to say that now is the time of advanced analytics.

Read more
blogpost
Articles

Airline Rewards App: Mapping requirements to architecture for application migration and modernization

In this article, I'll guide you through the steps, technical choices, and trade-offs of migrating and modernizing apps to the public cloud, emphasizing beyond lift & shift and PaaS approaches. Using a real-life example, we'll consider business goals, architecture, and functional/non-functional needs. Business factors will be discussed in the next article.

Read more

Let’s get in touch

Contact us