Cloud-native applications between buzzwords and real need
Introduction
Cloud-native is a term that has become increasingly popular in the field of software development and IT infrastructure, particularly with the rise of cloud computing and containerization technologies. While there isn't a single universally agreed-upon definition, there are common principles and characteristics associated with being "cloud-native."
"Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach."
Practically we can define these applications as applications that satisfy a set of principles that often revolve around the idea of designing and building software applications and systems that are optimized for cloud environments, taking advantage of cloud services and technologies.
Cloud-native applications represent a significant shift in the way we design and deploy software. It is a response to the evolving landscape of cloud computing and modern infrastructure technologies. Cloud-native applications are not just a trending buzzword; they offer substantial advantages when properly applied.
?
Cloud Computing Vs Cloud-Native
Are all applications hosted on the cloud can be considered cloud-native apps?
Some people conflict between cloud-native apps and hosting only legacy software on a cloud provider. And to make it clear the direct answer is no since any application can be hosted on cloud providers but some of them will be considered as cloud native.
This subset needs to apply a set of principles and there are four main pillars behind these principles.
Service Oriented
Service-oriented is a popular architectural framework for building enterprise apps. The role of each service in cloud-native apps is to run part of the application to serve on specific context. They are arranged in containers where each one can be managed in separate containers and be updated/repaired independently not affecting others. Features are run efficiently and quickly, thanks to cloud-native apps.
Containers
In cloud apps, containers can be found everywhere. Containers package code allowing multiple apps to run quickly and efficiently. The apps can be built into a set of coupled services that can be controlled under a container that is independent of the overall structure. Each service can be updated/repaired within the container.
Continuous Deployment and Delivery
Due to using the Agile methodology and practices, continuous deployment and delivery ensure that the entire software development process from start to finish runs smoothly and gets things done faster during the product life-cycle. Small parts of the software are consistently transferred to production by the process of automation. Developers can swiftly test and implement new code in production. Businesses can bring their new ideas and features to life in a matter of hours and make any changes they'd like without experiencing any trouble along the way.
DevOps
DevOps is a set of practices where software developers and IT operations work together to achieve a common goal of constantly delivering high-quality software solving challenges. In short, DevOps makes software delivery smooth and efficient and reduces risks allowing developers to thoroughly test and experiment with the software. Building, testing, and deploying cycles frequently and smoothly.
Service Oriented & Microservices
If you notice in the previous section I mentioned service-oriented not micro services. the reason behind this is micro service becoming a buzzword and some people become angry when hear it.
To make it simple let's agree on the common rule for large applications while you have many contexts it's crucial to divide it into a set of small applications each one has its own SDLC.
Name it a microservice or name it something else it doesn't matter.
One more important tip is not only the size of the application will guide this split of the scale but the importance of the context can lead you to decide to separate it into dedicated service and then give it proper focus during SDLC.
?
Additional consideration
The four pillars shape the cloud-native building process but some authors go beyond the four pillars and agree on set factors generated for the main pillars but with a wider scope to create modern design benefits from cloud-native APIs.
These factors can be named as 12 factor and the application satisfying them can be named as 12 factor app:-
1 - Code Base
A single code base for each microservice is stored in its repository. Tracked with version control, it can deploy to multiple environments (QA, Staging, and Production).
2 - Dependencies
Each microservice isolates and packages its dependencies, embracing changes without impacting the entire system.
3 - Configurations
Configuration information is moved out of the microservice and externalized through a configuration management tool outside of the code. The same deployment can propagate across environments with the correct configuration applied.
4 - Backing Services
Ancillary resources (data stores, caches, message brokers) should be exposed via an addressable URL. Doing so decouples the resource from the application, enabling it to be interchangeable.
5 - Build, Release, Run
Each release must enforce a strict separation across the build, release, and run stages. Each should be tagged with a unique ID and support the ability to roll back. Modern CI/CD systems help fulfill this principle.
6 - Processes
Each microservice should execute in its process, isolated from other running services. Externalize the required state to a backing service such as a distributed cache or data store.
7 - Port Binding
Each microservice should be self-contained with its interfaces and functionality exposed on its port. Doing so provides isolation from other microservices.
8 - Concurrency
When capacity needs to increase, scale out services horizontally across multiple identical processes (copies) as opposed to scaling up a single large instance on the most powerful machine available. Develop the application to be concurrent making scaling out in cloud environments seamless.
9 - Disposability
Service instances should be disposable. Favor fast startup to increase scalability opportunities and graceful shutdowns to leave the system in a correct state. Docker containers along with an orchestrator inherently satisfy this requirement.
10 - Dev/Prod Parity
Keep environments across the application lifecycle as similar as possible, avoiding costly shortcuts. Here, the adoption of containers can greatly contribute by promoting the same execution environment.
11 - Logging
Treat logs generated by microservices as event streams. Process them with an event aggregator. Propagate log data to data-mining/log management tools like Azure Monitor or Splunk and eventually to long-term archival.
12 - Admin Processes
Run administrative/management tasks, such as data cleanup or computing analytics, as one-off processes. Use independent tools to invoke these tasks from the production environment, but separately from the application.
?
Advantages of designing app as a cloud-native app
Designing an application as a cloud-native app offers several advantages some of which will be provision to any application hosted on the cloud like:
Hardware Scalability: cloud resources can easily scale up or down to handle varying workloads. Cloud providers offer auto-scaling capabilities, allowing you to dynamically adjust resources as needed, which can be especially beneficial for applications with fluctuating traffic patterns.
Cost Efficiency: can optimize resource utilization, reducing operational costs. With the ability to scale resources on demand, you only pay for what you use, avoiding over-provisioning.
Security: Cloud-native applications can leverage cloud provider security features, making it easier to implement robust security measures. Additionally, many cloud providers offer built-in security services, like identity and access management (IAM) and DDoS protection.
Improved Resource Management: Infrastructure as Code (IaC) allows you to define and manage your infrastructure in a programmatic and version-controlled way. This simplifies resource provisioning, configuration management, and resource monitoring.
Global Reach: Cloud-native apps can take advantage of a cloud provider's global network of data centers, enabling you to reach a broader audience and reduce latency for users in different regions.
?
When you design the application as cloud-native you can gain additional benefits:-
?
Resilience and High Availability: Cloud-native architectures are designed with resilience in mind, minimizing downtime and service interruptions. They often incorporate redundancy and fault-tolerant mechanisms, making it easier to achieve high availability.
?
Faster Time to Market: Cloud-native development practices, such as microservices and continuous integration/continuous deployment (CI/CD), enable faster development cycles and quicker releases. This agility can help you bring new features and updates to users more rapidly.
?
Flexibility and Portability: Containerization (e.g., Docker) is a common practice in cloud-native applications, making them more portable across different cloud providers and on-premises environments. This flexibility can help avoid vendor lock-in.
?
DevOps and Automation: Cloud-native development encourages the adoption of DevOps practices, which emphasize automation, collaboration, and rapid feedback. Automation streamlines deployment and operations, reducing manual errors and improving efficiency.
?
Observability: Cloud-native applications often incorporate robust monitoring and logging, making it easier to gain insights into application performance and troubleshoot issues quickly.
?
Backing services: cloud providers provide many different ancillary resources, such as data stores, message brokers, monitoring, IOT, Machine learning, and identity services.
These services are fully managed by cloud providers which means they will care about installation, configuration, maintenance, and batching.
In cloud-native app design, you will focus on design services to cover the actual application business and depend on ready backing services provided by the cloud providers.
?
Microservices Architecture: The use of microservices in cloud-native applications allows for easier maintenance, updates, and scaling of individual components, reducing the impact of changes on the entire application.
How to decide to go as cloud-native apps
When it became a buzzing word and many technical teams wanted to design cloud native for any application regardless the business case requires it or not we can see not all systems should be designed as cloud native.
The decision to design cloud-native or classic is not purely technical rather it's a mix between business and technical aspects.
The secret words here to decide designed system is cloud-native or not are (agility and scalability).
Agility means the ability to adapt to business requirements changes on time helping business to grow.
Scalability is the ability to adapt system capabilities to cover sudden increases in system scale.
The business team can't decide and well technical team can't decide.
The best choice is to collaborate between business and technical staff to address this critical decision.
I can give one hint that help you make a smooth decision, When designing an app that will act as a shared platform and contain more than one context executing hundreds of thousands or millions of requests daily it's crucial in this situation to build a cloud-native.
If you build a small internal system that serves one context to execute a limited number of requests daily then designing as cloud-native will complicate the development process without real benefits.
?
Conclusion
Cloud-native applications leverage cloud services, containerization, microservices architecture, continuous deployment and delivery, and DevOps practices. This approach results in several notable benefits, including scalability, cost efficiency, improved resource management, high security, and faster time to market. They also allow for global reach, resilience, flexibility, and observability.
?
However, it's essential to recognize that not all applications need to be designed as cloud-native. The decision to go cloud-native should be based on a combination of business and technical considerations, focusing on agility and scalability. In some cases, especially when building shared platforms or systems that require extensive scalability, the cloud-native approach is highly advantageous. For smaller, internal systems with limited demands, a cloud-native design may not be justified and could complicate the development process unnecessarily.
?
Ultimately the main idea to decide on cloud native or no is agility and scalability. Since, the choice to embrace cloud-native practices should align with the specific needs and goals of the project, striking a balance between technical capabilities and business requirements.
?
?
References
?
?
CTO @Tie Shop | Agile Strategy Technologist | Driving Growth through Digital Transformation | E-commerce Expert | Innovative and Customer-Focused
2 个月Good effort thanks