1. What Cloud-Native Applications are – Introduction
The term cloud-Native Apps can have many meanings. In this post, we want to share some considerations, definitions and some values, practices and tools.
Business and IT have never needed to be so aligned as they are today. We live in an era of constant innovation and not to say at least daily. More and more startups come up with innovative ideas leveraged by the facilities offered by IT tools. It is true that good ideas are not only coming from startups, and even companies already consolidated in the market with great legacies and heavy investments in traditional infrastructure are able to break the barriers of innovation imposed by their respective organizations.
In order to sell value to the business, all companies seek to declare themselves agile, especially with regard to the capacity for innovation, after all, it becomes very difficult to remain competitive when a competitor manages to conceive an idea, implement, test, approve and publish a new IT-based business much faster and more effective than your organization.
For some time it was imagined that this agility basically depended on an infrastructure capable of offering the development team the right tools and platforms to achieve the much-desired agility to innovate. What was observed was the so-called Innovation Gap, which corresponds to the space between the capacity offered by the company’s IT infrastructure and the new demands of the business for innovation.
The much-desired agility, in addition to the basis for an innovative capacity, serves as a basis for the delivery of other agility values such as:
The infrastructure has managed to advance significantly in recent years by delivering platforms, tools, and features in order to greatly reduce the innovation gap of organizations. Cloud Computing, CI/CD tools, agile virtualization, containers, increasingly powerful and comprehensive automation are among the main initiatives provided by the infrastructure in order to support an increasingly challenging and demanding development environment.
Although the advances in infrastructure are significant, many organizations have not experienced the promised agility in practice, nor have they been able to take advantage of its advantages. One piece of this huge puzzle, the applications, was missing. How can applications be able to make efficient use of all this technology framework? How to build applications that are agnostic to the execution environment and know how to adapt wherever they are deployed? It is in this context that we apply the concepts of cloud-native applications.
2. Cloud-Native Applications
The CNCF documentation provides us with a very comprehensive definition of the term 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.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.”
The term cloud-native applications is an approach to developing software solutions with this paradigm in mind, that is, they are applications that appear ready to run in a modern and agnostic execution environment that offers a variety of services for these solutions. It is not a technology in itself or a language itself, but a series of interconnected resources that allow a high degree of transparency and low coupling for applications.
For an application to be minimally classified as a cloud-native application, it is important that it has at least the following characteristics:
- API Oriented
- DevOps Automation and Collaboration
At this point, the objective is to build modular applications with flexible coupling seeking high cohesion in its modules. They can be microservices, mini-services or any size of service you want, including applications considered to be monolithic, it doesn’t matter, as long as you look for modularization and focus on exposing services that can be consumed by other services or graphical interfaces. Modules are by nature leaner and more cohesive, which allows greater agility for change, implementation, and scale.
2.2 API Oriented
Once the application is born with the objective of offering services, it is only natural that these services are exposed to the world through very well defined and documented APIs. It is not allowed that there are other ways to consume the data and resources of the application that are not through its APIs. APIs seek to reduce the coupling between systems allowing greater control over service contracts, versioning, and agility to change.
The packaging and distribution of applications in the form of containers favors the encapsulation of all dependencies of the application as well as offering a known execution environment. This approach favors the implementation of solutions in container orchestrators available in the most diverse infrastructures such as Kubernetes.
2.4 DevOps automation and collaboration
The solution must be managed by processes and practices that observe a delivery belt respecting continuous automation practices. Collaboration is the main key to the achievement of this value, here we seek the integration between quality assurance practices by the development team as well as adherence to a safe and scalable environment provided by the operations team.
It is important to note that many of the cloud-native application approaches treat it as a modernization journey. With each advance towards the status of cloud-native application, new features are discovered, new practices are consolidated and the team as a whole evolves to the next stage of the journey. Therefore, it is not always possible to implement all values in a single round in applications that were not designed for the world of cloud-native.
Below we demonstrate the main differences in the vision of traditional development and focusing on cloud-native.
Scale-up vertically Scale-out horizontally
Tightly coupled monolith
Loosely coupled and service-based
Portable across infrastructure
Waterfall, semi-agile, and long delivery
Agile and continuous delivery
Local IDEs & developer tools
Cloud-based, intelligent tools
Siloed dev, ops, QA, and security teams
DevSecOps, NoOps, and collaboration
3. Cloud-Native Applications practices
In order to support the community in the development of cloud-native applications, there are several techniques and practices that are widespread and shared, among which it is worth highlighting a series of practices that became known as the twelve factors for applications. Although initially, this catalog of good practices mentions that its focus is to develop applications as a service (SaS), its values are perfectly applicable and its recommendations for cloud-native applications.
3.1 Twelve Factor
- Codebase – One codebase tracked in revision control, many deploys
- Dependencies – Explicitly declare and isolate dependencies
- Config – Store config in the environment
- Backing services – Treat backing services as attached resources
- Build, release, run – Strictly separate build and run stages
- Processes – Execute the app as one or more stateless processes
- Port binding – Export services via port binding
- Concurrency – Scale out via the process model
- Disposability – Maximize robustness with fast startup and graceful shutdown
- Dev/prod parity – Keep development, staging, and production as similar as possible
- Logs – Treat logs as event streams
- Admin processes – Run admin/management tasks as one-off processes
3.2 General Practices
In general, practices for the development of Cloud Native applications seek to privilege mainly the independence of the application in relation to the environment where it will be executed, for this reason, the use of containers becomes so crucial since with this it is minimally guaranteed that the package of solution delivery remains unchanged and its development cycle was previously validated and approved.
It is also important to emphasize the ability to adapt the solution to the environment where it is executed without creating any kind of coupling, in practice, any external dependency becomes a resource provided by the infrastructure at the time of execution.
4. Cloud-Native Apps Values
In addition to the values obtained already mentioned by the practices of the 12 factors, we could summarize that by adopting the development model aimed at cloud-native applications, we are looking for the following values:
- Speed, Safety, Scale
- Client Diversity
- Self-service, agile infrastructure
- API based collaboration
5. Frameworks and Helper Tools For Cloud-Native Applications
Many languages and platforms offer a number of resources for implementing cloud-native applications. The Java universe is full of these resources, we can mention some of the frameworks and standards aimed at implementing cloud-native solutions:
- Spring Cloud
More important than a set of techniques, frameworks, and tools, the concept of cloud-native applications brings with it a new way of thinking and seeing solutions. Developers become more aware of the functionalities available for their solutions and are able to abstract a lot of infrastructure code.
More modern solutions such as Service Mesh are able to add functionality to deal with network issues transparently to the application code making the developer focus more on the application business and less on the infrastructure. Modern development paradigms such as microservices represent a part of the concept of cloud-native applications.
With a greater focus on business, it is natural to gradually migrate the size of applications and increase the level of cohesion and reduce their coupling. It is important that this technological advance is accompanied by a change of thinking in the organizational structure where these practices are maturing. Otherwise, the capacity for innovation and all the advantages will be doomed to fail to imitate an organizational structure that does not allow reaching satisfactory levels agility in any of the pillars required for the cloud-native model.