In recent years, I've worked across many varying architectures on AWS in a consulting capacity.

These architectures and the applications which ran on them were built to do different things. All of them come with fundamental trade-offs towards what they were building for. Some organisations might want to be cost-effective, whereas others desire to be highly performant and accept a higher cost.

What you are building for is your "X" and architecting for that will inevitably come with trade-offs. Without knowing your "X", your architecture won't satisfy your requirements. Allow me to take you through the understanding of building good architecture for your "X".

What I'd like you to keep in mind when continuing to read this blog is that there is unfortunately no hard or fast set of rules you can apply to your architectural design: everything you decide has a cost in some regard and it's not always monetary.

This blog is inspired by a series of talks I've recently given at AWS Events in the UK. In these talks, I revisited concepts that, while familiar to some, are crucial for all engineers—whether they're just starting out, mid-career, or highly experienced. My aim is to encourage learning, provide a grounding in fundamentals, and offer deeper insights into the field.

Use this post to encourage discussion with this blog - Share it with your fellow engineers & be ready to have productive conversations around your understanding of architecture and even how your current architecture is built.

Architecture, who?

When I'm talking about Architecture, I mean your system's underpinning structure. Architecture covers a wide range of aspects, from how your services are hosted, where your data is stored, how you access data, who has access and your network topology.

Think of a skyscraper in your nearest city, without a good foundation, you can't build anything. Without an initial understanding of what you require upon that foundation, you'll struggle to build the next Burj Khalifa with severe issues and potential risks.

Why you should care

Your architecture governs quite a lot without you realising, from simple things like your developer experience to more important aspects such as testability and security.

Whether you are starting from scratch, looking to implement new features or re-evaluating current architecture to better fit your "X", these three elements should cement (excuse the pun) the reason your architecture is important to you.

• Defines the 'work' ahead - Whether building from scratch or refactoring, any changes to architecture require work to achieve them.

• Defines your domain boundaries - Not everyone cares about or needs access to every part of your system. Equally, neither does any one particular part of your system.

• Defines the balance of your "X" - Whether that be performance, cost, success (fault tolerance) or other.

Architecture 🤝 Software

There is an interconnected nature between architecture and software. Think about a hypothetical application for a moment: the application has been programmed to read and write data from a MySQL database.

The decision as to how that data will be stored has largely been determined already, that is, it needs to be MySQL schema compliant or any changes will have a cost associated with changing it. Refactoring the software to work with another type of database and 'moving' the data to its new location.

In a parallel universe, that piece of software has yet to be written and the questions are just being asked of how and where it stores data, evaluating the use cases ahead of time.

How the data is stored, its access patterns and availability requirements may warrant a NoSQL database as the 'better' choice.

Other examples of this interconnected nature include:

• Highly available application - Data must be ephemeral in case of failure. Web 2.0 websites relied on local server storage a lot of the time and therefore weren't compatible with horizontal scaling: where the same data wasn't present on the server of other servers behind the loadbalancer.

• Fault-tolerant application - Any individual part of the architecture could fail and the system still functions or "fails gracefully" as retry functionality, dead letter queues or other failure scenarios are handled by the architecture and software.

• Whether actions are synchronous or asynchronous - You wouldn't want an API call (service A) waiting on an application that only runs on a schedule (service B). In this example, you might want to architect service B to not run on a schedule and in fact, be available 24/7. Or better yet, question why service A is synchronous - does it need to be?

I won't touch into too much detail here, but the architecture & the software that resides upon it, both influence each other when deciding many aspects, such as Server vs. Serverless or Monolith vs Micro-service. Your "X" plays a part in this decision.

I've written a blog on exactly those trade-offs recently, take a read (later of course) of Monoliths in the 21st Century: Nostalgia or Necessity.

Diagrams

Architecture is often visualised to make it easier to understand and follow the flow of actions through the system as a whole. You'll have likely seen a diagram like the one below before [created on Diagrams.net]:

A lot could be desired from the diagram I've created for a hypothetical e-commerce website, however, the quality of the diagram and what it must include is like linting - everyone has an opinion and nothing will ever satisfy everyone.

What matters is that your architecture, or architectural diagram is understandable for yourself, your team and the people around you. Change it if not!

Architectural Influences

When looking to build your architecture, you must first understand the landscape you find yourself in.

There are elements you control, others you can influence and some you must simply abide by.

Understand your landscape

