With fast-paced technology evolution, software architecture is evolving each day with new patterns and technology choices. This article summarizes the top 10 tips you should know as a modern software architect and the list is not limited but evolving.

#1 – Be observant of frameworks providing acceleration towards Microservices Architecture (MSA)

  • With Microservices Architecture in mainstream adoption, most of the frameworks either have started remodeling themselves as per Microservices Architecture.
  • Key capabilities frameworks need to support are Lightweight & minimal Footprint, easy to learn, support for fault tolerance, observability (tracing, metrics, logging), security (authentication & authorization), etc.
  • While there are established frameworks like Spring and Play Framework in Java, be observant and ready to adapt new frameworks like Helidon, Quarkus, or Micronaut based on the requirement. Also, established players like Spring framework are coming up with new choices such as Reactive Stack for Microservices, Spring GraphQL, RSocket with Spring Boot, etc., which need to be applied as per the use-case.
  • Other languages have similar trends like Gokit & Gomicro for Golang, Flask, Bottle, Falcon, and Nameko for Python, and Molecular & Nest for NodeJS.
  • Another key aspect of Microservices Architecture is that you don’t need to use a single framework or technology for all microservices. You can choose the applicable programming language and framework based on the mechanics and requirements of a particular microservice.
  • Read about the Microservices evolution in Java by clicking here.

#2 – Choose the suitable pattern & technology for Microservices communication

  • Communication pattern between Microservices establishes the baseline for the future – there are many choices depending on the applicable use-case.
  • Start by choosing the data architectural pattern and then choose the communication style.
  • With many binary formats for efficiency, there are multiple choices available for message formats as shown below.
Decision TypeTechnology or Design Options
Communication PatternDatabase per Service or Shared Database
SAGA Pattern (Choreography vs. Orchestration)
CQRS Pattern
Event Sourcing Pattern
API Aggregation or Composition
Communication StyleRPC – Request/Response (Synchronous)
Event-driven (Asynchronous)
Polling-based (Asynchronous)
Callback (Asynchronous)
Message Format & ProtocolText Format – JSON with REST
Text Format – GraphQL with REST
Binary Format (e.g. Protocol Buffer) – gRPC
Custom Format for Event-driven (with communication platform such as Kafka, NATS) -Text/Binary Format – Duplex (bi-directional) using WebSockets, RSockets
Text Format with Webhooks (callback)

#3 – Apply standardization and use a design-first approach for APIs

  • API development is a mature field with growing standards, guidelines, and approaches. While there are many perspectives, the below standards help to bring consistency within the enterprise in terms of API development.
  • Read this article to know about API standards and guidelines for both RPC-style and Event-driven APIs.
Services & API Standards Evolution
Fig A – Services & API Standards Evolution

#4 – Start considering Service Mesh as an accelerator

In software architecture, a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between services or microservices, using a proxy. – Wikipedia

Service Mesh Key Capabilities
Fig B – Service Mesh Key Capabilities
  • Service Mesh is emerging as a standard for handling the communication and networking backbone for Microservices. Additionally, it handles other ancillary functionalities such as service discovery, client-side load balancing, timeouts, retries, and circuit breaking, security, etc.
  • Note that though Service Mesh started as a more suitable solution RPC-style communication between services, new patterns have emerged such as Event Mesh for event-driven Microservices as well.
  • Another aspect is overlapping capabilities of Service Mesh with API Management/Gateway solutions and there are many different perspectives by different subject matter experts on their applicability. The solution lies in between where both of them can be used collaboratively handling applicable responsibilities.

#5 – Use Cloud-native architecture wherever applicable

Usually, cloud-native is being resonated with cloud services being provided by Cloud Service Providers (e.g. AWS, Azure, Google Cloud, etc.) but building cloud-native software architecture plays an overarching role. Cloud Native Computing Foundation (CNCF) is a Linux Foundation project (founded in 2015), which is focusing the evolution of cloud-native software.

As per their charter, cloud-native technologies can be defined as:

  • 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.

As a software architect, you need to understand the landscape of cloud-native technologies. Though the cloud-native landscape currently shared by CNCF can be overwhelming, start considering the cloud-native technologies in your future state of architecture.

Cloud-native Landscape
Fig C – Source: https://landscape.cncf.io/

#6 – Apply Observability for end-to-end visibility

  • Observability is defined as a measure of how well the internal states of a system can be inferred from knowledge of that system’s external outputs. In simple words, observability is how well you can understand your complex system.
  • Observability has extended the concept of monitoring to a new level in terms of four key pillars – Metrics, Traces, Events, and Logs for end-to-end visibility (as shown below).
  • As a software architecture, SRE practices related to Observability is of utmost importance to ensure the system under consideration can sustain the business need after Go Live.
Metrics, Logs, Traces, Events
Fig D – Observability Pillars (MELT)

#7 – Accept Kubernetes as a foundational platform

  • Kubernetes is the new Linux and gradually becoming a de facto standard as a universal application platform. It will soon be pervasive as a hybrid cloud engine and platform-as-a-service for Microservices & cloud-native architecture. Click here to read more details about Kubernetes management strategy and approach (as shown below).
  • As a software architect, you need to ensure you have a good grasp on Kubernetes considering its wider industry acceptance and role as a foundational technology in diverse technology solutions.

#8 – Leverage Managed Services & Serverless as foundational blocks

  • As a software architect, your focus should be solving business problems, not just technical challenges. In the era of the cloud, managed services are a key enabler to focus on delivering business value and leave the management of technology to experts.
  • Cloud service providers (e.g. AWS, Azure, Google Cloud) have a comprehensive catalog of services nevertheless as an architect, you should also explore offerings by specialized vendors and other startup solution providers.
  • CNCF has broadly classified managed services and serverless technologies into four buckets – Tools, Frameworks, Platforms, and Hosted Platforms (as shown below)
Serverless Landscape
Fig F – Source: https://landscape.cncf.io/serverless

#9– Focus & apply zero-trust architecture practices

  • Zero-trust security (aka perimeterless security) is the new way of thinking security in modern architecture with 4 pillars in mind – people, devices, network & workloads.
  • As a software architect, creating a Zero-trust architecture (ZTA) is the need of the hour. NIST (National Institute of Standards and Technology) recognizes that the migration to a ZTA is more of a journey rather than a complete replacement of an enterprise’s infrastructure. Click here to read about the zero-trust Architecture white paper.
ZTA High-level Architecture
Fig G – ZTA Architecture
Source: Reference (NIST) – https://csrc.nist.gov/publications/detail/sp/800-207/archive/2019-09-23

#10 – Experiment and apply automation trends

  • The last but not the least aspect for software architects is to be aware of automation trends happening around the industry. Continuously experimenting & applying new trends is an essential engineering skill for a modern software architect.
  • Automation related to build and release, quality engineering (software testing), and software deployment and infrastructure management are three key areas to be observant of as a software architect.
  • GitOps (a way of implementing Continuous Deployment for cloud native applications) and MLOps (a set of best practices for businesses to run AI successfully) are novel examples of applying new trends as needed.

To conclude, these tips help you put up a solution architecture based on modern practices but essentially it depends on the system under consideration and associated context. 

Top 10 Tips for a Modern Software Architect
Top 10 Tips for a Modern Software Architect
Ankur Kumar
Ankur Kumar

Ankur is a technology enthusiast with 20+ years of experience in IT landscape. He started his journey as a programmer in 1998. Ankur not only enjoys the technology but also loves engaging as a leader with the team.
Ankur founded Vedcraft platform to share technology learning and experience in the area of software architecture and design.

Related Articles

Leave a Comment