Today was the first run of some new presentation material looking at the use of GitHub Actions using Runners deployed on OCI Free Tier. The presentation was actually physical rather than virtual which was after 2 years of virtual presenting, rather refreshing. Not to mention the UKOUG hosted the event at the Oval Cricket ground, which made for an interesting venue. The example configuration is included in our GitHub OCI Utilities repository (as we use this solution to help validate and test our development work).
The presentation itself (which includes screenshots of the setup of a simple Action and runner) is here, note I have disconnected my Runners, but you will be able to see the Action configuration but if you try to trigger activity through my repository then nothing will happen.
We have another blog post related to the webinar sharing some more detail. This will be published in a week or so on blog.oracle.com.
The Deutsche Oracle Anwendergruppe (DOAG) conference took place virtually this week. DOAG and the UKOUG events are probably the biggest of the European user group events. With UKOUG happening at the end of the month.
My presentations at DOAG have been an update on which GraphQL, gRPC or REST API technology to use (see the presentation material here), along with a brand new presentation, again relating to APIs. But this time we’re looking at the application and capabilities of the Oracle Cloud’s API which can allow us to manage a wide range of services (see here). While I don’t have the demo piece recorded, you can see the slide aspect here.
As mentioned I will be presenting at UKOUG Together. I have another brand new presentation for this as well, which will look at GitHub Actions combined with Oracle Cloud. We also have our first 2022 conference confirmed, in the form of API World.
We’re excited to be presenting on November 16th 4.30pm CET (3.30pm GMT). I hope you can join us by registering here
Heathrow rapidly moves to Oracle Cloud and connects with hybrid Integration.
The continuous delivery of constant small innovations can bring benefits faster without risks. Join us to hear how Capgemini’s Agile Innovation Platform (AIP) combined with Flexagon’s FlexDeploy DevOps platform enable this model of innovation and achieve tangible benefits to customers using the cloud capabilities and traditional on-premises ERP.
Phil Wilkins, Capgemini Integration Architect, and Dan Goerdt, President of Flexagon will describe how the combination are highly effective at delivering micro-innovation demonstrated through real-world customer results.
From this session, you will learn:
How the Agile Innovation Platform’s building blocks and templates allow development teams to reduce time to value.
How FlexDeploy brings unique benefits to both Open Source and Oracle-specific technologies.
What were the challenges solved and benefits gained by actual customers using AIP and FlexDeploy.
How Integration is the foundation of continuous delivery and innovation.
I recently presented at APIWorld about how API definitions go beyond the payload specification into providing details of terms and conditions and so on. You can see the presentation here (more about my presentations here).
One of the questions during the presentation did I have other examples of good APIs, reflecting the points I’d made. A very valid question, to which I didn’t have more examples to hand, hence this post.
So the easy answer would be to point to an excellent article on Nordic APIs (here) that address the question and explain why they rate the APIs. But that’s a little bit of a lazy answer and in all fairness, the examples provided are from organisations where APIs are recognised as a primary or important contributor to business revenue. So I’ve looked at areas where the API may not necessarily be seen by the business as the primary source of revenue. With the examples provided, we’ve described what we think is good, or not so good about them. Hopefully, through these examples, you’ll see why points are made in the presentation. So here are my reviews…
Through my day job at Capgemini UK I have regular dealings with Flexagon as we use their FlexDeploy product with a number of customers (as we do recommend the product). Recently I was invited to contribute to a paper being developed by the Flexagon team. The fruits of the collaboration are now available at https://info.flexagon.com/ebook/devops-for-developers. The Flexagon team have done a nice job with it, and we’d recommend taking a look if you’re wanting to know more about DevOps and CI/CD.
The paper is completely free of sales pitch – completely devoid of product references which makes for a good read.
This isn’t the first time I’ve written about the Oracle Cloud SDK (check here), but it seems rather fitting, as some of the utilities I’ve been working on are open to the community, and #JoelKallmanDay is all about community. If you’d like to know more about #JoelKallmanDay then checkout Tim Hall’s blog here.
Oracle have provided a very rich API and then overlaid it with a number of SDKs in Python, Java etc. The SDKs immediately remove the work of creating connections and correct payloads. Taking the Python SDK for example, all I need to do is create a standard configuration file with all the necessary connection properties to my OCI instance. Then it’s simply a case of creating the correct Python object for the correct group of services wanted. Then it’s down to populating the object attributes. This is the illustration of exactly what a good SDK does. I can lean on my IDE to use the correct set and get operators. The code for establishing a connection is done for me.
What I’ve found most striking is the level of consistency in the methods provided by the SDK regardless of the service. This makes it very easy to develop functionality without needing to check every API before I can write any code. it would be easy to say, so what. But when you look at the breadth of the OCI services it becomes more impressive.
The convenience doesn’t end there. Rather than having to run your utilities from a local command line (Python means we’re pretty much OS agnostic), the Oracle Cloud shell is preconfigured with Python, OCI SDK, GitHub and FTP server and basic Linux text editors. The all amounts to the fact that you can use your scripts/tools from within the web UI of OCI. Edit your credentials file locally, push and pull any changes to the scripts from the shell and any Git repo such as GitHub.
With this insight, we just need to build that catalogue of accelerator tools to make those repetitive processes just a little easier. For example ensuring that when you tear down your manually created services all interlinked entities are deleted first (which can be troublesome with policies, groups, compartments and so on).
The log simulator we’ve built and written about in the past has had a release made that lines up with the Logging In Action book (v0.1). I am now continuing to add improvements on the main line. Not best Git branching practice, but as I’m working on this solo it doesn’t represent a problem.
If you expect multi line events all you need to do, is add to the properties file a name value pair, with the name FIRSTOFMULTILINEREGEX and the value is a Java/Groovy regular expression which can be used to determine if a line in a log entry is the 1st line in a new log. Then all subsequent log lines are appended to the previous line until a line identifies as a new log entry. The log entry will be written with newline characters in the same place as the read.
In addition to this if the synthetic log events need to be set to be new line then using the ALLOWNL property to be set to true will result in any new line escape sequences (\n) to be made into proper new lines in the output.
The details are all included in the documentation in GitHub.
We’ve got the peer review comments back on the completed 1st draft back of the book. So I’d like to take this opportunity to thanks those who have been involved as peer reviewers, particularly those involved in the previous review cycles. I hope the reviewers found it satisfying to see between iterations that their suggestions and feedback have been taken on board and where we can.
The feed back is really exciting to read. Some tweaks and refinements to do to address the suggestions made.
The work on the Kubernetes and Docker elements and the chapter which has become available on MEAP has helped round that aspect off. But importantly, the final chapters help address the wider challenges of logging, and some of the feedback positively reflects this.
To paraphrase the comments, we’ve addressed the issues of logging which don’t get the attention that they deserve. Which for me is a success.