You might be working within a heavily regulated industry, where considerations such as deanonymisation of data is a legal requirement, or encryption can only be completed by a hardware security module and not by software-defined methods because the utmost security is required. This is the regulatory impact.

Your organisation may wish to impose mandatory requirements and restrictions, for instance, in this blog post I've referenced Amazon Web Services, your organisation may make it mandatory to use Microsoft Azure as the cloud solution of choice. The difference mightn't same great but there are pros and cons to consider on all sides. For instance, in a hypothetical situation, AWS offers more 'free' usage of managed services such as Lambda functions vs. Azure where Azure Functions offer no free invocations (this difference immediately affects your financial cost). This is the business decision impact.

Knowledge, previous experience and skills of yourself, your team and your organisation as a whole will also need to be understood. If you are designing or extending existing architecture, you're also restricted slightly by the existing infrastructure and applications if you can't re-design or refactor OR it mightn't be 'owned' by you and therefore can't be influenced. This is the restriction impact.

What's your X?

With your landscape understanding, you now have an empty canvas, where the borders have been defined and understood. Next is to understand your X, and what are you architecting towards.

Your 'Y' is the application you wish to make available and its infrastructure requirements - Which mightn't be defined yet.

The X comes in many shapes and sizes; but it is balanced between and not exclusive to any individual attribute: Cost, Performance and Success (the ability to handle failure).

You might find similarities between this pyramid of architecture with something else, the CAP theorem. An advantage for any particular side is a disadvantage for one or two of the others.

How you architect your system will continuously bring forward the questioning and reasoning against your X.

For example, a fully serverless application with relatively stable traffic may be the cheapest cost to run monthly, but due to the knowledge and skills required may cost more to develop vs. a conventional server (serverful) design.

In conjuction you don't need to be fully embedded in any particular 'camp', ie micro-service vs. monolithic, serverless vs. serverful. You can and should use each tool appropriately for how it best serves you and fits your X. Use the right tool for the job.

Credit: Yan Cui on LinkedIn.

The Well-Architected Framework

It'd be remiss of me to not call out Amazon Web Services' very own framework for creating robust and stable architectures for systems and the decisions you need to weigh up.

To not repeat what is already available, please visit the well-architected framework website.

Principles of Great Architecture

The best thing at the time

As has been mentioned, your architecture can and will change depending on various factors not limited to what skills or knowledge you hold at the moment, the imposed SLAs and current requirements on your system.

What you build today may be perfectly suitable for now but the future has a vote and may warrant a change. That doesn't mean you've violated this principle if done correctly. If you've considered all factors possible, you've taken a step forward with the information you have at hand. The reflection principle will offer more information and offer insight to improve.

Don't get stuck in analysis paralysis, real usage will provide enough insight to confirm suspicions.

• What skills and knowledge do you have right now?

• Do you know your real service level agreements?

• What is your backup policy? Do you need one?

• Are you repeating yourself?

Explainable and justifiable

"Brain before build" - Designing your system before writing any code is strongly advised!

Having resources such as documentation or diagrams for the design of your architecture and all associated reasonings for the choices you've made, will allow you to collaborate with others, validate assumptions and ensure you are architecting towards your X.

Don't underestimate the wildcard questions when designing architecture, which can be overlooked without thought-provoking questions.

• Are you re-inventing something that already exists? It could be that a SaaS product already does as you require.

• Is it worth refactoring OR build new?

• What could your future use cases be? How are you ensuring you aren't 'trapping' yourself?

Causes reflection

Great architecture design, the aspect of designing and the final product will hopefully cause reflection on existing system processes. You may identify inefficiencies or areas for real improvement in some way because you understand your architectural influences and landscape.

Reflection happens at all stages of the design.

• Is what we're building achieving the original requirements?

  • Are the requirements fixing the problem or masking it?

• Is it maintainable?

• Is it testable?

• Are you using the correct thing at the correct time?

What's to come?

With everything we've discussed above, it's very likely that in the future we could see AI tooling which could calculate an approximate cost both monetarily and engineering timewise. Tooling such as this could heavily influence decisions of which architecture to choose for your "X".

Something else to consider is the growth of Software-as-a-Service products which will complete a wide range of requirements from applications and architecture and it may become more beneficial to purchase "off the shelf" than to build your own. It's also important when considering SaaS products that it's someone else's problem, you are simply gaining value.

