Introduction to Cloud Native Architecture: Paving the Way to Smooth Migration


In her interview to the portal Jaxenter.com, Jessica Deen, Cloud Developer Advocate for Microsoft at JAX London 2018, said about cloud native technology that, though making its adopters “portable and resilient”, the technology stays scary, as unknown, even for professionals from cloud app development companies.

Pini Reznik, CTO of Cloud Native Computing Foundation (CNCF), confirms this statement, admitting that “Companies regularly approach us to say they’ve tried Cloud Native but it failed to deliver. […] We saw a pattern emerge – as they became more aware of all the possibilities of Cloud Native, they found it hard to focus on any one thing. But Cloud Native is difficult, so if they didn’t focus they got bogged down on every front.”

Two main questions are stemming from this.

What is New about the Cloud Native Technology?

Cloud native apps work solely in the cloud. However evident this may sound, here hides a major difference between them and cloud-based application development.
  • Working with a higher level of virtualization. The cloud allows to enjoy the highest level of scalability (you get as many resources as you want) and agility without thinking about hardware – a striking difference from on-premises services.
  • Shift of responsability. All that comes to security, scalability and computing resources is a concern of the cloud computing service provider, and not their clients. In their service level agreements (SLA), the members of the great cloud triumvirate – Amazon’s AWS, Microsoft’s Azure and Google Cloud – guarantee 99,9% of their cloud managed services availability per month.
  • Quicker scalability. With a cloud native app, you can scale it up at any moment when a necessity comes. This is another difference from services deployed on-premises, which work fine with a predefined amount of data, but face difficulties once you need to scale up.

What Makes It so Difficult?

The difficulty comes from its novelty. Developing cloud native apps demands a major shift in the coding culture: now a developer doesn’t simply write a code, but keeps in mind broader concepts. DevOps practices, i.e. participation of both development and operation engineers in the entire service lifecycle, and learning to work with applications capable of ruling their own infrastructure and adopting themselves to changing circumstance, for example server failures, come as some of the basic principles of cloud native development. Today, not everyone is ready to work this way. Apart from microservices, the cloud native paradigm uses the notions of DevOps, Containers and Continuous Development.  

Key Concepts in Cloud Native Architecture

Let’s check the definition of the technology, given by the CNCF, established to promote a widespread adoption of the cloud native paradigm.


Cloud native computing uses an open source software stack to be:

  • Containerized. Each part (applications, processes, etc.) is packaged in its own container. This facilitates reproducibility, transparency, and resource isolation.
  • Dynamically orchestrated. Containers are actively scheduled and managed to optimize resource utilization.
  • Microservices oriented. Applications are segmented into microservices. This significantly increases the overall agility and maintainability of applications.

These characteristics provide for the principal practical benefits of the new approach:

  • Faster Deployment Time. If you check the brightest examples of big-name companies leveraging the cloud native technology, be it Asos, Skyscanner or Uber, you will see that they cite its extreme agility and, as a result, faster deployment time – “reacting at the speed of the Internet” – as the main benefit motivating them to go for the new architecture type.
Businesses that deliver innovative software solutions outperform their competition and realize faster time-to-revenue of their value-added services.
The delivery of new apps is accelerated by the self-service portals and elastic nature of cloud computing, enhanced by the use of APIs instead of form-based manual service methods of traditional cloud software development.
  • Inspiring Experimental Culture. According to Victoria Morgan Smith, senior project manager at the Financial Times, one of the goals of going cloud native is to “de-risk experimentation”. Cloud native architecture gives more liberty for this, as the automation capabilities of the cloud enable cloud native business owners to roll back to a stable version of an app with no detected errors.
In the past, a standard approach to avoiding danger was to move slowly and carefully. The cloud native approach is about moving quickly by taking small, reversible and low-risk steps.
  • Improved Scaling. Needless to say: the auto-scaling tools of the cloud native approach stay one of the most attractive points about it, allowing its users to get access to more computing resources of their cloud computing company.
  • More Efficient Development Management. With a monolithic architecture of an application, any development process has to be linear, with a stream of work going on around a piece of the solution, while with a microservice-centric structure dedicated teams can work on implementing new features or revising older ones at the same time.
