Manning have made section of my book freely available. The excerpt from the first draft of my book Unified Logging with Fluentd illustrates the Fluentd take on Hello World – the extract can be found at http://mng.bz/nzm8. This is from the 1st chapter to help set the scene of how Fluentd can be configured. The following quote comes from one of the peer reviewers:
The extract includes the use of the log simulator tool – https://github.com/mp3monster/LogGenerator which takes some configuration and can either play synthetic data or replay real logs as current log events in what ever format you want to simulate – for example standard Log4J through to Apache Server logs with the relevant time separation between events.
Book Discount …
If this isnt enough temptations, then perhaps saying that on September 22: Deal of the Day book is my book Unified Logging with Fluentd. Use code dotd092220au at https://bit.ly/3mBRLK2
Oracle’s data integration product landscape outside of GoldenGate has with the arrival of Oracle Cloud been confusing at times. This has meant finding the right product documentation can be challenging, and knowing which product to use in your own technology road-map can be harder to formulate. I believe the landscape is starting to settle now. But to understand the position, let’s look at the causes of disturbance and the changes that have occurred.
Why the complexity?
This has come from I think a couple of key factors. The organizational challenges triggered by Thomas Kurian’s departure which has resulted in rather than the product organization being essentially in three parts aligning roughly to Infrastructure, Platform and Applications to being two Infrastructure and Apps. Add to this Oracle’s cloud has gone through two revolutions. Generation 1 now called Classic was essentially a recognition that they needed an answer to Microsoft, Google and AWS quickly (Oracle are now migrating customers off classic). Then came Generation 2, which is a more considered strategy which is leveraging not just the lowest level stack of virtualization (network and compute), but driving changes all the way through the internals of applications by having them leverage common technologies such as microservices along with a raft of software services such as monitoring, logging, metering, events, notifications, FaaS and so on. Essentially all the services they offer are also integral to their own offerings. The nice thing about Gen2 is you can see a strong alignment to CNCF (Cloud Native Compute Foundation) along with other open public standards (formal or de-facto such as Microprofile with Helidon and Apache). As a result despite the perceptions of Oracle, modern apps are standard a better chance of portability.
Impact on ODI
Oracle’s Data Integration capabilities, cloud or otherwise have been best known as Oracle Data Integrator or ODI. The original ODI was the data equivelent of SOA Suite implementing Extract Load Transform (ELT) rather than ETL as it meant the Oracle DB was fully leveraged. This was built on the WebLogic server.
Along Came Cloud
Oracle cloud came along, and there is a natural need for ODI capabilities. Like SOA Suite, the first evolution was to provide ODI Cloud Service just like SOA Suite had SOA Cloud Service. Both are essentially the same on-premises product with UIs to manage deployment and configuration.
ODI’s cloud transformation for the cloud lead ODI CS evolving into DIPC (Data Integration Platform Cloud). Very much an evolution, but with a more web centered experience for designing the integrations. However, DIPC is no longer available (except possible to customers already using it).
Whilst DIPC had been evolving the requirement to continue with on-premises ODI capabilities is needed. Whilst we don’t know for sure, we can speculate that there was divergent development happening creating overhead as ODI as an on-prem solution remained. We then saw the arrival of ODI Marketplace, this provides an easier transition, including taking into account licensing considerations. DIPC has been superseded by ODI Marketplace.
Oracle has developed a Marketplace just like the other major players so that 3rd party vendors could offer their technologies on the Oracle cloud, just as you can with Azure and AWS. But Oracle have also exploited it to offer their traditional products normally associated with on-premise deployments in the cloud. As a result we saw ODI Marketplace. A smart move as it offers the possibility of exploiting on-prem licensing into the cloud along with portability.
So far the ODI capabilities in its different forms continued to leverage its WebLogic foundations. But by this time the Gen2 Oracle Cloud and the organizational structures behind it has been well established, and working up the value stack. Those products in the middleware space have been impacted by both the technology strategies and organization. As a result API for example have been aligned to the OCI native space, but Integration Cloud has been moved towards the Apps space. in many respects this reflects a low code vs code native model.
This new product appears to be a very much ground up build as it exploits Apache Spark and Function as a Service (FaaS) as foundational elements. As a ground up build, it doesn’t inherit all the adapters the original ODI can offer. This does mean as a solution today it is very focused on some specific needs around supporting the data movement between the various Oracle Cloud storage and Database as a Service solutions rather than general ingestion and extraction processes.
Products are evolving, but the direction of travel appears to be resolving. But we are still in that period where there are capability gaps between the Gen2 native solution and the traditional ODI via Marketplace solution. As a result the question becomes less which product, but when and if I have to invest in using ODI Marketplace how to migrate when the native product catches up.
As some may know we have continued to support our book on Oracle Integration through our site Oracle-Integration.cloud with monthly a roundup of new articles and posts coming from the community. Today we posted the August roundup. This compliments our own writing, and the possibility of adding a cookbook to compliment the original book. There are two sources that we don’t take look at too deeply, the use of videos resources and courses. Primarily because these sources cost, or take time to determine what the content covers. Whilst I’m not providing guarantees, two members of the Ace community that I have had regular contact and respect have developed course ware and video content these are:
For those who regularly follow my blog, I like Groovy as a way of scripting given its portability, proximity to Java, its use of the JVM means its really easy to work with. With the extra language features it makes it easy to work with without needing to setup Maven builds to manage dependencies for something simple. As a result, the utils I’ve produced to support Oracle API Platform CS (here) for example are written with Groovy.
However, not everyone is such a fan, or sees Groovy as niche and, to be honest in the last few years Python has made huge in roads in the scripting space. So I can appreciate the preference for Python to be used. This was really brought home to me by a peer review comments for my latest book project. This got me to thinking what options do I have to remove Groovy from the equation, without resulting in needing to mess with maven POM files. The options as I saw it are:
Replace any use of Groovy extensions with Java libraries
Switch to using Java 11 and the shebang feature (more in a minute)
Compile code with Groovyc and package the jars manually including dependencies.
From Java 11, the ability for a single Java file to be executed without compiling etc was introduced – known as shebang (more here). The issue here is a lot of applications have been certified against Java 8, and in an Enterprise environment this is important. Which means either installing Java 11 locally without changing environment variables, or you need to add code to switch Java versions as necessary. The upside being that you can run your code as a script, and then if necessary build it into a jar to distribute. Aside from the need to switch between JDK versions, Java’s language gets ever richer, but Groovy has a nice set of extensions that make JSON object navigation really nice, and these aren’t necessarily in core Java.
Groovy provides a tool to compile Groovy to bytecode for the JVM (i.e. create class files). From which we can create a JAR file with using the javac command. But this doesn’t bundle the Groovy dependencies necessary to run the jar, as a result Groovy still needs to be installed. You could do this through the use of a maven, Gradle or other build tools. But we’re back to creating a POM file or equivalent., and to be honest creating a POM file from scratch is slow going unless everything lines up neatly with file structures, which it won’t because when you produce a script you’re not expecting to need to worry about packages and associated folder structures.
In looking to see if someone had simplified the process I came across this excellent tool scriptjar (more here). Script jar takes the location of the class files, creates a jar file and loads it with the Groovy jar dependencies, and assembles the manifest file etc. Net result, a jar file created in 2 lines that has no Groovy deployment dependencies to use, and will work with older Java versions such as Java 8.
I started out referring to the API tools, but the same mechanism can be applied to the LogSimulator tool I’ve created that allows you to generate or replay existing logs in real-time or faster than real-time, making it easy to test log monitoring setups from a monitored source all the way through (today it only handles log file replaying or the use of the Java native logging).
Earlier this month as part of the Virtual Oracle Developer Meetups, we were very fortunate to have Oracle Ace, Martien van den Akker present on the subject of the magic of correlations in SOA, BPM, and Oracle Integration Cloud. Martien not only presents to the Oracle community but also is very active on the Oracle community sites (community.oracle.com and Cloud Customer Connect) sharing his wealth of knowledge. When it comes to the tough questions about Oracle middleware tech on these platforms, you stand a good chance that Martien will be the one answering your question.
This insightful presentation not only addressed the traditional Oracle Integration approach using SOA and BPM but also contrasted the capabilities as provided by Oracle Cloud. Martien was generous enough to allow us to record the presentation and share it (below), along with the demo resources from:
Earlier this week I was fortunate enough to be invited to participate in the bol.com’s TechLab podcast on logging. I understand this is the first time that Bol have had an external participant in one of their podcasts, so feeling very honored, not to mention having enjoyed the whole recording process.
bol.com are a European etailer, with a platform based capability. It was really interesting to talk about how they have approached logging in comparison to other organizations I’ve worked with over the years.
I’d recommend checking out not just this podcast (obviously) but others as well given that the guys have been very open about their platform and their experiences.
You can listen to the podcasts from the following links:
The Corona Virus pandemic has had some very odd impacts to the usual technology conferences. We all know that a great number of events have moved from physical to virtual. From a presenter’s perspective has meant the opportunity to present to communities we would normally be less likely submit papers for. For example, the All India Oracle User Group Yatra conference is a significant event in the Oracle Ace/ Groundbreakers calendar – where I have had two papers accepted.
For me to present there, is a challenge as it requires that I lose a week of fee earning time (once you account for the travel). But since the event has gone virtual, I’ve been able to submit a paper, which has been selected …
In addition, the recently postponed Camp Cloud Native which has been lead from the US, has been rescheduled because of the events triggered by the death of George Floyd. As the event is virtual, it wasn’t difficult for the organizers to do the right thing.
With meetups going virtual participating in European events is a lot easier, for example contributing to Aces@Home Episode 3 …
Whilst presenting virtually is the current norm, we are still seeing calls for papers for physical events for October/November this year. It creates a bit of a dilemma. Will it be safe enough to travel? will my family feel comfortable with me travelling (even today we’re hearing news of a serious new outbreak in Beijing)?, will I have to isolate at either end of the journey? Difficult, because I don’t want to submit a paper, and then withdraw at the last minute if circumstances look less secure. Having been involved in user group conference planning, whilst last minute changes will always happen, they can be difficult to cover, so would prefer not to put people in that position.
Whilst I’m not an extrovert by nature, being physically present at a conference, has its plusses – the opportunity to network/meet other Aces to catchup.
So until the physical conference again, be online, be distant, and be safe.
Today was one of my sessions, whilst I only co-hosted, we got to hear a great presentation with a heart warming story which in this challenging times seems all the more appropriate. Christian McCabe (Steltix) and Filip Huysmans (Contribute) presented on how a multinational hackerthon spanning South Africa to Belgium was put together to only help children of Christel House (a charity who work to provide education to those who would not normally get access to it). Not only was the hackerthon engineered to given the students a chance to learn and experience software development in a pretty realistic context, it also provided the school with some software to help their everyday activities, in this case managing books in their library.
The hackerthon yielded a lot of successful outcomes (Steltix wrote about it here), but, what was really interesting is that whilst working with the school, children and interns (from both Steltix and Contribute) took a lot lessons away as well.
Fluentd is both an open source solution for making log management so much easier to work with, particularly for distributed / multi component solutions. But not only that it is supported by many log analytics tools, and central to several cloud vendors log management services.
The goal of the book is to explain how Fluentd can help us and to use the tool. We can’t cover every possible plugin, so we walk through the use of enough plugins and the way features interact you can extrapolate to other plugins.
A couple of years ago I got to discuss some of the design ideas behind API Platform Cloud Service. One of the points we discussed was how API Platform CS kept the configuration of APIs entirely within the platform, which meant some version management tasks couldn’t be applied like any other code. Whilst we’ve solved that problem (and you can see the various tools for this here API Platform CS tools). The argument made that your API policies are pretty important, if they get into the public domain then people can better understand to go about attacking your APIs and possibly infer more.
Move on a couple of years, Oracle’s 2nd generation cloud is established an maturing rapidly (OCI) and the organisational changes within Oracle mean PaaS was aligned to SaaS (Oracle Integration Cloud, Visual Builder CS as examples) or more cloud native IaaS. The gateway which had a strong foot in both camps eventually became aligned to IaaS (note that this doesn’t mean that the latest evolution of the API platform (Oracle Infrastructure API) will lose its cloud agnostic capabilities, as this is one of unique values of the solution, but over time the underpinnings can be expected to evolve).
Any service that has elements of infrastructure associated with it has been mandated to use Terraform as the foundation for definition and configuration. The Terraform mandate is good, we have some consistency across products with something that is becoming a defacto standard. However, by adopting the Terraform approach does mean all of our API configurations are held outside the product, raising the security risk of policy configuration is not hidden away, but conversely configuration management is a lot easier.
This has had me wondering for a long time, with the use of Terraform how do we mitigate the risks that API CS’s approach was trying to secure? But ultimately the fundamental question of security vs standardisation.
Any security expert will tell you the best security is layered, so if one layer is found to be vulnerable, then as long as the next layer is different then you’re not immediately compromised.
What this tells us is, we should look for ways to mitigate or create additional layers of security to protect the security of the API configuration. These principles probably need to extend to all Terraform files, after all it not only identifies security of not just OCI API, but also WAF, networks that are public and how they connect to private subnets (this isn’t an issue unique to Oracle, its equally true for AWS and Azure). Some mitigation actions worth considering:
Consider using a repository that can’t be accidentally exposed to the net – configuration errors is the OWASP Top 10. So let’s avoid the mistake if possible. If this isn’t an option, then consider how to mitigate, for example …
Strong restrictions on who can set or change visibility/access to the repo
Configure a simple regular check that looks to see if your repos have been accidentally made publicly visible. The more frequent the the check the smaller the potential exposure window
Make sure the Terraform configurations doesn’t contain any hard coded credentials, there are tools that can help spot this kind of error, so use them. Tools exist to allow for the scanning of such errors.
Think about access control to the repository. It is well known that a lot of security breaches start within an organisation.
Terraform supports the ability to segment up and inject configuration elements, using this will allow you to reuse configuration pieces, but could also be used to minimize the impact of a breach.
Of course he odds are you’re going to integrate the Terraform into a CI/CD pipeline at some stage, so make sure credentials into the Terraform repo are also secure, otherwise you’ve undone your previous security steps.
Minimize breach windows through credentials tokens and certificate hanging. If you use Let’s Encrypt (automated certificate issuing solution supported by the Linux Foundation). Then 90 day certificates isn’t new.
This may sound a touch paranoid, but as the joke goes….
Just because I’m paranoid, it doesn’t mean they’re not out to get me
Fundamental Security vs Standardisation?
As it goes the standardisation is actually a dimension of security. (This article illustrates the point and you can find many more). The premise is, what can be ensured as the most secure environment, one that is consistent using standards (defacto or formal) or one that is non standard and hard to understand?