Q&A

How to Choose the Right Architecture for the Right Job

• By David Ramel
• 09/12/2023

Spurred by cloud adoption, many monolithic IT systems have morphed into distributed solutions based on service-based architectures, but as with all such IT transformations, the backlash has begun and the pendulum is now inching back the other way.

Maybe.

Supporting the backlash theory, one of the most popular articles on Virtualization & Cloud Review recently was "Prime Video Sparks Serverless Debate by Switching to Monolith." Readers showed intense interest in the video service's change in direction, going from this:

to this:

That move certainly bucked a serverless adoption trend illustrated by Datadog:

So is there an architectural backlash underway in IT? Regardless, says one expert, organizations can now pick and choose the right approach depending upon circumstances.

"Although monolithic architectures are making a comeback, the best way to build distributed software solutions is through the use of service-based architectures," said Rockford Lhotka, a well-known figure in software development and sought-after speaker and event presenter. "These include microservices, dedicated n-tier services, and related architectural models widely used when building comprehensive solutions," continued the VP of strategy at Xpirit USA.

Lhotka will help IT pros tasked with making architectural decisions in an upcoming session titled "No Silver Bullet: Use the Right Architecture for the Right Job" at the big November Live! 360 conference in Orlando.

"In this session you will learn when to implement a system using microservices, and when to use dedicated services," Lhotka said. "You will also learn when to use sync vs. async communication between system components, and the importance of discipline around messaging protocols within your system and with external consumers."

Attendees are promised to learn:

• How microservices fits into the history of distributed computing
• When to use a well-architected monolith vs. services
• When to use n-tier services, microservices, and other architectures

We recently caught up with Lhotka to learn more about his upcoming session.

VirtualizationCloudReview: What inspired you to present a session on using the right architecture for the right job?
Lhotka: Having a solid architectural base is probably the most important factor for technical success in any enterprise application. Throughout my career there've always been those that hype the latest and greatest solution. These over-hyped solutions often cost organizations and people a great deal.

I've been fortunate in my career, in that I've had the opportunity to be involved in building a wide range of software over 30+ years, and have distilled down some core truths about how we successfully build software. There's not one answer, but neither are the choices unlimited.

We are at a point in time where there are known good solutions to the most common software requirements, and the task is to identify the combination of known-good-architectures that solve any specific set of requirements.

Many people tout microservices as the solution to all architectural problems. Could you explain the historical context of distributed computing and where microservices fit into that narrative?
Microservices is one architectural pattern that solves a specific set of problems. Like so many patterns over time, it has been hyped to the point that you'd think it solves all problems, when in fact it solves a small set of problems.

All architectural problems have consequences: good and bad. They make some things easier, and incur cost and complexity in other areas. This is also true of microservices.

In many ways, the microservice architecture is exactly what some of us were talking about way back when Service-Oriented Architecture (SOA) was being hyped. At that time most organizations didn't implement SOA in a "good way", and instead went down a dead-end road. Microservices has provided another chanced to do service-based software in a way that moves the industry forward.

The debate between monolithic vs. service-based architectures is ongoing. Can you provide a brief overview of the primary considerations developers should keep in mind when deciding between a well-architected monolith and various service-based architectures?
The key point of my talk is that we need to escape this binary A vs. B thinking. There is no "one architecture" to solve all problems. Each architecture has its benefits and costs, and it is up to us as software architects to evaluate our business and technical requirements and identify which software architectures will be necessary to best serve those requirements. For simpler apps it might be a single architecture, and for mid to large sized apps multiple architectures will be required to address different parts of the overall solution.

This is true for the "monolith" vs. microservice discussion as much as anything. I'm not sure I'd advocate for a true monolith (as in old-style mainframe or minicomputer software), but I do advocate for well-designed n-tier solutions, as they are well understood and (when done right) a very cost-effective solution to building software. Some business solutions can also benefit from microservices, often in combination with some n-tier elements.

