Classic Versus Microservices Same replication engine, very different operating model
The hardest mistake in Oracle GoldenGate planning is treating the architecture choice as a cosmetic preference. It is not. Classic architecture organizes administration around a local runtime tree, Manager, parameter files, and GGSCI. Microservices Architecture reorganizes the same replication fundamentals around deployments, named services, browser and REST control, Admin Client, and a security-first boundary between operators and runtime components. The data still moves through Extract, trails, transport, and Replicat, but almost every operational habit around those stages changes.
How the described components fit into the GoldenGate operational model.
Intermediate to advanced Oracle GoldenGate practitioners.
Confident operation, configuration, and architectural migration planning.
The real choice boundary is the control surface around replication, not the replication primitives themselves
Classic architecture and Microservices Architecture both move committed changes with Extract, trail files, network transport, checkpoints, and Replicat. The difference is where operational state lives, how administrators authenticate, how network paths are defined, how services expose health, and how much of the platform is naturally automatable. That is why a team can keep the same source and target database logic yet still feel like it adopted a different product after moving to Microservices Architecture.
Classic architecture fits estates built around local shell access, direct file inspection, parameter-file discipline, and simpler host-local administration. It is familiar, terse, and effective when the environment is small enough that the GoldenGate home itself can be the center of administration.
Microservices Architecture fits estates that need stronger separation between software home and deployment state, browser and REST control, explicit service boundaries, reverse-proxy fronting, and security controls designed into the deployment itself rather than layered on later.
Many teams compare only GGSCI versus a web UI. The practical comparison is bigger: Manager versus Service Manager, data pump plus Collector versus Distribution and Receiver, host-local process groups versus named deployments, and flat runtime directories versus separated configuration and variable homes.
| Question | Classic architecture answer | Microservices Architecture answer | Why it matters operationally |
|---|---|---|---|
| What is the top-level administrative unit? | A local GoldenGate instance organized around its directory tree and process groups. | A named deployment managed under Service Manager. | Deployment thinking scales better when one software installation hosts multiple isolated replication runtimes. |
| How do operators connect? | Typically through GGSCI on the host where the GoldenGate runtime lives. | Through browser UI, REST, or Admin Client against deployment services. | Remote administration, automation, and delegated access are materially easier when the control plane is service-based. |
| How is transport modeled? | Data pump and Manager/Collector semantics dominate the remote trail hop. | Distribution paths and Receiver endpoints become explicit managed objects. | Path health, direction, and landing location become easier to reason about as first-class topology objects. |
| How is security introduced? | Mostly by configuring process credentials, trail or TCP encryption, and host controls. | At deployment creation time, with secure or non-secure choices and service authentication surfaces. | Security posture shifts earlier in the lifecycle and is harder to treat as an afterthought. |
| How is observability exposed? | GGSCI, reports, lag checks, and host-level inspection remain central. | Service pages, REST resources, Admin Client, and Performance Metrics Service. | Operational evidence is less dependent on shell access and report scraping. |
This is an architecture comparison, not a feature-by-feature catalog of every Extract or Replicat mode. The safest way to read the rest of the article is: the replication core remains recognizable, but the administrative perimeter changes enough to alter deployment design, troubleshooting habits, and upgrade planning.
Classic centers on host-local process groups; Microservices centers on deployments and named services
Classic architecture encourages a local operator mindset. You create the runtime subdirectories, start Manager, edit parameter files, create Extract and Replicat groups, inspect reports, and solve most issues by being on the host. Microservices Architecture keeps the same replication purpose but lifts administration into services: Service Manager governs deployments, the Administration Service manages runtime objects, and Admin Client gives a command shell that targets those services rather than a flat runtime tree.
The default muscle memory is GGSCI plus parameter files under directories such as dirprm, dirdat, dirrpt, dirchk, and the credential store and wallet directories. Manager is an actual process you start and tune, not just a conceptual coordinator.
The default mental model is a deployment with its own configuration and variable homes. Service Manager starts and supervises the deployment services. Operators then work through the Administration, Distribution, Receiver, and Performance Metrics services by browser, REST, or Admin Client.
Classic bootstrap feels close to the filesystem for a reason
In classic architecture, early administration establishes the runtime tree and Manager behavior directly inside the GoldenGate environment. That makes the platform transparent, but it also means the installation and the runtime are tightly associated in day-to-day operations.
GGSCI> CREATE SUBDIRS GGSCI> EDIT PARAMS MGR PORT 7812 DYNAMICPORTLIST 7813-7820 GGSCI> START MGR GGSCI> ADD EXTRACT ext_core, INTEGRATED TRANLOG, BEGIN NOW GGSCI> ADD EXTTRAIL ./dirdat/ea, EXTRACT ext_core GGSCI> ADD REPLICAT rep_core, INTEGRATED, EXTTRAIL ./dirdat/ra GGSCI> INFO ALL
The point is not the exact parameter set. The point is that classic makes the GoldenGate home and the process-group catalog feel like the natural administrative center. For small or inherited estates, that simplicity can still be useful.
Microservices bootstrap starts by establishing a deployment boundary
Microservices Architecture inserts a stronger boundary between the software installation and the runtime that will actually host Extract, Replicat, paths, credentials, and metrics. That is why environment variables such as OGG_HOME, OGG_ETC_HOME, and OGG_VAR_HOME matter operationally: they describe a deployment, not just a shell session.
export OGG_HOME=/opt/ogg export OGG_ETC_HOME=/srv/ogg/deployments/edge_sync/etc export OGG_VAR_HOME=/srv/ogg/deployments/edge_sync/var $OGG_HOME/bin/adminclient CONNECT <service-manager-uri> DEPLOYMENT edge_sync AS oggops PASSWORD <secret> INFO ALL INFO DISTPATH * INFO ER *
That shift has consequences. If your operating model depends on service endpoints, roles, and API-driven automation, Microservices Architecture aligns naturally. If your estate is still built around local shell discipline and direct file handling, classic may remain the lower-friction operational fit until a broader redesign is justified.
A surprising amount of migration pain comes from treating Microservices Architecture as classic with prettier screens. It is more accurate to think of it as a service-managed control plane wrapped around familiar replication engines.
The replication path is still recognizable, but transport becomes far more explicit in Microservices Architecture
At the data level, both architectures still capture committed changes, persist them in trails, move them across the network, and apply them on the target. What changes is how the transport hop is packaged and observed. In classic architecture, data pump plus Manager and Collector are the traditional remote-trail story. In Microservices Architecture, Distribution Service and Receiver Service make that transport boundary a managed path with clearer ownership and endpoint semantics.
Classic bundles the remote movement story into the familiar Extract plus optional pump model.
Microservices breaks transport into explicit services that expose clearer path intent.
Why transport packaging changes design quality
Classic transport is proven, but it often hides path intent inside a mix of Extract parameters, remote-host statements, Manager ports, and target-side expectations. Microservices Architecture turns that into a managed path model. This makes route ownership, health, and landing configuration easier to discuss during design reviews and easier to inspect during incidents.
| Transport concern | Classic architecture | Microservices Architecture | Operational consequence |
|---|---|---|---|
| Path object | Implicit in pump parameters and Manager/Collector handling. | Explicit distribution path managed through services. | MA makes route ownership visible and easier to govern. |
| Target landing | Collector behavior and remote-trail conventions. | Receiver Service is the explicit target landing boundary. | MA separates sending and landing more cleanly, aiding diagnostics. |
| Direction choices | Usually thought of in source-driven pump terms. | Source-initiated and target-initiated distribution patterns are both first-class. | Firewall and network policy planning becomes easier to align with enterprise rules. |
| Mixed architecture links | Possible, but direct classic-to-MA connectivity has caveats. | Often requires a coexistence design rather than a naive plug-in replacement. | The transport boundary is where migration shortcuts often fail first. |
Distribution Service is not just a renamed pump, and Receiver Service is not just a renamed Collector. The services expose topology and health differently, participate in secure deployment design differently, and matter much more once the estate includes multiple deployments, proxies, or automation pipelines.
Security design arrives earlier in Microservices Architecture and stays closer to the control plane
Classic architecture can absolutely be secured: credential stores, trail encryption, message encryption, and host-level controls have been part of serious GoldenGate practice for years. The difference is lifecycle placement. In classic, security often feels like a set of runtime protections applied around a local estate. In Microservices Architecture, secure versus non-secure deployment, certificate handling, authenticated service access, and reverse-proxy planning shape the deployment boundary itself.
Credential store and wallet handling remain essential, but the architecture still assumes a host-local administration style. Shell access and file stewardship stay prominent in the security story.
Secure deployments use certificates and service-facing authentication patterns from the beginning. That changes how you think about operator access, remote administration, and network boundaries.
If your enterprise requires service-tier authentication, proxy fronting, or delegated operations without broad host access, Microservices Architecture aligns naturally with that requirement.
| Security area | Classic architecture posture | Microservices Architecture posture | Why it changes planning |
|---|---|---|---|
| Authentication surface | Mostly local administration plus process credentials. | Service endpoints, authenticated browser/CLI access, and REST control. | Identity and authorization can be shaped around operational roles instead of shell access alone. |
| Deployment security | Emerges from how you configure runtime encryption and host controls. | Secure versus non-secure deployment is a core OGGCA setup choice. | Late-stage security redesign is disruptive in MA because it reaches into deployment shape. |
| Proxy integration | Not the normal architecture center. | Reverse proxies (NGINX, Apache) can naturally front the service layer. | Enterprises that standardize ingress and certificate handling usually prefer the MA model. |
| Classic interoperability | Classic can coexist with other classic easily. | Direct links into secure MA deployments are not a drop-in assumption. | Migration planning must respect security mode and topology, not only version compatibility. |
Deciding whether distribution is source-initiated or target-initiated is easier once ingress, egress, and certificate ownership are settled.
Database user secrets, master keys, and service certificates solve different problems and should not be treated as one interchangeable security bucket.
Mixed classic and MA estates are common during migration, but they are where path and security shortcuts fail first.
Installation, scaling, and upgrade work feel different because the runtime packaging is different
Classic architecture is straightforward partly because the installation and the runtime live close together. You install GoldenGate, create the subdirectories, start Manager, and define process groups in that environment. Microservices Architecture deliberately separates the software home from the deployment runtime, which improves lifecycle flexibility but also adds more structure to configuration, startup, and governance.
Install the software, initialize the directories, configure Manager, then add Extract and Replicat groups. The runtime tree is the operational center almost immediately.
Install the software, configure Service Manager, add a deployment, establish its service endpoints and security mode, then manage runtime objects through deployment services.
Classic favors directness; MA favors managed lifecycle boundaries. The better fit depends on whether your main pain is initial simplicity or long-term operational structure.
Scaling classic typically means more process groups, more parameter files, more runtime directories, and more dependence on disciplined naming and shell access. That can work very well, but it leans on operator consistency.
Scaling MA means more deployments and more service-managed objects, but the shape remains more inspectable. Service boundaries help when multiple teams, environments, or automation pipelines must share the same product estate without sharing all the same privileges.
| Lifecycle topic | Classic architecture tendency | Microservices Architecture tendency | Operational consequence |
|---|---|---|---|
| Runtime locality | Installation and runtime are tightly associated in practice. | Software home and deployment state are intentionally separated. | MA usually gives cleaner upgrade and governance boundaries. |
| Administrative scale | Good for smaller estates if naming and shell discipline stay strong. | Better suited to estates needing repeatable remote management and automation. | The break point is rarely transaction volume alone; it is usually team count and complexity. |
| Upgrade planning | More tightly coupled to the local runtime habits of the installation. | Explicitly organized around deployments, services, and home-to-deployment lifecycle. | MA favors more deliberate release choreography rather than ad hoc host-level changes. |
| Automation surface | Strongest through scripts, GGSCI command automation, and local tooling. | Strongest through REST-aware tooling, Admin Client, and service workflows. | Your platform standards should influence the architecture choice directly. |
If the GoldenGate platform will be operated like a shared service with formal ingress, role boundaries, and repeatable deployment automation, choose Microservices Architecture early. If the platform is a contained replication utility inside a tightly controlled inherited estate, classic may remain practical until a broader platform redesign is warranted.
Decision matrix: choose for operating consequences, not nostalgia or marketing pressure
The right architecture depends less on whether a team likes command lines and more on what the estate must tolerate: remote administration, secure deployment boundaries, reverse proxies, explicit path control, multi-team operations, and phased migration constraints. Use the matrix below to keep the choice concrete.
You inherited a working classic estate, shell access is already part of the operating model, and there is no immediate need to expose GoldenGate through a service-tier control plane.
You are building new Oracle replication services, need a web or REST control plane, or must align GoldenGate with enterprise proxy and service-management patterns.
You need coexistence because part of the topology still depends on classic (e.g. legacy sources) while the target operating model for new work is clearly Microservices.
Do not keep classic only because the team knows GGSCI if every surrounding requirement points to service-tier administration and secure remote deployment boundaries.
| Decision factor | Classic architecture is stronger when... | Microservices Architecture is stronger when... | Watch-out |
|---|---|---|---|
| Existing estate | The current estate is stable, well-understood, and not blocked by classic patterns. | You are designing a new estate or performing a major platform reset anyway. | A purely cosmetic migration rarely pays for itself. |
| Remote operations | Remote control is minimal and privileged shell access is acceptable. | Remote and delegated administration are core requirements. | Trying to emulate MA-style operations on top of classic often creates brittle wrappers. |
| Security governance | Host-local control and runtime encryption are sufficient for the risk model. | Deployment security, certificate planning, and proxy integration are first-class concerns. | Security usually decides the architecture sooner than performance does. |
| Topology complexity | The topology is modest and path ownership is easy to keep in operators' heads. | There are many paths or environments that benefit from explicit service-managed routing. | Complex transport estates degrade faster in classic because intent hides in param files. |
| Automation standard | Script-driven host automation is already the accepted platform norm. | REST-aware automation and service inventory are normal platform expectations. | Choose the architecture that matches the automation ecosystem you already trust. |
| Migration pressure | Immediate migration introduces more risk than value. | Migration is justified by upgrade, governance, or topology redesign pressure. | Architecture change without a business or operational driver is usually churn. |
This matrix does not treat the architectures as a simple older-versus-newer performance contest. The more reliable distinction is administrative and lifecycle shape. Performance depends far more on capture mode, apply mode, database preparation, workload, trail design, and target bottlenecks than on whether the control plane is classic or microservices.
Migration and coexistence are architecture projects because pathing, security, and admin habits all move together
A classic-to-Microservices change is not just a process recreation exercise. It changes where operators connect, how services are exposed, how remote paths are defined, how certificates are handled, and sometimes how mixed-version or mixed-architecture links must be staged. Oracle supplies migration tooling for classic-to-MA scenarios, but it is still the surrounding design that decides whether the move feels controlled or chaotic.
Define the target operating model first: secure or non-secure deployment, proxy posture, admin access pattern, and path direction.
Map each classic process group to its MA home: Administration Service ownership, distribution path, receiver landing, and Replicat location.
Test coexistence boundaries explicitly, especially classic-to-MA transport and any secure deployment assumptions.
Cut over operator procedures last, after the runtime path and verification model are already stable.
Why operator procedure migration is usually underestimated
Classic teams know how to think in INFO ALL, parameter files, reports, and host-local restart sequences. MA teams need equivalent muscle memory for deployments, services, paths, and service-mediated health checks. If those procedures are not rewritten deliberately, the architecture might be technically migrated while operations stay mentally classic, which is one of the fastest ways to create confused incidents.
| Migration concern | What to decide early | What to verify before cutover | Common failure pattern |
|---|---|---|---|
| Security mode | Whether MA deployment is secure, cert sourcing, and proxy design. | Admin Client, browser access, and path authentication all work in the final topology. | Teams stand up MA in the wrong security posture, then discover the path design no longer fits. |
| Transport mapping | Which classic pump/Collector map to which distribution paths and receiver endpoints. | Target-side trail landing is advancing where Replicat expects it. | The new path exists but writes to the wrong trail, deployment, or landing boundary. |
| Operator access | Who uses browser UI, who uses Admin Client, who still needs host access. | Routine operations can be performed without improvised privilege grants. | The runtime migrates but emergency procedures still depend on old shell habits. |
| Version constraints | Which components remain classic during coexistence and if assumptions must change. | Trail format and process compatibility are valid across the entire staged topology. | Mixed-version coexistence is treated as an informal promise rather than a tested contract. |
The biggest cost driver is migrating runtime objects before deciding the target service boundary. When that happens, the team reworks endpoints, certificates, distribution direction, operational runbooks, and access controls after the replication pieces already exist. The product can survive that disorder. The project schedule usually cannot.
Verification and troubleshooting differ because the evidence surface differs
The underlying diagnostic logic is the same in both architectures: confirm capture, confirm local or source-side trail movement, confirm transport landing, confirm Replicat checkpoints, and confirm lag interpretation. The difference is where that evidence is easiest to collect and how much of it depends on being on the host.
| What you need to verify | Classic architecture evidence | Microservices Architecture evidence | Interpretation |
|---|---|---|---|
| Process availability | GGSCI process state and reports under the classic runtime. | Administration Service and Admin Client status views. | A running badge is only the first check, never the final conclusion. |
| Transport movement | Pump activity, Manager/Collector behavior, target trail growth. | Distribution path state, Receiver landing behavior, target trail growth. | The proof of transport is target-side landing, not configuration existence. |
| Apply health | Replicat status, report inspection, checkpoint progress. | Replicat service-managed status, reports, checkpoint progress, metrics views. | Apply remains the final truth boundary no matter which architecture hosts it. |
| Lag interpretation | Classic lag commands, reports, and heartbeat evidence. | Service-level monitoring plus heartbeat and checkpoint evidence. | Never rely on one surface alone when diagnosing backlog. |
Classic incidents often become filesystem and report-led investigations. That is effective when the operator knows the host well, but it scales poorly when multiple teams or remote operations are involved.
MA incidents are easier to scope by service boundary, path state, and deployment object ownership. The tradeoff is that operators must understand those service layers rather than reducing everything to a local shell.
| Symptom | Likely classic focus | Likely MA focus | What it usually means |
|---|---|---|---|
| Source trail advances but target trail does not | Inspect pump parameters, remote host settings, Manager and Collector. | Inspect distribution path state, endpoint ownership, and Receiver landing. | The transport hop is the actual fault boundary. |
| Objects exist but operators cannot administer them remotely | Usually a host access or command automation problem. | Usually a deployment access, certificate, or service exposure problem. | The control plane is unhealthy even if replication engines are present. |
| Migration test passes in lab but not in production | Port, filesystem, or shell assumptions changed. | Security mode, proxy path, or endpoint direction changed. | The non-functional architecture was not treated as part of the replication design. |
| Operators restart the wrong thing under pressure | Process-group boundaries were unclear. | Deployment and service ownership were unclear. | The team lacks a clean mental model of the actual control surface. |
Separate configuration evidence from movement evidence. A configured Extract or path tells you only that the object exists. Trail advancement, landing advancement, checkpoint movement, and heartbeat progression tell you that replication is actually flowing.
Version-aware guidance: treat Microservices Architecture as the modern baseline, but respect classic where the estate still depends on it
Current Oracle documentation centers modern GoldenGate operations on Microservices Architecture, especially for service-based administration, deployment management, and current lifecycle guidance. At the same time, classic architecture still matters in real estates, in 21c-era documentation, and in coexistence or migration scenarios. The right expert posture is not to dismiss classic, but to stop treating it as the default answer for new architecture decisions.
Extract, trails, checkpoints, and Replicat remain the durable replication grammar across generations.
Microservices Architecture introduced service-managed deployments and changed the control plane permanently.
Classic documentation and estates remain relevant, especially for inherited deployments and staged upgrades.
Modern planning, security, and upgrade guidance assume MA fluency even when migration coexistence is still required.
If the reasons are mostly habit, staffing comfort, or short-term convenience, the architecture choice is probably lagging the platform requirement.
Classic can continue to be the correct answer if the estate is stable and the operational boundary around it is still appropriate.
That one sequencing decision removes a large fraction of avoidable rework.
Classic architecture is not merely an old interface, and Microservices Architecture is not merely a new one. They represent two different administrative philosophies wrapped around the same GoldenGate replication core. Classic favors local clarity, shell discipline, and direct ownership of the runtime tree. Microservices Architecture favors deployments, explicit services, secure control-plane design, and automation surfaces that fit a modern platform estate.
The right choice is whichever philosophy matches the environment you actually have to operate. If your GoldenGate platform is becoming a shared, remotely managed, policy-governed service, Microservices Architecture should be the planning baseline. If you are responsible for a contained classic estate that already fits its operating boundary, keep it clear-eyed, keep it well verified, and migrate only when the surrounding requirements change enough to make the old boundary the real problem.
Test your understanding
Select an answer and click Check.
Q1 — In Classic Architecture, what is the primary command-line interface for managing GoldenGate processes?
Q2 — Which Classic Architecture component roughly corresponds to Service Manager in Microservices?
Q3 — What does Microservices Architecture add that Classic Architecture fundamentally lacks?
Q4 — Can a GoldenGate Classic Extract send trail data to a Microservices Receiver Service?
No comments:
Post a Comment