With the release of Oracle GoldenGate 12c (22.214.171.124.0) came the introduction of a new architecture that can be used to replicat your business information. This architecture had many different names over the years as it was being developed; which we (Oracle) finally settled on the name of “Microservices” Architecture as we got closer to general release. There are many benefits to the Microservices Architecture and these benefits should give you pause to look closely at this new feature for Oracle GoldenGate 12c.
Before we get into the Microservices Architecture, let’s review the Classic Architecture. In the below image, you see a pretty standard Oracle GoldenGate implementation.
In this architecture, the primary access into the Oracle GoldenGate enviornmentis is through the GoldenGate Service Command Interface (GGSCI). After logging into GGSCI, you can interact and administrate the associated processes, i.e. Manager, Extract (Capture), Data Pump, and Replicat (Apply). The Collectors are pretty much hidden on the target systems, but they are there; just not seen through GGSCI. In this architecture, you data is replicated over TCP/IP between the Data Pump process and Collectors using local and remote trail files.
The downside to this architecture is that, in order to administer the environment, you have to physically login to the server where Oracle GoldenGate is running. With this requirement, many organizations were restrictive on who had access to the server and often caused a debate over who were truely the owners of Oracle GoldenGate.
Althought the Classic Architecture of Oracle GoldenGate has been a bedrock of replication for nearly 20 years, we (Oracle) wanted to leverage that bedrock to transform the way we (industries) replicate data today. This lead to the more flexible and super scalable Microservices Architecture. As you may have guessed, “Microservices” is the mechanism that we are suing to provide access to the “RESTful API” end points. By using RESTful APIs, we (Oracle) have taken a huge leap forward in the replication space. We have broken down the limitations we had around administration and access, while at the same time remaining true to the bedrock that is the foundation of Oracle GoldenGate.
The below image is a view of a simple Oracle GoldenGate Microservices Architecture, for you to review.
As you will notice there are some traditional components of Oracle GoldenGate missing, while there are still extracts (capture), trail files, and replicats (apply). This is due to being a completely new replication architecture which had many benefits. A few of these benefits are:
- Remote Administration
- SSL Support
- HTML 5 webpages for each service/server
- Additional replication protocols (WSS, WS, UDT, OGG)
- Real-time Performance Metrics
In order to understand the Microservices Architecture, you have to understand what each of the servers (or services) provide within the architecture. So, let’s take a moment and talk about these items starting with the ServiceManager.
The ServiceManager is the watchdog process for the architecture on each server in the replication enviornment. Ideally, you should only have one of these processes running. This process can be configured to run in one of 3 ways. These ways are:
- As a daemon
- Integrated with XAG
While the ServiceManager is running, this process will be the main entry point into the Oracle GoldenGate environment. During the configuration process, you will be asked to assign ports for each the servers to run on. The ServiceManager will be the first port you assign. From the HTML5 page of the ServiceManager, you will be able to see all of your deployment homes and associated servers.
The AdminServer is the service that will take the place GGSCI (don’t worry, we still have a command line in this architecture) and Manager in the Classic Architecture. From here, you will be able to setup your credential store, extract and replicats. Most Oracle GoldenGate Administrators will spend their time here. Additionally, from this service you can drill into the running process and review current status, statistics, parameter files, and report file. Making your administration in general much simpler.
The DistributionServer is the replacement for the Data Pump Extract. The service performs all the same functionality as the Data Pump Extract with the exception of transformations. Besides providing all the same functionality, you also get a visual representation of where your trail file is being read from and shipped to. It is very clear to see from the overview page of this services. As you dig into the details of the DistributionServer, you can see the statistics on what is being read and written to trail files and adjust TCP/IP items within the distribution path.
The ReceiverServer is the replacement for the Collectors. The whole job of the ReceiverServer is to accept transmissions from the DistributionServer and write out the remote trail files. From the overview page of this service, you can clearly see where the information is coming from and what trail it is writing to. Just like the DistributionServer, if you look at the details of this service you can see alot of useful information.
Lastly, is the most interesting of the services with the Microservices Architecture. This would be:
Performance Metrics Server:
Finally, we (Oracle) have provide a real-time performance monitoring services with Oracle GoldenGate. Before you get all happy about having a new way to monitor performance, you must have a license for the Oracle Managment Pack for GoldenGate before you can use the GUI or associated metric APIs. If you have that in place, there is so much performance metric information you can retrieve and use in both the GUI and APIs. I would encourage you to take a look.
With that my friends, hopefully, you are a bit excited about using the new Microservices Architecture. There is so much you can do with this architecture and it is going to change how we replicat data, both on-primese, in the cloud, and in hybrid environments.