Speaking of monoliths, a recent article in Virtualization & Cloud Review about Prime Video sparking a serverless debate by switching schemes and cutting costs proved to be quite popular on the site. Any ideas on why that would be so interesting to our readers?
At the end of the day, the business people who are asking us to create software to solve their problems are trying to be more efficient. Ideally we'll show them how to evaluate short-term development and long-term maintainability costs, and work together to devise software that addresses their problems in a balanced manner.

It isn't surprising to me that people are finding out that microservices are quite expensive to implement and maintain. Microservices solve a specific set of technical issues, and they do this in a way that always introduces complexity and cost. Application a microservices architecture to build software that doesn't have the specific set of technical issues solved by the architecture means organizations incur that cost and complexity without any of the benefits.

This is a natural backlash that has occurred against every hyped architecture I've observed over my career.

The whole "serverless" thing is also over-hyped, and yet has a kernel of very high value at its core. This is related to microservices, and might represent a long-term evolution of how we build backend software overall. The end result is likely to be that we build backend software to be event-based, much like we've been building smart-client software since the early 1990s.

If this happens, we're just at the start of the evolution. So I'm sure it'll become over-hyped and portrayed as the "one solution" to all problems. There'll be a backlash, and ultimately event-driven server-side (serverless) architecture will become yet another tool in a software architect's toolbox.

When considering n-tier services versus microservices, what are the primary differentiators? In what scenarios would one be more advantageous than the other?
From an architectural perspective the primary difference is where you place "trust boundaries."

In an n-tier architecture there's a level of trust between the client (UI), the services it calls on an app server, and the underlying database. These are all part of a single distributed application, and they are all built to work with each other. As a result, we can use efficient binary data transfer protocols, implement service endpoints to meet the exact needs of the application, and we can (technology permitting) share code and other assets across these tiers.

In a microservice architecture each microservice is an isolated app that must not trust any other parts of the overall software solution. Each microservice is created with a service endpoint that tries to accommodate any caller, today or in the future. And no code or other assets should ever be shared between microservices or their consumers (such as a client UI). If you can't arbitrarily deploy a new version of each one of your microservices without deploying anything else, then you haven't achieved the goals of microservice architecture -- they must be that isolated from each other.

As a result, n-layer/n-tier solutions are much cheaper to create, and use patterns and tools that have become very efficient over the past 27 years. Not only is this well understood by developers, but also by the IT and support people who deploy and run this type of solution.

Microservices are still a new enough idea that the tooling for developers and IT/operations/support folks are still being developed and standardized. Additionally, instead of creating a single software solution, microservices means you are creating a whole bunch of standalone services that will be stitched together to create the overall solution. As a result, the costs are higher for development, as well as long-term operation of the overall solution.

The benefit to microservices is that if parts of the overall solution need to change independently from other parts of the solution, this is possible. For example, if one service implements a tax policy that is known to change on a regular basis due to governmental policies across the country or globe, it should be much more efficient to continually update this one service as necessary, even if the overall software solution doesn't change so rapidly.

My overall preference is to look at building the more stable parts of an app using the lower-cost n-layer/n-tier architecture, and use microservices to implement the high-change parts of the overall solution.

You've mentioned the importance of sync vs. async communication between system components. Could you briefly summarize the factors that determine which method of communication to use?
One common point of fragility in any distributed software system is the communication between the distributed components. Point-to-point HTTP communication is easy to understand and implement, and yet is a source of fragility. Without additional tooling, it is up to each developer to ensure that every http call is wrapped with retry and short-circuiting logic to deal with the (likely) possibility that the remote service is offline. In recent years there've been technologies as part of Kubernetes and things like Istio and Dapr that help address this inherent fragility.

Another solution is to avoid synchronous point-to-point communication entirely, and use async queued messaging instead. In my view this is a superior solution, because the underlying technology avoids the fragility of synchronous communication, while also offering low-cost benefits around scaling, redundancy, and even geographic failover. The drawback to this approach is that most developers are trained to think in terms of synchronous communication, and it requires some training and mental flexibility to shift to this asynchronous model.

Note: Those wishing to attend the conference can save hundreds of dollars by registering early, according to the event's pricing page. "Save up to $400 if you register by September 22!" said the organizer of the event, which is presented by the parent company of Virtualization & Cloud Review.