Kubernetes Best Practises – Review & Mindmaps


, , , , ,

I’ve had some time to catch up on books I’d like to read, including Kubernetes Best Practises in the last few weeks. While I think I have a fair handle on Kubernetes, the development of my understanding has been a bit ad-hoc as I’ve dug into different areas as I’ve needed to know more. This meant reading a Dummies/Introduction to entry style guide would, to an extent, likely prove to be a frustrating read. Given this, I went for the best practises book because if I don’t understand the practises, then there are gaps in my understanding still, and I can look at more foundation resources.

As it goes, this book was perfect. It quickly covered the basics of the different aspects of Kubernetes helping to give context to the more advanced aspects, and the best practices become almost a formulated summary in each section. The depth of coverage and detail is certainly very comprehensive, explaining the background of CNI (Container Network Interface) to network-level security within Kubernetes.

The book touched upon Service Meshes such as Istio and Linkerd2 but didn’t go into great depth, but again this is probably down to the fact that Service Mesh ideas are still maturing, and you have initiatives like SMI (Service Mesh Interface still in the CNCF’s sandbox).

In terms of best practices, that really stood out for me:

  • Use of Taints and Tolerations for refined control of pod deployment (Allowing affinity to be controlled to optimise resilience, or direct types of pod deployment to nodes with specialist capabilities such as GPU).
  • There are a lot more differences and options then you might realize in terms of ingress controller capabilities, so take time to identify what you may need from an ingress controller.
  • Don’t forget pods can be scaled vertically with the VPA (Vertical Pod Autoscaler)as well as horizontally through the HPA.
  • While using a managed persistence service will make statement storage a lot easier, stateful sets will give you a very portable solution.

As with a lot of technical books I read. As I go through the book I build up a mind map of what I think are the key points. Doing so leaves me with a resource I can use as a quick reference, but creating the mind map helps reinforce the learning. So here is the mind map …

Greening our work compute needs


, , , ,

As a consultant working with clients, we always need to address security considerations for clients, their networks and data. Typically this might mean ensuring I could connect to the correct network through a VPN with the secure client software installed. Then work through a Citrix set-up for the tools we’re allowed to use.

Since the start of the pandemic, there seems to be a marked shift towards issuing consultants with customer provided laptops that have been configured and locked down. This means I can’t use the client laptop to connect to my employer’s network to interact with our own systems – making it easy to leverage our existing resources to support the customer and conversely no trust or contractual position that might allow our company devices connecting to a VPN or ring-fenced part of a network.

Interestingly there seems to have been a drift away from the ideas of BYOD (Bring Your Own Device) which may come from the fact that outside of smaller very tech-savvy organizations, BYOD can be seen as challenging to support.

As this Google Trends report shows over the last five years the trend has been until the last couple of months showing a generally downward trend. Not authoritative proof, but hints that it hasn’t accelerated as you might expect given remote working.

By the customer supplying a laptop, there is an effort to control intrusion and other security risks. But the problem is, now I have a device that I could easily take off-line and work to defeat the security setup and the client would be non the wiser, or worse it is another laptop that could ‘get lost’ or ‘stolen’ with a greater chance of having sensitive material. Every new device is without a doubt an elevated risk for the client and a cost to support (this of course is also an argument for not applying BYOD).

Continue reading

Detailed (Low Level) documentation


, ,

Low level aka detailed design documentation has been an interesting point of debate. We range from the agile manifesto which states focus should be on working code over documentation and people using this as an argument for not producing documentation. On the other end of the spectrum as someone working for a large SI, documentation is more often than not contractually binding and accurate docs are key when taking work from a different supplier organization.

It is clear that documentation is an essential element. But I do agree with the agile manifesto, a business operates on its software, not documents, although the docs help us keep the software maintained and running.

How do we balance the age-old conflicts of …

  • Documents get out of date because they are kept separate from the implementation
  • Documents, particularly when rushed don’t provide the information necessary
  • Document templates having sections used a tickboxes rather than guide rails
  • Making sure we’re working with the most upto date document


One of the key issues for documents getting out of date is a compound issue of accessibility, visibility and ease of maintenance. These compound to separate the documentation from the reality of code and configuration.

This can be eased by bringing documentation to being ‘physically’ closer to the code as we often see with readme markdown files on GitHub for example. But we can get closer with quality code commenting, particularly for each package and module. Just about every code or notation format had its own document generator from well-proven Javadoc to Terradoc for Terraform. To illustrate my point here are a couple of examples:

If done well the documentation can be generated and deliver the right information. It would mean in structured change management the change task for the code includes the documentation. The ideas behind combining code and documentation can be seen with good API Blueprints.

When you still need to produce publishable documents, you have the opportunity to stitch multiple class and package generated docs together using tools such as pandoc. Arguably it would be the developer’s job to establish the pandoc configuration file (Documentation as Code).

You can add to this if done carefully, by adding diagrams such as UML representations. Importantly this process can generate representations that include lots of detail that would be noise to the key representation (time for tools like Sparx to support annotations that can give hints as to what to show in a generated model).


The biggest risks of this approach are:

  • People paying lip service to documenting code, or using the argument that agile means no documentation (an age old misrepresentation).
  • Comments reflect the code correctly
  • Assuming the documentation will be clear because it is writte6x n

These pitfalls could be in theory be addressed through some smarts such as comparing the volume documentation generated against the number of lines of code and code complexity metrics.

But like many things, good culture and good application of principles are essential.

Exploring further

There are growing dedicated resources in this space, check out:

GitHub Actions on OCI


, , , , , , , ,

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.

Implementing GitHub Action Handlers (aka Runners) on OCI
Continue reading

Busy week with webinars & virtual conferences …


, , , , , ,

It has been a busy week with the day job of delivering to customers, with a webinar with Oracle, Flexagon and a customer – Heathrow Airport. Plus two technical sessions for DOAG.


The webinar is the latest step in the partnership between Capgemini and Flexagon. If you’d like to see it, the recording can be accessed here.

The webinar development was very much a team effort with Oracle providing the hosting and promo logistics (particularly from Jurgen Kress and input from Daryl Eicher). Presentation development effort with Flexagon (Dan Goerdt and Tanya O’Connor). Of course the great input from our Heathrow customers – Mark South and Nick Byng-Maddick.

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.

Coming up

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.

Presenting with Oracle, Flexagon and Heathrow Airport


, , ,

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.

APIs more than a payload spec – Examples of Good APIs


, , , , , , , , , , , , , ,

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…

Continue reading

DevOps with Flexagon


, , ,

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.


Automating OCI Tasks with OCI Python SDK #JoelKallmanDay


, , , , , , ,

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).

LogSimulator new features


, , ,

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.

Continue reading