Still confused, where should you start?

As mentioned earlier, it's very difficult to understand how your "X" will define your architecture without having a full context of your situation and the problem you are trying to solve.

Some people reside strongly in opposing thought camps; when starting with your architecture, some believe in going fully Serverless and therefore more likely "micro-service" architecture.

Whereas others believe it's quicker to produce a monolith and work backwards.

In my personal opinion, I don't care for either - I use what I feel fits best, with the available knowledge, tools at hand and my "X". I may be inclined to build a monolith if my "X" is speed to market (an "X" I've not spoken of so far) or be inclined to build a hybrid server-serverless architecture if the system requires it.

Whichever you feel comfortable with right now, start with that. You'll soon reflect and change for new requirements going forward and have a better understanding when you revisit your design. With more information, you'll be able to choose the best thing at that time once more.

Despite the differences, there's one thing in common, it's usually the responsibility of engineers & DevOps to get back to business as usual as quickly as possible.

In my time as a Consultant Engineer, I've experienced various ways in which teams are built, route-to-lives operate and how incidents are found, reported and dealt with. In all of these various teams, I've had to deal with incidents, ie. something has unfortunately gone offline or users have suffered a degradation of the service they expect.

Incidents happen - Don't think for a moment that 'firefighting' doesn't happen in the likes of Google and Amazon. Heck, Amazon created the Well-Architected Framework after a disaster!

I want to offer up my thought process for dealing with incidents, from the perspective of the engineers and DevOps. As much as I'd not wish for an incident to happen to you, I know at some point it unfortunately will.

I believe this playbook will bring order to the chaos. Don't take it gospelly if you don't wish to, build upon it so it suits your needs, but whatever you do, don't create an unwieldy monster. Keep it sharp, consistent and useful.

Elect an owner

As often in the chaos, various people are 'pulled in' to offer their expertise and insight. They could be members from within your team or wider depending on the incident.

Ultimately it doesn't matter who is there from the beginning, but in my experience the moment an incident is raised, it should be owned. Some incident management software requires owners to be specified, for the sake of the paperwork, this owner doesn't need to be an engineer.

When I'm saying an owner, I'm meaning the engineer leading the charge to handle the incident. Electing an owner doesn't have to be the individual with the most context in any particular area, but someone able to adapt their calendar and other obligations to resolve the most pressing matter.

Too many cooks spoil the broth

I love the quote 'Too many cooks spoil the broth', it sums up nicely that everyone is operating on an agenda of their own based on their experiences and knowledge, but ultimately that could be to the detriment of the goal. Gordon Ramsey elects a head chef to make the calls and final decisions for a reason.

Electing an owner isn't about giving someone an ego boost, it's about having a spearhead individual who can be at the receiving end of the hypothetical funnel of all of the context surrounding the incident.

Gather the facts

As the owner, you need to gather the facts relating to the incident, paint a picture of the system in your mind and understand the effects that have happened. With this knowledge, you'll be primed to assess the impact and mitigate the problem.

A take on the typical who, what, where and when won't leave much to be desired when approaching the fact collection methodically.

• What has or hasn't happened that shouldn't or should have? - Journey through the system

• What can you prove quickly? Using metrics, statuses and logs.

• What are the SLAs?

• What is the risk? To the business, to regulatory requirements or to security.

• When could the action happen again?

• When did it start? What was the condition of the system before this?

• Who is affected?

• ...

Assess the impact

An issue may arise anywhere in a system, an incident could be raised for an effect caused as a byproduct. With the facts at hand, you are probably already narrowing your scope of investigation - but hold fire. If you narrow your view too much, you may lose sight of the root cause.

You must understand the system's chain of events and all available 'check points' - places where you can validate conditions and expected behaviour; to best equip yourself to identify the root cause.

In a micro-service architecture, one such checkpoint could be your service logs between every micro-service or a queue with messages waiting to process etc.

Here is an example to illustrate what I mean a little better.

In the example, we can see that a bug in an 'upstream' service was the cause but the effect has been felt in a downstream process.

Let's use the example and assess the incident with a narrow scope:

• What journey was affected? The image compression journey.

• How many users were affected? Just the one, confirmed by monitoring and logs.

• How was the business affected and any known risks? Low risk as there is negligible cost implications.

• What SLA was affected? No SLA is expected in this process.

Given the example provided you may be assuming the scheduled compression job is to blame.