One of the basic concepts about cloud native technology is its use of microservices in deploying highly scalable apps.
  • Cloud Portability. The approach is in fact absolutely cloud agnostic and doesn’t care about who is running the backend, be it Google, Microsoft, Amazon Web Services or one of their contenders. Cloud native apps are not tied to a specific cloud application services platform, as in their environment, interactions between the app components are done via standard service APIs, running tasks via either open source or common functions which can run across different clouds.
Moreover, Kubernetes, leading container orchestration platform, has introduced a concept of “cluster federation”, i.e. aggregating multiple clusters and treating them as a single one regardless of their location. That is, different clusters can be deployed in different public clouds, staying provider agnostic. According to Zakhar Bessarab, Senior Web Developer at RStyle Lab, “this provides an even higher level of abstraction, i.e. abstraction over abstraction”.   
Have any questions? Ask our team!

However, it would be fair enough to name some of the challenges of adopting this approach.

According to the 2018 CNCF report, respondents name the following key concerns when facing the cloud native approach adoption:
  • Cultural Changes with Development Team (41%)
  • Complexity (40% up from 35% compared to the 2017 survey)
  • Lack of Training (40%)
  • Security (38% down from 43%)
  • Monitoring (34% down from 38%)
  • Storage (30% down from 41%)
  • Networking (30% down from 38%).
These changes in numbers are clear: while a broader expansion of cloud native apps brings about a growing level of concerns about their novelty and associated innate difficulties of this transfer, a certain experience in the technology adoption and exploiting provides developers with a range of best practice solutions regarding monitoring, security or storage challenges.  

Insight into Migration to Cloud Native Architecture

The process of evolving a typical monolithic app, deployed over on-premises infrastructure, into a cloud native one follows a number of regular steps.
  • Transferring existing legacy code and databases from server hardware to the cloud. This transfer is only the first step in making your app truly cloud native, as their codebase includes every feature and service built as monoliths, while cloud native solutions, boasting microservices architecture partly or as a whole solution, present a distributed collection of services.  
  • Automation implementation. Cloud native solutions don’t deal with manual tasks regarding product-based development, testing and deployment. Instead, they use automated test suites, configuration tools and CI/CD.
  • Getting adopted to the cloud. Typically this step is limited to breaking a monolithic code into microservices, turning an application into a collection of small services; each service implements business capabilities, runs in its own process and communicates via HTTP APIs or messaging. But in fact the microservice-based structure is one of the approaches, and not the only one. There are monolithic cloud native apps as well, for example, cluster of databases.
  • Deployment of independent bricks within the cloud native app structure. The most widespread approach here is the containerization method, i.e. wrapping up all the processes and libraries for running a particular application into a single package and putting an interface on it to facilitate navigation. Docker has made this technology highly popular, as it is effective and less demanding compared to the others, it provides a high level of isolation of the app’s elements and can be deployed within the tightest time frames.
However, the container technology is not mature enough to isolate processes perfectly well. That’s why another approach, implying the use of virtual machines, stays a more advanced technology in the terms of the provided isolation, but presents a significantly more expensive solution.   
  • Orchestration. Orchestrators like Kubernetes, DC/OS, Nomad or Swarm remotely control containers running on any machine within a defined set called a cluster.
  • Monitoring/Logging/Alerting. These features have become essential parts of cloud native apps; however, they are often missing at the initial figuring stage of the cloud native project deployment. In the future it can lead to a variety of troubles, because, as we all know, if the program is working, it doesn’t mean that there are no errors.
Yet, it is always advised to contact a
cloud based application development company to get individual cloud consulting services, facilitating a company’s migration to the new app architecture.
Cloud-native applications are cloud agnostic, technology independent and can be deployed in almost any context. That’s why they have become today’s choice when designing and deploying applications, from mobile apps to Internet of Things software development. These applications are fast (in terms of deployment and change time), agile and deliver value for money. Though this approach remains quite a new one and requires a considerable cultural shift in order to benefit from it to the maximum, the market seems more than welcoming to adopt it on a large scale.

Popular Posts

Subscribe Now

We get into the groove, sharing what we've learnt in the real-life context with the like-minded folks.
Subscribe to get the latest insights from us!

Please, enter a valid name
Please, enter a valid email address
Please, agree with our privacy policy

By subscribing, you agree to receive email updates from R-Style Lab and you can opt out at any time

Link copied to clipboard