on September 11, 2023 -

Software architecture of any application or platform is usually evolved throughout the software development journey. There are several challenges faced during this architecture evolution process e.g. it is very difficult to track changes introduced or incorporated from the beginning of the architecture. Like automated deployment process of functional stories makes the things in software development easy to manage or view the change history throughout various versions and enables implementation-team to map code changes with actual requirement since beginning, sameway infrastructure-as-code (IaC) brings opportunity to practice automated CI/CD pipeline for coding required for infrastructure setup, which can further be extended to other types of software-architecture like functional-architecture, deployment-architecture etc. In this article, I will touch-base a few important aspects of software-architecture-as-code including some of popular tools.

#softwarearchitecture #softwarearchitectureascode #infrastructureascode #cicdpipelineforsoftwarearchitecture #toolsforinfrastructureascode

How to automate software-architecture, using architecture-as-code approach

During any software project implementation, various types of architectures are written as following

Functional architecture (which are collection of functional components or domain/subdomains)
System architecture (which could be on-premises or on-cloud)
Integration architecture (which is used to represent communication approach between functional components)
Deployment architecture (which defined the strategy of source code versioning and deployment in relevant environments)
and so on..

These are different types of software-architectures used for relevant purposes and are considered as master-architecture or foundation-architecture which will remain same for implementation of any use-case e.g. say application having use-cases onboarding-of-a-new-employee, exit-of-an-existing-employee, the foundation-architecture will remain the same including other use-cases.

During the execution of large-complex-long (LCL) projects, many architectural-changes will be incorporated in the foundation-architectures e.g. some of the upcoming use-cases may require a new ABB (architecture-building-block) to be added in the foundation-architecture, then a new version of foundation-architecture will be added to artifacts repository and published to stakeholders.

Let’s talk by some examples regarding changes in the foundation-architecture, suppose cache-layer (ABB) was not incorporated in the system-architecture of foundation-architecture. Reason behind the same was that none of the use-cases needed the cache-layer (ABB) in the initial version of foundation-architecture and considering simplicity in architecture, budget priority, incorporation of cache-layer in the foundation-architecture was deferred to the time when need will occur.

Let’s consider some sample architecture-diagrams of system-architecture & functional-architecture which will be referred multiple times in this article.

System architecture diagram

System architecture : standard architecture building blocks (ABBs)

Functional architecture diagram

Functional architecture : common components or domain/subdomains

Closer view on setting up the software-architecture

Just to show the bigger picture or top view of overall software-architecture to the readers of this article, any software-architecture will have two high level sets of activities:

Setting up the infrastructure-architecture (which is required for hosting of application or its components)
1. e.g. JBoss AS to setup for API backend, Apache Tomcat server to setup for API backend, Apache Active MQ server to setup for queue-layer, Redis server to setup for cache-layer, MySQL/Postgres server to setup for database-layer, and so on.
2. As a matter of fact, most of the applications or platforms will require almost similar kind of system-architecture with similar kind of ABBs in the diagrams or few ABBs may-be ON/OFF or few new ABBs may be required to be added.
3. Sharing an architecture-building-block (ABB) might be shared among multiple functional-components e.g. database-layer can be isolated or shared among multiple applications or functional-components, queue-layer can be shared among mobile-app, web-app, notification-app etc.
4. Co-hosting multiple architecture-building-block (ABBs) might also be co-hosted on the same machine e.g. to reduce the infrastructure expense web-server-layer, queue-layer, cache-layer can be co-hosted on the same machine.
5. Important point to highlight here is that sharing of ABB or co-hosting of multiple ABBs will not make any difference in overall system-architecture.
Setting up the application-architecture (which is required for application installation and ready-to-run)
1. e.g. setting-up Employee-information-management for managing employee profile, setting-up User-management for sign-up/sign-in/sign-out processes, Cart-management to receive orders into CART, Order-management to perform order-life-cycle on orders received from Cart-management.
2. Now readers can refer to the functional-architecture diagram and try to visualize the required system-architecture is mostly the same for each functional-component or domain/subdomain.
3. The readers (being architects) will be able to correlate that the set of required ABBs for each functional-component or domain/subdomain are more-less the same.

So in nutshell software-architecture-as-code (SAaC) concept can be defined as writing code for setting up infrastructure & application as follows

Writing the code to setup infrastructure-architecture will be called infrastructure-architecture-setup-as-code (IASaC) or infrastructure-as-code (IaC).
Writing the code to setup the entire application-architecture on deployed infrastructure by IaC approach will be called application-architecture-setup-as-code (AASaC).

Adopt Infrastructure-as-code (IaC/IASaC) over conventional approach

Let’s understand how the infrastructure is setup in conventional methods i.e. configuring infrastructure before IaC.

