Module 14 – New and Emerging Concepts in Software Systems

Neil Ernst

2025-08-28

New and Emerging Concepts in Software Architecture

I wanted to spend our last lecture talking about some new and emerging concepts in how we build and understand software.

Reading code happens more than writing code.
- “Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.” - Martin, Clean Code
- Singer et al. recorded developers spending < 25% of their time making source edits. –>

Emerging Topics

I’ve taken this section from following Twitter and topics we have published at the academic conference on software architecture, ICSA.

Microservices

Can someone give me their definition of microservices?

Lewis and Fowler have a nice introduction to this concept. The following images come from that article.

The basic idea is that organizational structure is recapitulated in the software structures. This means there are unwanted dependencies, particularly at release time, between our software. Instead, we could organize around cross-functional business ‘service’ teams, respecting the 2-pizza rule.

Conway-micro

If you have these business service teams, you get to focus on each team owning its own service (micro), and not have big integration worries.

monoliths

We need to be careful. Making an organization into one organized around microservices is a pretty radical change, particularly for large companies or government entities.

There’s a danger that we try to move to microservices and end up stuck between what we had before - the monolithic entity that released in step - and microservices. Simon Brown has called this the “distributed big ball of mud”. Now we get the worst of both worlds: duplication and organizational complexity, with all the tight coupling of the monolith.

Research is looking at - how one can identify potential microservices; - how to migrate to microservice architectures; - how to draw component boundaries; and - how to manage and organize microservices.

Lambda/Serverless

Related to the microservice paradigm is that of “serverless computing”. Can someone define this for us?

Broadly, this is a Cloud operations shift. Some of you may be familiar with the terms PAAS, IAAS, SAAS?

The Cloud is broadly the following ideas (“other people’s servers”):

IAAS - Infrastructure as Service. The provider makes the OS and hardware and network capability available, but you are responsible for installing libraries and software. Amazon AMIs are examples of IAAS.
PAAS - Platform as Service. The OS, common libraries, server software, etc are provided for you. Heroku is an example of PAAS.
SAAS - Software as a Service. An arm’s length entity is responsible for the entire stack of an application. Your users sign in and run tools on their servers. Salesforce, Shopify are examples of SAAS.

Serverless computing takes the idea of PAAS and breaks it down. One acronym is “FAAS” or Function as Service.

Where PAAS might still require us to essentially write all the logic for our application, in FAAS/Serverless (best characterized by AWS Lambda or Google Cloud Functions) we take common ‘functions’ of our application and let Amazon or other cloud providers take responsibility for providing it (at scale).

FAAS means:

Stateless
Event-driven
Ephemeral
Managed by 3rd party (eg. Amazon)
More logic in client (e.g. storing state)
Limited lifetime

Challenges:

vendor lockin
multitenancy
managing state
testing
latency/transition

Another approach mentioned in the Fowler article is the idea of “backend as service”. Here, common functionality not core to the application – think login and authentication – is offloaded to a 3rd party.

width:700px

Architecturally, this means that even the complex apps you have been looking at in this course are made more difficult to understand. We must understand the SLAs of the specific cloud platform (e.g. cold start times) in addition to our own internal architecture. We gain auto-scaling and management but reasoning about the QAS might be considerably harder.

Serverless example

Machine learning and architecture

An area I’m doing active research in is the integration of probabilistic programs into conventional software architectures.

A probabilistic program, at its most basic, is the idea that instead of taking on a set value (i=2), the variables are random variables with value derived from a probability distribution (e.g. the Normal).

We have a good understanding of how to build and architect systems that are conventional imperative, OO programs (e.g. Java EE, Spring, Rails). But increasingly our software will be encoding complex decision procedures that are difficult to express in these languages. For example, we could build a rule-based system for firing actions in response to monitoring. This was what expert systems were in the 80s and 90s. But they didn’t scale well and missed a lot of complexity.

Nowadays, we make decisions probabilistically: the Uber crash recently is based on a decision procedure that has to weigh evidence from sensors to take some action (apply brakes, steer right, etc). The evidence is all probabilistic: this is a pedestrian heading right with probability 80%. It is far from clear the best way to structure programs to accommodate these new types of data (or how to test them).

SE 4 ML

Furthermore, the machine learning programs behind these decisions are often incredibly complex. A paper from Google calls this the “high interest credit card of technical debt”. Managing a suite of Tensorflow models, for example, quickly becomes challenging. For one thing, we need to document the hyper-parameters we are using. In a case like the Uber crash, regulators will want to know how the algorithm was trained.

Mandatory XKCD cartoon:

width:500px