What cloud native means - and what it doesn't mean

Cloud Native describes a modern, agile concept in which software is developed for operation in the cloud. This allows companies to fully utilise the advantages of the cloud. Many decision-makers are therefore keen to switch their applications and processes to the new method as quickly as possible. However, there are also some misconceptions and misunderstandings surrounding cloud native. They are put to the test below.

Cloud native is being proclaimed in many places as the new maxim for IT departments. Cloud-native software is seen as robust, flexible and freely scalable, ideal for agile companies. And in principle, this is true. However, things are not quite so simple - at least when cloud-native architectures are meant in the strict sense: Applications that are made up of microservices, are operated on dynamic infrastructures and communicate via service meshes.

Five cloud-native myths in the fact check

Myth #1: After a lift & shift of my infrastructure, my workloads are cloud-native.

This is not true. If you migrate applications from your own data centre to virtual machines in the cloud using the lift-and-shift principle, this is actually only the first step on the way to cloud native. This relatively easy-to-achieve state is also referred to as "cloud-based". The migration of the application to the cloud has been completed, but the possibilities of the cloud are only used to a limited extent.

Cloud native, on the other hand, is a much more comprehensive approach (see also article "What is Cloud Native?"), which, in addition to the changed infrastructure, also means a new software architecture, new tools, new ways of organisation and even a completely different working culture within the company. For example, small development teams are formed that work with agile methods and more personal responsibility. The aim of all these measures is a significant time saving when implementing new projects and a general increase in agility: IT can react more flexibly and quickly to changes overall.

Myth #2: Cloud native abstracts complexity.

This is only partially true. By moving applications and processes to the cloud, a company can hand over more or less responsibility to a managed service provider or hyperscaler, depending on the delivery model (IaaS, PaaS, SaaS, etc.). In addition, according to the principle of shared responsibility, it can be agreed with managed service providers that they will take on further tasks and responsibilities and, for example, take care of monitoring or support.

However, new challenges inevitably arise when implementing the cloud-native principle:

• New complexities: New technologies and the distributed nature of cloud-native applications require more attention from IT teams. For example, orchestration software such as Kubernetes is required to coordinate the microservice containers. In addition, each microservice requires support for embedding in the overall system (service discovery). The fact that microservices communicate asynchronously and are only loosely coupled also means that troubleshooting is more difficult than with monolithic applications. Another complexity factor is local data storage, where each service stores the data it requires in its own container. This principle means that the local data always has to be merged before an overall picture of the application data is possible - for statistical analyses, for example.
• Higher clock speed: The cloud platforms and the tools used are constantly evolving. In contrast to traditional applications, it is not possible to simply avoid this high rate of change; instead, you have to constantly adapt your own applications and processes.
• Lifecycle management: The division into many individual components and the large number of technologies used make the processes surrounding the lifecycle of cloud-native applications considerably more complex.
• Governance: The increasing agility in software development inevitably leads to teams working very independently. A set of rules and organisational and technical measures must therefore be established in order to maintain control over applications and data at all times and ensure a consistent overall system.
• Security: The faster pace and new type of software architecture bring with them new threats and challenges in the area of IT security, the extent of which is almost impossible for inexperienced IT teams to grasp.

Myth #3: Cloud native is "secure by design".

This is a misconception. And a dangerous one at that. Compared to monolithic applications, there is actually a new security situation with new points of attack. These result from the variety of technologies used alone. The new concepts also bring numerous new components into play, such as required tools, third-party libraries or APIs. All of these elements also increase the number of conceivable attack vectors, which are difficult for inexperienced teams to keep track of.

The fact that Cloud Native can still be operated securely is thanks to the threat defence methods, which have also been further developed. There are measures and tools to ensure security at every level of granularity, from programme code and containers to the entire cloud. However, this requires customised security concepts combined with clear responsibilities that define which teams and roles have to take on which tasks.

Myth #4: Cloud native is all about reducing costs.

This is misleading. The cost-cutting effects are often only short-term. In detail, this means that a lift-and-shift move of workloads on your own infrastructure to the cloud usually initially brings cost benefits, e.g. because unused server capacity no longer needs to be kept available (elastic scalability through pay-as-you-grow billing models) and capital expenditure is replaced by operating costs (OPEX instead of CAPEX). And cloud-native applications can achieve additional cost benefits through more efficient resource utilisation and fast implementation times. However, these are less significant than in the former case. What is often overlooked, however: In most cases, the supposed savings are relativised by higher operating costs in the further course due to increased complexity (keyword: Day 2 operations).

Much more important than positive TCO effects are the potentials of cloud native in terms of efficiency and speed. Companies can drive digital transformation and remain innovative by continuously modernising their own applications in order to further develop their business area. This gain in competitiveness is significantly more valuable than a reduction in IT costs.

Myth #5: Cloud native does not require a new operating model.

This assumption is wrong. Suitable models and concepts must be found for cloud native operation that do justice to the changed framework conditions. However, the fact that developers are also jointly responsible for operating the applications in line with the DevOps concept must be reconsidered for cloud native. This is because the new complexities make it difficult for developers to cover the entire field of requirements. There are best practices tailored to cloud native for a new distribution of roles that address this challenge.

Conclusion: Rethinking enterprise applications

Cloud-native software stacks require new processes and approaches beyond the narrower field of application management. Nevertheless, the cloud-native approach is an essential prerequisite for companies to successfully master the digital transformation and keep their applications and application development itself modern in the long term.

If the digital transformation is to succeed, companies must start with a solid IT concept and create the right digital foundation. Cloud Native is an essential building block for this. This is because the concept offers a whole new level of innovation potential for business applications.

Cloud-native computing is more than an evolutionary step, it is a paradigm shift. This also means that the associated processes, values and technologies must be integrated into the strategy, organisation and corporate culture. In practice, these non-technical points are decisive in determining whether the respective cloud-native strategy ultimately leads to success.