Step-1 : Get physical servers (bare-metal machines) and establish physical connectivity among them via network cable
Step-2 : Setup host operating system (e.g. Ubuntu, CentOS, RHEL, Windows Server, etc.) on all physical machines
Step-3 : Setup virtualization tools as per your convenience (e.g. VM Ware, Windows Hypervisor, etc.)
Step-4 : Create virtual-machines and setup guest-operating-system on VMs
Step-5 : Install & setup software tool for required ABB as per required system-architecture e.g. load-balancer, API-gateway, web-server, queue-layer, cache-layer, etc.

Now if we analyze all of the above steps closely, only step-1 will require human intervention at the location of physical-machines and remaining steps (2,3,4,5) can be performed remotely via command-line or API or admin console.

So the steps which can be performed remotely via command-line or API, can be bundled into one or more executable-programming-scripts which can be executed in a logical sequence of steps. This is the actual idea behind infrastructure-as-code and the many popular tools can be used to write infrastructure-as-code (IaC).

Steps (4 & 5) are comparatively more frequent tasks be it the first time setup or be it the regular upgrade, so these tasks are very suitable candidates which can be achieved via IaC approach. Below diagram explains the life-cycle of infrastructure-as-code (IaC).

IaC standard workflow

Life-cycle of infrastructure-as-code (IaC)

Seq	ABB Name	Decomposed tasks/activities under IaC / IASaC (on premises & virtualized)
1	Load-balancer-layer	Write driver code which will call following methods sequentiallyWrite method to setup VMWrite method to setup guest OSWrite method to setup load-balancer-layer of preferred vendor
2	Web-server-layer	Write driver code which will call following methods sequentiallyWrite method to setup VMWrite method to setup guest OSWrite method to setup web-server-layer of preferred vendor
3	Queue-layer	Write driver code which will call following methods sequentiallyWrite method to setup VMWrite method to setup guest OSWrite method to setup queue-layer of preferred vendor
4	Cache-layer	Write driver code which will call following methods sequentiallyWrite method to setup VMWrite method to setup guest OSWrite method to setup cache-layer of preferred vendor
5	Application API layer	Write driver code which will call following methods sequentiallyWrite method to setup VMWrite method to setup guest OSWrite method to setup API-server-layer of preferred vendor
6	Database-layer	Write driver code which will call following methods sequentiallyWrite method to setup VMWrite method to setup guest OSWrite method to setup database-layer of preferred vendor
7	Observability layer	Write driver code which will call following methods sequentiallyWrite method to setup VMWrite method to setup guest OSWrite method to setup observability-layer of preferred vendor

** For the sake of simplicity in the article, the above table is not considered for containerized and cloud environments. Maybe the same will be covered in some other article.

Adopt application-architecture-setup-as-code (AASaC) over conventional approach

Let’s understand how the application is setup in a given infrastructure using conventional approaches i.e. installing applications before AASaC.

Step-1 : Identify the required configuration of each application (which needs to be provisioned on relevant infrastructure)
Step-2 : Open the admin console of corresponding infrastructure tool e.g. RedHat JBoss AS, Apache Tomcat, Apache Active MQ, Redis Server, Postgres/MySql admin panel.
Step-3 : Deploy application binary
Step-4 : Perform test related to required application configuration on infrastructure
Step-5 : Repeat steps 1 to 4, if any issue.

Now let’s understand how an application should be defined. Definition or size of an application will vary based on the architecture style, but the approach of software-architecture-as-code does not differ by any application’s architecture style e.g. monolith or microservice or micro-frontend for all approach of software-architecture-as-code will remain same. In order to be focused with the objective of this article, it is not important to discuss various architecture-styles.

For the sake of understanding, we shall refer to the functional-architecture diagram provided in the above section. From the functional-architecture diagram, every component is called functional-component, which can also be called functional-application or domain. Each functional-application can further be decomposed into smaller-functional-application or sub-domain. For this article, we don’t need to be bothered about scope or boundary of functional-application or domain or smaller-functional-application or sub-domain, for us everything is a micro-application which will consist of micro-frontend, micro-service & micro-database.

AASaC standard workflow

Identify required configuration for each micro-application
Identify the ABB where configuration will be provisioned
Write code for configuration provisioning
1. Write code for connectivity command with ABB
2. Write code for provisioning command for required configuration
3. Write code for exceptional scenarios
Bundling of steps, but this is not mandatory step
1. Multiple micro-applications belonging to one domain or subdomain for functional-application can be bundled together
2. Multiple ABBs belonging to one micro-application can be bundled together

Now we have a fair understanding of how the concept of software-architecture-as-code can be leveraged into your project to bring architecture level automation. In order to write code for any piece, there are many tools as explained in the next section [Popular tools].

Please also apply modular design & separation-of-concern design approach in software-architecture-as-code i.e. code & execution of IaC/IASaC or AASaC should be isolated from each other, so that codes for setting-up infrastructure or application will remain completely independent and manageable in isolation.

