Modernizing a Monolith Across Compute Options

Goal

The previous sections compared compute models one at a time. Real modernization rarely works that neatly. A monolith may contain web pages, APIs, background jobs, scheduled tasks, file processing, integrations, reports, and admin tools. Some parts can move quickly. Some should stay stable until the surrounding platform is ready.

This section applies the chapter's compute model to a practical modernization scenario.

The Short Version

Modernization is not one migration target. It is a sequence of workload decisions.

A weak answer sounds like:

Move the monolith to Kubernetes.

or:

Rewrite it all as Lambda functions.

A stronger answer sounds like:

Start by mapping the workload shapes inside the monolith. Keep compatibility-sensitive pieces stable, extract clear service boundaries into containers, use event-driven compute for bounded asynchronous work, and modernize the operating model around identity, networking, deployment, observability, and rollback.

The goal is not to use every compute service. The goal is to choose the simplest safe operating model for each component.

Break the Monolith into Workload Shapes

Use this decomposition:

Legacy monolith
  -> customer-facing web and API paths
  -> core transaction logic
  -> background workers
  -> scheduled jobs
  -> file and image processing
  -> reports and admin tools
  -> external integrations

Each part has different constraints. Customer-facing APIs need latency, scaling, deployment safety, and clear rollback. Core transaction logic needs data consistency and careful change control. Background workers need queue behavior, retry design, and observability. File processing may fit event-driven functions. Reports may depend on legacy runtimes or data access patterns.

A Practical Phased Architecture

A realistic AWS modernization might look like this:

This is a teaching example, not a universal blueprint. The actual answer depends on data ownership, team skill, latency, reliability targets, compliance, cost, and deployment maturity.

Strangler-Style Change

A useful modernization pattern is to place new capabilities around the monolith and gradually move responsibility out of it. This is sometimes called a strangler-style approach.

Customers
  -> API/front door
      -> existing monolith for stable core behavior
      -> container service for new account features
      -> queue and worker for asynchronous order tasks
      -> Lambda for bounded event processing

The value is controlled change. The team does not need to rewrite everything before learning how the AWS operating model works. It can improve deployment, monitoring, identity, and failure handling while extracting the highest-value or lowest-risk components first.

Shared Platform Concerns

Mixed compute does not mean chaotic compute. Before splitting pieces across EC2, containers, and Lambda, the team needs shared standards:

• Account and environment boundaries.

• VPC and subnet placement.

• IAM roles and least-privilege access.

• Secrets and configuration management.

• CI/CD pipelines and rollback.

• Logging, metrics, traces, and dashboards.

• Backup and restore plans.

• Event contracts and idempotency rules.

• Cost allocation and ownership tags.

• Incident response and runbooks.

These shared concerns make compute diversity manageable. Without them, every service choice becomes a separate operating island.

Example: Customer-Facing Monolith

A retailer has a monolith that handles storefront pages, checkout, order processing, image processing, nightly reports, and partner notifications. The business wants faster releases and better scaling, but cannot afford a long rewrite.

A practical recommendation might be:

1. Rehost the monolith core on EC2 with Auto Scaling, private networking, deployment automation, centralized logs, and backups.

2. Put a managed API or load-balanced entry layer in front of the application so traffic paths can be controlled over time.

3. Extract image processing into Lambda because the upload event is clear and the work is bounded.

4. Move partner notifications and fulfillment side effects behind queues so checkout is not blocked by every downstream system.

5. Build new APIs as containerized services on ECS/Fargate unless the organization already has a mature EKS platform.

6. Keep legacy reports on EC2 until the data model and reporting target are redesigned.

This answer is not flashy, but it is credible. It shows sequencing, risk control, and operating ownership.

Common Mistakes

• Trying to refactor everything before the landing zone, network, identity, and operations are ready.

• Moving all parts to one runtime because it simplifies the diagram.

• Splitting compute before splitting data ownership and event contracts.

• Treating Kubernetes adoption as the modernization outcome.

• Ignoring rollback while changing customer-facing paths.

If Someone Asks You

How would you modernize a monolith using AWS compute options?

A good answer is:

I would first map the workload shapes inside the monolith: web/API paths, transaction logic, workers, scheduled jobs, file processing, reports, and integrations. I might keep the compatibility-sensitive core on EC2 at first, extract new services into containers, use Lambda for clear event-driven tasks, and put asynchronous work behind queues. The recommendation should include identity, networking, deployment, observability, rollback, data ownership, and cost controls. Modernization is a phased operating-model change, not a single compute-service choice.

What You Should Remember

Modernization is a sequence of workload decisions, not one migration target.

Questions to Check Your Understanding

1. Which monolith components are often good early candidates for event-driven extraction?

2. Why might some components stay on EC2 during the first migration phase?

3. What shared platform concerns must be ready before splitting workloads?