Building Resilient, Scalable Cloud-Native Applications: How To Meet Business Needs While Providing Redundant Solutions

This is an article from DZone's 2023 Development at Scale Trend Report.

For more:

Read the Report

Back in 1986, I relocated to Boulder, CO, to work for my uncle's start-up company. When we arrived at the office that first day, he helped me to a nearby desk supporting a Compaq Portable computer. On top of the system was a book focused on using dBase II. My job was to build an application to track orders for his company. My uncle knew I had an interest in computers, and I couldn’t wait to get started. This became my first experience in learning how applications were built in an era of microcomputers. The flow was quite simple: 

• Document the requirements on what was needed
• Create a design that meets the defined needs
• Build and debug the solution
• Validate the solution works as expected
• Figure out how to distribute the solution
• Ask customers to adopt and use the solution

Figure 1: The No-Web application development lifecycle

While we are currently building applications and services in a Web2 and Web3 world, this era is what I often call the "No-Web" era of application design. 

Figure 2: Evolution of World Wide Web iterations

A few years later, I remember distributing Turbo Pascal-based applications on floppy disks for use by insurance agents located around the United States. Later, applications were stored on file servers that were housed in a corporate data center. The Web1 iteration was still a few years away.

While most of the application development lifecycle steps haven’t really changed, some important factors have emerged with cloud-based service providers: 

• Adoption of a centralized approach
• Scalability improvements
• Application and service resiliency

All of these aspects are benefits of cloud-native applications.

What Does Cloud Native Mean?

Wikipedia defines cloud-native computing as using cloud services "to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds." The transformation to the cloud became a high priority as corporations and startups became excited about getting out of the business of maintaining data centers.

Cloud-native applications are more than applications running in the cloud. One key differentiator is the manner in which applications are designed to run natively in the cloud. The adoption of containers, serverless, and microservices provide solutions that are easy to deploy from one environment to another — providing horizontal scalability and multi-region support at the same time. 

With the hardware layer abstracted from the codebase, cloud-native applications can scale vertically just as easily.

The Cloud-Native Approach

Adopting a cloud-native approach provides software engineers multiple greenfield opportunities as applications can be broken down into multiple aspects using common approaches:

• Serverless – allows event-driven requests to be offloaded to a functional-based lambda
• Microservices – breaks large applications into smaller processing units
• Containers – allows applications to become packaged into an isolated multi-layer container for distribution

For each aspect, cloud service providers offer add-ons which can be utilized to enhance the experience. Some common examples include: 

• API gateway – provides protection to services and handles common components (like authorization requests)
• Auto-scaling – scales up (and down) based upon pre-configured thresholds
• Caching – stores requested information in memory-based cache to avoid longer-running application requests
• Failover – automatically routes traffic to secondary nodes for processing
• File storage – object storage that is infinitely scalable and highly performant
• Load-balancing – distributes requests to instances which can be located in different geographical locations
• Orchestration – container solutions are automated, scaled, and managed at a grand scale 
• Persistence – use of SQL- and NoSQL-based data storage options
• Secrets management – avoids exposure of highly sensitive information

Since the cloud-native approach can be architected at the smallest grain, the resulting cloud-native application can yield the best solution for each aspect of the design, as illustrated in the simple example in Figure 3: 

Figure 3: A cloud-native application built from multiple cloud service features

Benefits of Cloud Native

Benefits of Cloud Native The cloud-native approach for building applications allows software engineers to architect solutions that employ the best technology at the use case level. This means that one use case could employ an event-driven serverless solution, while another can utilize a microservice backed by a SaaS-driven persistence layer. 

Cloud-native applications allow for a hybrid design of components that foster the best application experience.

The cloud-native approach allows components of the application to be scaled up (and down) as demand changes. This means the demand for one microservice does not require the same level of resource allocation for any other microservice. Additionally, component instances can be scaled horizontally across the same (or different) geographical regions. 

Since the hardware layer is abstracted from the application layer, those architecting cloud-native applications can remain focused on meeting business needs and corporate objectives.

These benefits provide a strong advantage when compared to applications designed to run in local data centers. The differences only widen when concepts like contingency planning or disaster recovery are considered. 

Challenges of Cloud Native

While cloud-native computing may appear to be application design nirvana, there are some challenges that should always be considered. The primary critique of cloud-native computing is the potential for costs to incur at higher levels than expected. 

Some common examples: 

• Losing track of prototype components that were never decommissioned
• Snapshots created automatically without an established retention schedule
• Over-allocation of hardware resources in cases where a cheaper option exists

Most cloud service providers provide excellent tooling to project and analyze costs, but it must be a widely adopted standard to make cost control a priority. When working in multiple regions around the world, it is important to understand regulations that exist — especially with sensitive data. Failure to comply could result in penalties or fees. 

Cloud providers offer the ability to provide multi-region failure and disaster recovery protection. However, these advanced concepts can be challenging to architect and design in a manner that allows for automatic failure but also protects against unexpected data issues.

Conclusion

As software engineers, we’ve come a long way since the No-Web era of application design. However, the one aspect that hasn’t changed for me is that I still get excited when I receive an opportunity to architect and design a new application. 

I have been focused on the following mission statement, which I feel can apply to any IT professional: 

Focus your time on delivering features/functionality that extend the value of your intellectual property. Leverage frameworks, products, and services for everything else.

Cloud-native application design adheres to my personal mission statement 100% because it allows for software engineers to remain focused on meeting the business needs of the customer: allowing the best solution to be utilized at the use case level. However, like every decision we make in life, we must always be cognizant of the associated costs.

Have a really great day!

This is an article from DZone's 2023 Development at Scale Trend Report.

For more:

Read the Report