What if I told you that the file was originally an image but in transfer during upload bytes of data were lost resulting in file corruption? You can begin to understand why a narrow scope shouldn't be your immediate reaction and the effect is not always the cause.

Retracing the steps of the system to the point of issue is a much better approach, checking all information available to you to check the status of the system is operating as it 'should'.

Using the example, if we were to retrace the steps, we may not have concluded yet what the cause of the issue was, but using the 'check points' available to you, you will have an idea whether the system operated as intended or didn't and up to what part of the journey.

Issues come from a wide range of causes, so unfortunately there isn't a concise enough decision tree to find the cause for you.
However, you can ask the following questions at every step you retrace to further shrink the scope.

With the facts you've gathered earlier, ask yourself the following:

• What journey is affected? Preliminary scope setting - Don't get too fixated though.

• What high-level 'state' was the system in before and after the issues started? ie. Available vs. Offline

• What metrics are abnormal? What (if any) alerts were fired? ie. Error rate increased.

• Under what conditions would lead to the high-level state change and metrics becoming abnormal?

As the owner, you might want to lean on other teams with context to areas outside of your knowledge or understanding, to best grasp the answers to such questions.

Communication is key and even better when done often!

Also, have you checked

• A recent release - Check your CI / CD pipelines for recent activity, the release calendar for dependency releases etc.

• Configuration properties - Check recent commits for config in code changes. Does your environment config match?

• Connectivity - DNS, Network routing, ACLs

• Availability - A system was unavailable at the time, and dependent services had no failure tolerance

Once you've identified the issue, even at a high level, you can begin to mitigate it.

Mitigate the problem

There unfortunately isn't a magic wand here, your system is unique to you (and your company) and therefore only you (and them together) will be able to fully comprehend the problem to resolve it.

However, in my experience of dealing with incidents, these guidelines have worked well in the past to keep everyone informed, work the problem and resolve the issue swiftly.

• Who do you need to notify (stakeholders, users)?

• Is the problem getting worse? ie. Continually happening or one-off.

  • Can you stop the system safely temporarily to reduce the impact? 'Stop the bleed'

  • Can you disable a subset of functionality so that the whole system isn't compromised? Graceful degredation.

• Is a fix required to resume normal service behaviour?

  • Suggestion: Fix forward if it can be repaired in hours, and roll back if in days.

• Can a privileged user manually correct behaviour? (Breakcase scenario)

If you've correctly assessed the situation and can begin processing the requirements to resolve the issue, you'll be out of the woods in no time.

Retrospective view

Escape the forest so that you can see the wood from the trees.

Once you've gotten past the issue, and mitigations have been completed to return the system to working order and correct any missteps, it is important to realise it isn't over. Luckily the chaos and pressure are behind you.

Just as retrospectives hold value at the end of agile sprints, I believe they hold value when looking back at incidents. They offer a no-blame, honest and open forum to highlight the multiple areas of improvement to the system, testing and release structure.

Anybody can organise a retrospective for incidents - but I believe it is best for the elected owner mentioned prior, to be available and in attendance. That valuable full-picture context will pay its dues here. Schedule this as soon as reasonably possible.

• Monitoring and alerting - Was it comprehensive enough for this incident? What about other teams and systems?

• Testing - Are there any missing scenarios (automated) that could have identified this?

• Release process - Could it be better controlled or simplified? Could you implement A/B releases & testing?

• Application fault tolerance - Retries, DLQ, graceful degradation

• Architecture or application self-healing - Could your system automatically recover?

• Synchronous vs. Asynchronous - Is something synchronous that would perform better asynchronously or vice-versa?

Whatever you identify, you should categorise with a strong bias towards the highest priority. By that, I mean prioritising long-term improvements higher than future feature work. If your system can fail, for any known situation, you risk monetary, reputation and time losses.

Fail with grace

Everything fails all the time - Werner Vogels

The philosophy of 'graceful degradation', which I aptly rephrase to 'fail with grace', is to build architecturally sound applications with built in redundancy and graceful degradation of service that minimises the likelihood of complete system failure.

In essence, maintaining the minimum functionality that can be supported in a system in the event of a failure while also ensuring recovery from such.

Even in your existing system, you can begin building applications and architecture to fail with grace today - it doesn't have to have been a decision at the inception of the system.

TL;DR From incident inception to resolution

