Cloud-Native Architecture Part I — Principles Part I

One of the main goals for software architects and designer is to design best-in-class and high-quality software applications. The architects and designers need to adopt software design principles to achieve the desired result.

Cloud-Native Architects and Designers should apply these principles for designing and developing cloud-native applications. These principles help the team to deliver quality software to the customers.

Be Smart with State Principle (BSSP)

The Be Smart with State principle states when and how you store state in your design. Storing of the state is the hardest aspect of architecting a distributed, cloud-native architecture. Therefore, architecting your system should stateless wherever it is possible.

The stateless means that any state is stored outside of a container, this external storage can store in various storage. By storing data externally, you remove data from the container itself, meaning that the container can be cleanly shut down and destroyed at any time without fear of data loss. If a new container is created to replace the old one, you just connect the new container to the same datastore or bind it to the same disk.

Stateless components are easy to:

• Easy to destroy and easy to create: the stateless components have no dependency on state to carry, therefore, the application in a container can destroy and create easily with no time
• Easy to Repair: if you want to repair failed instances in your deployment, simply terminate gracefully and spin up a replacement
• Autoscale/Horizontal scale: To scale more instances, just add more copies, the orchestrator can manage the scale-up and down. This scale can be managed automatically based on load or CPU usage
• Rollback: if you have a wrong deployment, the stateless containers are much easier to replace with new ones without any human intervention
• Load balance across - Load Balancing is much easier since any instances can serve any request from a requestor if you have state full instance, you need to send requests to the same instances, these can be managed with sticky sessions.

Defense in Depth Principle (DiDP)

The DiDP provides series of security mechanisms and controls are layered throughout a computer network to protect the confidentiality, integrity, and availability of services.

Services in cloud-native architecture have deployed and process a request for internet applications and always there will be threats from external and internal attacks. Always use an authentication mechanism between services and minimize trust between those services, whether it is an internal or external service.

You need to apply principle not just authenticating the services to avoid rate limiting or script injection but you should protect your services from any threat. This makes your architecture more resilient and easy to deploy and create more trust for your services. The DiDP principle ensures network security is redundant, preventing any single point of failure.

An effective DiDP strategy may include following security best practices, tools, and policies.

• Firewalls
• Intrusion prevention or Detection system
• Endpoint detection and response
• Network segmentation
• Strong Password
• Patch Management

Always be Architecting Principle (AbAP)

One of the core objectives of cloud-native applications is always evolving. You should always use this principle when you architecting the system as your application seek to refine, simplify and improve the architecture to support business disruption, organization change, the landscape of IT system change, and technology disruption. Dead, rigidifying IT systems bring the organization to a standstill and unable to support business disruption.

Cloud-native architecture does not replace traditionally, but they are better adapted to the very different environment of the cloud.

Isolate Failure Principle (IFP)

Embracing a Cloud-Native architecture doesn’t automatically make your system more stable, design how to isolate failure in your microservices is key to ensure that your microservices become fragile. Microservices are not reliable by default, therefore you can’t assume your microservices becomes more resilient or scalable by default.

For example, you have five microservices of one system, for this system to work, all five services to be up and running. If anyone services down, it may impact as a whole process, therefore all five have to be available at any given point of time otherwise the system stop processing all requests, so once service goes down takes them all down.

If any one of services fails, the system stop working, if any one of the networks between services stops, it fails, your services stop working. Therefore your services less reliable.

You have to consider what happens if every single one of our services fails, and need to avoid a single point of failure. What happens if every single one of your services fails? Can your system keep running? Do you even know what happens when your users talk to your services, forex, can talk to your catalogs but your application cannot invoke inventory services to show the catalog? Do you want to stop as a whole system or you allow users to buy a product without available in inventory?

Particularly subtle sort of failures that can happen in a distributed system is the cascading failure, all the way far down chain fails (Service A calls Service B and Service B calls Service E), this ripples all the way the whole system down.

Cascading failure can hurt a whole system and you need to design your system to protect this. You need to isolate the failure in each and every part of your system.

Principles of Orthogonal

In mathematics, the orthogonality describes the property of two vectors, they are perpendicular or 90° to each other. Each vector will advance indefinitely into space, never to intersect.

Well architected software is orthogonal, each of its component or module can be modified without affecting other. By considering agility in both business and technology, the software applications undergo many changes to support disruption in business. The cost of applying orthogonal principles is a little high but by considering the cost, in the end, the overall cost will be managed by considering changeability, testability, and extensibility, etc.

The Orthogonal design is based on two principles

• Cohesion
• Coupling

Cohesion

Cohesion is the degree to which the elements inside a module belong together. It is the strength of the relationship of elements within the module. It is the internal glue that keeps the module together.

It is a measurer that defines the degree of intra-dependability within elements of a module. The greater the cohesion, the better is the program design. It is a natural extension of the information hiding concept.

A cohesive module performs a single task within a software procedure, requiring little interaction with procedures being performed in other parts of a program. We always strive for high cohesion, but sometimes the middle path of the spectrum is always acceptable.

Cohesion is an ordinal type of measurement and is generally described as “high cohesion” and “low cohesion”

High Cohesion is where you have a module that does a well-defined job with similar elements, it gives us a better-maintaining facility, reflects a better quality of a design. Reusability is high as all elements in the module work together as a logical unit of work with clear functionality. It makes it easier to

• Understand what class or method does
• Use descriptive names
• Reuse classes or methods

Low Cohesion where you have a module that does a lot of unrelated jobs, results in a monolithic module that is difficult to maintain, extend and test. The extra complexity in modules with low cohesion makes it more likely that defects may be introduced and leads to high technical debt. Reusability is reduced for modules as performs diverse functionality.

Types of Cohesion

Coupling

Coupling is the degree of interdependence between software modules or microservices; a coupling measures of how closely connected two modules or microservices are and the strength of the relationship between modules or microservices. Coupling tells at what level the modules are interface and interact with each other. The coupling can be low or weak and high or strong or tight. The degree of the coupling between modules reflects the quality of the design

No Dependencies, Loosely coupled with some dependencies and Highly coupled with many dependencies

Coupling is the measure of the interdependence of one module to another. Modules should have low coupling, low coupling minimizes the ripple effect where changes in one module cause an error in another module.

Software modules that are tightly coupled are more complex, it is the degree to which one module is connected to another module, if a module is tightly coupled, then you are bound to use/edit the rest of the connected modules were only editing one module could have served the purpose. This impacts the principle of maintainability, extensibility, and testability. You need to carry out a full suite of a test of entire connected modules irrespective of modification, this increases the cost and effort.

The Loose Coupling design is to reduce the dependency that a change made within one module or microservices will create unanticipated changes within other elements. Individual modules can be altered, extended without the need of taking into account a lot of information from other modules. Errors or data flow can be pointed easily. The loose coupling supports the principle of maintainability, extensibility, and testability.

Types of Coupling

There are different types of coupling, the following are the details of these types in order of lowest to highest coupling. The coupling between the modules can be more than one way.