Popular tools to write your IaC/IASaC & AASaC code

Above IaC standard workflow is very similar to functional code of any functional-epic-or-user-stories during sprint development. IaC’s code-&-review-stages will remain same as functional-epic-or-user-stories i.e. IaC code would be written freshly or existing code would be updated, unit-testing would be performed, code-coverage & test-coverage would be verified at local level, PR request would be raised for review and code-merge in the higher environment. Same time the IaC’s apply-stage is a very critical task and since these are not frequent tasks, it is nowhere mandatory to automate the deployment of IaC build.

Reference links : Popular IaC tools

Terraform

Terraform is an open-source tool for infrastructure-as-code developed by HashiCorp. One can write configuration-files (equivalent to installation script) in Terraform for both kinds of deployment platforms on-premises & cloud.

HashiCorp Terraform write-to-apply workflow

Source : Terraform official documentation

Terraform configuration-files are human-readable and can be managed via version-management-tool like Github, Gitlab etc., only the apply stage has to be very careful as this will change the existing infrastructure setup and any small mistake may stop the already working production environment.

Example during foundation-architecture, Terraform scripts for postgres DB setup were written as per active-passive high-availability setup e.g. after 1 or 2 years now customer wants to change HA strategy to A-P to Multi-master replication topology based database architecture. Writing Terraform scripts is the most easy part while applying the target terraform script comes lots of activity including export-import of database and outage for export & important.

Other reference

Ansible

Ansible is an open-source tool for infrastructure-as-code developed by RedHat. One can write configuration-files (equivalent to installation script) in Ansible for both kinds of deployment platforms on-premises & cloud.

RedHat Ansible provides a rich workflow creation feature, where one can create an ansible project, select workflow templates, define jobs under workflow for actual provisioning.

Ansible workflow

Other reference

Puluni

Puluni is an open-source tool for infrastructure-as-code developed by Pului. One can write configuration-files (equivalent to installation script) using Puluni packages for both kinds of deployment platforms on-premises & cloud.

Puluni comes with a great benefit that one can write infrastructure-as-code in any programming language including Python, Java, Node-JS and so on.

Puluni write-to-apply workflow

Source : Puluni official documentation

Other reference

Cloud vendor specific tools (e.g. AWS CloudFormation, Azure ResourceManager, GCP Deployment Manager)

Apart from above open-source IaC tools, every cloud provides their own IaC tool compatible with their own & others cloud-platforms. These cloud specific IaC tools also provide an automated CI/CD pipeline.

Reference link

Operating system level scripting language (e.g. Shell script for Unix, Linux or Windows)

This is a very conventional way of writing installer scripts for any ABB layer, most of COTS products come with <installer.sh or installer.bat> scripts which are nothing but the infrastructure-as-code only. Many readers should be able to refresh their memory for start.sh or start.bat for Apache Tomcat, install.sh or install.bat for Oracle database, similarly for mysql & postgres.

If someone does not want to go with any of available tools to avoid 3rd parties tools dependencies, they can write custom IaC capabilities with the implementation of decomposition tasks for each activity that is performed manually in order to setup the specific ABB’s infrastructure.

Which IaC tool?

The whole idea of this article was to provide high-level understanding about infrastructure-as-code and what are popular tools available to automate your infrastructure-as-code.

All of the above tools are popular & stable in market, and decision on which IaC tool will vary depending upon

Which tool’s skill-set is available with the team or what can be arranged?
Yours or client’s preference to go with an open-source license or enterprise license?
Which open-source vendor provides the safe-n-secure license which will not allow them to kill the open-source status of the IaC tool.

About author

Profile : Rajesh Verma – Brief profile

Source : link for this article here

Series : S1 (Architecture & design)

Episode : S1E2 (Software-architecture-as-code (SAaC))

Author’s approach : Rajesh wants to share his learning & experience gained throughout his career from various sources. Author started the series on architectural topics and this article is the first episode in that attempt. Author feels that lots of information is available on various forums, but scattered here & there. Episodes in this series will be designed for most of the relevant topics in architecture-&-design, published gradually and organized in logical sequence. Principally episodes will have linkage with other episodes, so that readers can have proper connection among the topics and would be able to correlate with ongoing activities in their software life. Topics for example will be related to functional architecture, integration architecture, deployment architecture, microscopic view of mostly architecture-building-blocks (ABBs), security guidelines & approach to comply, performance KPIs & engineering, git branch & DevOps enabled automation strategy, NFR aspects (e.g. scalability, high-availability, stability, resiliency, etc.), commonly used architecture styles & design patterns, cloudification approaches, multi-tenancy approach, data migration, channel-cutover & rollout strategy, process standardization & simplification, greenfield rollout & brownfield transformation journeys, etc.

Thank you for reading the post, please stay connected.

No Tag

Whitepaper : Software-architecture-as-code (SAaC)