• Elect an owner quickly - Too many cooks spoil the broth. Someone with a technical understanding to orchestrate the actions and remediations.

• Gather the facts, methodically - What hasn't happened that should? What can we prove quickly (metrics or errors)? What are the SLAs?

• Assess the impact - Which journeys on the system are affected? How many users? What is the risk? What teams need engaging for a 'context champion'?

• Mitigate the problem - Who do you need to escalate or notify (users)? How can you stop the 'bleed' right now? Is a fix required to get back to normal service behaviour?

• Retro & build for 'fail with grace' - Your highest priority should be re-assessing the problem, how could you improve resiliency? Build systems to 'fail with grace'.

Read further

10 Lessons from 10 Years of Amazon Web Services - Werner Vogels

Google SRE - Incident Response

Principles of Chaos Engineering

Allow me to cover a few of the headline points and express my opinion, in words, as to why I feel we are looking at the original question slightly incorrectly.

What is a monolith?

Within the tech industry, there are many acronyms and terms banded around with the assumption that the receiving audience knows what it means. Monolith is one such term where everyone 'kind of' knows what it means but it can look and feel slightly different to everyone.

Previously, when everyone practised waterfall, monolithic applications were often the result of the engineering team's efforts. Now, they aren't too much different. Monoliths often have a single codebase, where all functionality, dependencies and modules are stored. Additionally, the modules are interdependent and therefore can't be deployed independently.

So thinking back to that time, or if you are like me and were still in nappies, think back to the tales your parents told you of the software in that era.

The software of that time was revolutionary when spreadsheet software was pioneering the way everyone did, well, everything. Each year to gain the newest version, you'd have to purchase that version outright and install it whole. This was the 'traditional' monolith - everything that was required came in one package.

Fast forward to the 21st century and the world has changed, produced some fantastic movies in the process (Fast & Furious Tokyo Drift, bby!) and morphed the definition of a monolith slightly. We no longer build everything to be a 'desktop' application, we build for the web first (exceptions apply). This means that our users only need a browser to be able to use our product or service. As such, the definition of a monolith is now a designation of the applications and services which are the sum total or a large part of a wider system, for that web product or service.

For me, I would classify a monolith as any application which has more than a single responsibility, where responsibility is the smallest unit of a task. What do I mean by the term 'smallest unit of a task'? Take for example an API. For each API endpoint, that does something slightly different, I would class that as a task. It is the smallest unit of value available (note: not the same as a unit test). Monolithic API applications have, and will always exist. However, they also make for great candidates for micro-services which I'll touch on shortly.

Every 'monolith' isn't a monolith

Now that we are working with a common understanding of the historical thought of what a monolith is. Over my years in the industry, what people class as a monolith is everything from 0 to it being a micro-service. I disagree that everything up-to full-fledged micro-service applications is monoliths. There is a middle ground.

Think of Monolith <-> Micro-service as a linear scale of application depth and complexity. You can say that additional names or stages are missing from that linear scale. However, naming anything on a scale would require it to have defined conditions as to when it is 'something' - not something I want to do right now. For the sake of this blog, let's imagine that the linear scale looks like this (no definition supplied - your warranty may vary):

Monolith <-> Macro-service <-> Micro-service

What are the differences?

Monoliths differ greatly compared to macro or microservices. Monoliths are typically deployed as a single unit, whereas microservices are independently deployed and there could be hundreds of units.

When it comes to scalability, you must scale the entire monolithic application to meet your needs, even if only a small subset of functionality is receiving high demand. As you've probably guessed, this is wasteful of resources. Microservices in contrast are already, loosely coupled and designed to be independently scalable. Allowing for much quicker responsive scaling.

As mentioned prior, it is often the case that monolithic applications are held in a single codebase. A microservice approach would house each part of the functionality in a separate codebase.

What place do they have in the 21st Century?

Defining where a monolith truly belongs would not be the right thing to do. Your system, the problem you are trying to solve and the way you work are all factors in the equation and will always be (slightly) different to everyone else. Therefore there is no hard and fast rule of 'Monoliths should only be created for X problem'.

However, some problem cases lean more towards building an application of a monolithic nature than a micro-service nature. You may want to ask yourself the following, "For the problem I am trying to solve...":

• What are the various different stages or tasks it must do?

• What are the SLAs on the completion of those tasks?

• How resilient to failure should it be?

• Could any of its tasks be done in parallel?

• Are the tasks event-driven in nature or simply timed / batch events?

• What is the team size, skills and knowledge?

These high-level questions are not meant to determine whether the result should be monolithic or micro-service, but they do indicate which direction to lean. If you lean toward the micro-service side but your application doesn't fit the definition of a micro-service, it would be classified as a macro-service. It's a step in the right direction!

I have a monolith, what can I do?

You may already have a monolith(s) in your system. If it works perfectly fine, tests pass and it achieves the value you want it to do - that is perfectly fine! (For now) You should not be in a hurry to move to the latest technological trends, you need to evaluate every trend for it's pros vs. cons and consider the cost and effort required in order to achieve those.

You should reflect on your monolith and ask yourself these questions:

• Are you able to maintain your application easily? (Adding new features, fixing bugs)

• Does your application scale easily?

• Are you able to quickly deliver new value to your customers?

If any of your answers is no, it might be time to consider giving the application some attention. The journey a monolith must take to become a micro-service is difficult to define, your problem and obstacles will be different to anyone else.

You could consider the following when determining the journey ahead:

• Splitting the monolith into a modulated monolith

• Look to reduce the scope of what the monolith is to achieve

• Consequently, make smaller applications/services for the scope you've moved out of the monolith

• Re-build the application from the ground up in a micro-service approach

I only use micro-services, I don't even need a monolith

That statement may well be the case. The problem being solved can be done so purely by micro-services alone. It is still important, however, to understand when and where micro-services meet their limits.

Micro-services are fantastic but do come with their cons. It is always important to continually re-evaluate your system, how it is built and whether it continues to be fit for purpose for the value trying to be achieved. As you may have read recently, Amazon Prime Video recently re-evaluated its services and infrastructure and recognised that there were both performance and cost improvements to be made, despite using micro-services and serverless infrastructure. You can read more about that on the Prime Video Tech Blog.

Both a blessing and a curse as you build a distributed system is that you build a 'spiders' web of loosely coupled, inter-connected services that resolve a task at a time. Often these tasks are part of a chain of events, once one task has been completed, the task service picks it up where it was left off and continues. Like a conveyer belt. To facilitate this, infrastructure such as object storage or a database is used to safely 'facilitate' the next step, as micro-services are built ephemeral. All of this incurs network calls, storage read and writes and ultimately service capacity limitations - in the form of quotas, maximum throughput or latency.

Some of these issues may never impact your system, as the problem you are aiming to solve doesn't introduce them.

As the Prime Video team recognised, by consolidating already 'small' tasks together, they can reduce the effects highlighted above. They may have moved away from being 'fully' micro-services, but by no means have they created a monolith like we know from history. They've moved ever so slightly left on the scale, towards a macro-service to reduce the effect of the cons. of micro-service and serverless architecture. They have retained many pros that micro-services offered them originally, as they could remain 'serverless'.

A Monolith can be Serverless

One common misconception is that a monolithic application can only be deployed on infrastructure classified as 'serverful'. That is, you deploy it to a traditional server and must maintain that server or fleet and are unable to benefit from the many advantages Serverless infrastructure offers. This isn't the case.

There is no obstacle preventing a monolithic application from being containerized and hosted on a serverless container service like AWS ECS Fargate. If your application exceeds the size limit to benefit from on-demand Serverless infrastructure like AWS Lambda, you won't be able to take advantage of the additional benefits Lambda provides.

This is where micro-services shine, they are super small in their size as they've been built to complete a single unit or task of work. They are one of many applications, that make up a total of a service, system or product.

Ultimately you must consider the pros vs. cons of the infrastructure and what it can offer you, against what value you are trying to achieve.

Monoliths are here to stay

Hopefully, the points highlighted here, which were covered (some briefly) in the panel discussion on Wednesday, offer food for thought when you think about the architectural structure of both your application and infrastructure. Additional, you should be able to form an opinion, based on my opinion that there is a linear scale between monolith <-> micro-service and we should stop thinking of them being so clean-cut.

In my opinion, monoliths are a necessity or a necessary evil. Their shape may be much different from that of the early '90s applications but we've all still got work to do. They require modernisation as much as possible in the form of modularisation, separation of concerns and shrinking the overall scope and size. These efforts will move the applications more towards the centre line of the linear scale and begin to reduce the impact of the cons and even gain some pros usually enjoyed by micro-services.

I would always advocate considering micro-services and Serverless first and foremost.