DevopsDays 2019 moved away from the “culture” focus of the 2019 events. There are therefore technical notes this year. I will format these better as time goes on. For the moment though here they are for what they are.

dod-edi.info for generic info on the event

The big takeaways this year might be “Team structure / integration counts” and “Learn to walk before you run”Last year was veering off into Dev and Ops “living side by side on a piano keyboard”. This year even the “culture” talks took a more practical business organisation approach to what that can actually look like.

October 17, 2019
08:00 – 09:05 Registration and coffee
09:05 – 09:15 Opening welcome
09:15 – 09:45 Stuart Davidson – TBA
Are devops “product teams” or “enablement teams”? This was expanded upon later with looks at team organisation. Interesting to see the tandem nature of the questions “what are we trying to achieve with the team?” and its influence over “how do we arrange the team?” In large organisations hybrids were a potential.First book recommendation 

09:45 – 10:15 Andrew Dufour – System Accidents: The Unanticipated Interaction of Multiple Failures
Another “dead people – disaster enterainment” talk – I’m still not liking using contemporary disasters to make talks engaging. God knows there are plenty of prior examples – e.g. Tay Bridge, Titanic etc.
Recommandation of YouTube talk – https://www.youtube.com/watch?v=xA5U85LSk0M “How Your Systems Keep Running Day After Day – John Allspaw”
https://www.amazon.com/John-Allspaw/e/B002BMN7XW

Big and interesting question for me personally “Why were people who know not persuasive?”https://www.amazon.co.uk/Drift-into-Failure-Sidney-Dekker/dp/1409422216
Some discussion of the “amoral calculator” – had a root around – https://quizlet.com/44514109/the-challenger-vaughn-flash-cards/
so tied up in “normalisation of deviance”.
Alleged take away “Diversity is Better” – I’d like to see citations on this. I like working in diverse teams, gender, sex, nationality, race, culture religion I love it all. However, clashes of people that have different tolerances to correction, inability to view things from another direction, an unwillingness to accept that intention and execution cna be at variance. I’d rather have a bunch of imaginative people in a supportive environment (homogenous or not), than a group of unimaginative people who main motivation is backbiting or identity politics.

10:15 – 10:30 Break + coffee
More catching up with Remi and Alex from Ingenico – is the grass green on the other side of the fence? It is hard to tell.Nice compliment from Remi about the work I carried out 6 years ago – good to know it wasn’t in vain and I still have 20 year software and recent software in every high street in Britain ;-).
10:30 – 11:00 Jessica Andersson – From Developers and Operations to DevOps and Autonomous Teams
https://twitter.com/MeltwaterEng
https://github.com/meltwater/MeltwaterEng-public-presentations/blob/master/files/2019-10-17-from-devs-and-ops-to-devops.pdf
Takeaways 1) 30% improvement (not quite sure what that means) 2) you build it – you run it 3) Everyone on call – pay regardless of call out (reduce conflict of interest)4) Skills matrix5) Celebrations – common goalsThe nightmare of different laws on “on-call” in different countries

11:00 – 11:30 Joe McGrath – Wrangling Data Science in a DevOps World
https://www.kainos.com/
Machine learning needs real data (access to live data)Large quantities of data also required (std issues of big data and flexible processing) https://en.wikipedia.org/wiki/Fog_computing
Stripped down data (only the fields you need)Need to knowPetabytes of dataModels are bigFlexible processing capacity
For storage you need an artefact repo – people will deposit bit files in git if you let them.For generation then issues are eased by automatic generation (where recipe and config are what were supplied) – also automate garbage collection to clear out old models.
Jupyter is the de facto tooling. Sagemaker.
 Development requires much greater resource than production. Data scientists are not devs and are not as big on reproducability and inclined to throw too many resources at marginal improvement.
Use Githooks and makefiles to automate. Githooks for example can be used to automatically train and deposit the config and data used.Tool to strip “jupyter notebooks” outputAutomate model trainingDeployment options -1) Docker + API + Model2) AWS and Sagemaker3) Azure databricks4) Google ML
Use standard security methods – e.g. publish behind secure TLS; Sanitize input; Protect data (data modifications can be used to break or adjust models).

11:30 – 11:45 Break

11:45 – 12:15 Maik Wojcieszak – 7 Effective ways to waste time
@tmlsoftware
To make meetings effective – agenda; <5 topics; minimum people; encourage engagement (all a bit NSS).
“Because it is a strategic decision” is BSDon’t bother asking customer for prioritized requirements – waste of time – no context.Beware “Bright ideas” but no customers – they might be a waste of time. NSSDunhigg : The Power of Habit: Why We Do What We Do, and How to Change https://www.amazon.co.uk/Power-Habit-Why-What-Change/dp/1847946240

12:15 – 12:45 Piotr Gaczkowski – Ego-less Programming — the philosophy of better code
12:45 – 13:45 Lunch Break
13:45 – 14:15 Ignites
Dave Stanke – All Tech is Debt @david.stanke “Did you ever have to figure out code before modifying it?” yes, every time. Users need retrained (although small increments helps with this). Slackbot to help people raise and close trivial issues. donut.com The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling: https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
Adarsh Shah – Role of Team structures in DevOps Transformation Journey
Turned out to be a trailer for the talk the next day
Emanuil Tolev – 4 ways to help people in their careers

14:15 – 14:30 Sponsors
14:30 – 14:50 Open Spaces Proposals
14:50 – 15:05 Coffee

Open Spaces Session 1- 15:05 – 15:35
(four options in each session – the one chosen marked with an asterisk)
Hutton Room – DevOps & Agile in regulated industries.
Boardroom – Engineering Enablement
* Biosphere Blue – Which managed Docker container platform do I want?
Salisbury Suite- Is re-imagining the wheel always bad?

Big room (Biosphere Blue) for this: Openshift needs a team of 6. Use ansible and Molecule to drive system test

Session 2 – 15:40 – 16:10
Biosphere Blue – What is your team topology.
Salisbury Suite – How to implement DevOps for zOS environments?
Boardroom – Speaking at conferences and Meetups.
* Hutton Room – How do you introduce TDD/BDD or should you?

Cucumber scripts can provide estimates (although, and this was a bit scary “if you are still doing estimates”).Cucumber scripts – created by analysts(but placed in a “do not run” directory); picked up dev and massaged to be runable.Selenium tests take about 10 secs per test and “expect some brittleness”. Use the tests of the target to test the deployment scripts and the deployments themselves.

Session 3 – 16:15 – 16:45
*Biosphere Blue – Bad habits vs. good habits in DevOps
Salisbury Suite – Secrets management
Hutton Room – Mental health in Tech
Boardroom – DevOps. How to get started
16:50 – 17:00 Day Close
17:00 – 20:00 Evening Reception and Networking

October 18, 2019
08:00 – 08:55 Registration and coffee
08:55 – 09:00 Opening welcome
09:00 – 09:30 PJ Hagerty – From Turing to Big Data: A Look at Computing and Analytics
A keynote (no comments)

09:30 – 10:00 Tom Riley – Prometheus in Practice: High Availability with Thanos
thomasriley.co.uk There are some standard logging tools – how do these compare with nagios and Datadog ? Check this out before re-inventing the wheel.

10:00 – 10:15 Break + coffee
10:15 – 10:45 Andy Burgin – History repeating
Roles of “platform engineering” Providing self service platforms; Industry best practices; test,integrate,deploy,operate; Optimal to automatedMission Statement : Outside Squad – no human between feature and customerAnother person in favour of Chatops/chatbots – this time an advocate for Monkeybot

10:45 – 11:15 Adarsh Shah, Priyanka Rao – Enabling DevOps culture with a Platform engineering team
This was very good – How to Avoid another Silo- Enablers vs doers- Cross team internships- Pairing with App Dev Team- Lunch and Learn sessions- Common goals
Pair stairs – encourage story pair rotation. Anchor on area (what is this?). Glossary (e.g. environment means something specific in Docker). Postmortem on issuesSkills matrix
General arguments — product thinking – rather than project thinking- Observe and talk to your internal customers- KPIs for a bit of objectivity- Innovate and experiment (safety and space).
The Path to Production – a roadmap for devopsAcross the top – concerns- Logging, Monitoring, BC, DR, Security, Infrastructure and SupportDown the side – horizons- Now;Soon;Later;Near;FarPlans are there to be shared.

11:15 – 11:30 Break
11:30 – 12:00 Ali Hill – Don’t Be a Hero
This was a well constructed talk on the pitfalls of overdoing it. I don’t know if you would call it “burnout” but certainly an argument for “pacing” https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3230825/
There is quite a lot of glib medicalisation around this topic.

12:00 – 12:30 Nataliya Remez – Cultural aspects of DevOps transformation
Empathy Map Canvas – Google it https://www.amazon.co.uk/7-Rules-Positive-Productive-Change/dp/1523085797
https://www.amazon.co.uk/Esther-Derby/e/B002BLJE8A/ref=dp_byline_cont_book_1

12:30 – 13:30 Lunch Break
13:30 – 14:00 Ignites
Adrian Mouat – Advanced Container Build Tooling
Good stuff from Adrian covering advantages and pitfalls of advanced tooling. I’d need to be doing this day to day to get more from it.
Look up “Tonus Tiigi” for more info and YouTube talks
Nik Knight – Using Coaching Skills to Grow Compassion, Empathy and Kindness in DevOps
A bit of a change of topic – main takeaways – talk the person through the 5 steps of strategic decision making – consider training people to mentor via role play
Andy Burgin – So You Want To Run Your Own Kubernetes Cluster ?
Don’t do it – use a managed service until you are confident

14:00 – 14:15 Sponsors
Open Spaces Session 1 – 14:50 – 15:20
Biosphere Blue – Why do we still use Jenkins
Hutton Room – Hacking through the tools jungle
Boardroom – You build it you run it
* Salisbury Suite – Release management in a continuous delivery world
Check out K3S “sort of Kubernetes lite”

Session 2 – 15:25 – 15:55
Biosphere Blue – Monitoring best practice
Salisbury Suite – Diversity in tech orgs
Hutton Room – Software engineers on call
* Boardroom – Deployment: what strategies and tools do you use
Fix forwards – i.e. don’t look back – better to fix than revertMoving the DB forward – modify getters/setters/lo-level to cope with both – when client changes are complete then tidy up. Example: to change telephone number to string – add field – change getters/setters to set both and convert when accessed – when done covert the rest and delete the old column.
Do NOT try to change your project cadence all in one go (six month releases to daily releases in one step is madness)
This man talked sense:Paul Hammant 
https://trunkbaseddevelopment.com
https://www.branchbyabstraction.com
https://ph-l.in/ks

Session 3 – 16:00 – 16:30
Salisbury Suite – Project work firefighting improvements : the best balance
Hutton Room – DevOps vs. Legacy and vendor software
Boardroom – Making (regulatory) security processes agile + valuable
* Biosphere Blue -Do you treat your laptop like a cow,
DevOps for local dev envsIf using ansible as a dev-machine setup tool then just iterating over an app deploy list is a good startI need to check out no-machine again
16:30 – 16:35 Return to main room
16:35 – 16:45 Day Close

And off to the bus station to meet son #2, and thence Black Isle to see Ma and Pa.

I’m slowly working my way through the links and business cards acquired.

Springsmith Ltd was wound up in February 2014. This was following ceasing trading on 28th April 2013 and VAT deregistration.   With the company being registered in England, and no current contracts the sensible thing was to close the company. Thankfully I’m still here… the contact information will remain valid, and like all right thinking business people I’m always on the look out for an opportunity.  Thank you to our customers, associates and friends; particularly those who had to put up with hearing about the frustrations of administration, tax, agencies, accountants, etc etc.

Working in a fast paced but ultimately easily managed way, sometimes these seem contradictory. Working with Git and Subversion you can have your cake and eat it. Github, and similar, allow access you repository using either, but what about those working in environments where Subversion is mandated for projects, but want to use Git for a more agile, more frequent, more personal checkin pattern? 

The Promised Land

There does not seem to be much debate in the software community these days that Git is taking the version control world by storm. This is happening for many sound reasons. Which is great, unless you work in a company where Subversion/SVN is the order of the day.

Disagreement

Choice of version control tool is very much like choice of editor – everyone knows which one is best – except they do not agree with one another. Some people even try to impose personal tools, rather than adopt a policy of “use what makes you happy”. Those people are obviously bananas.

Subversion isn’t really suitable for “Personal Agile”.

Git and Personal Agile

“Personal Agile, what do you mean by that?” I hear you ask. Well…
1) Drive the code forward
2) If it turns out good check it in
3) If it turns out bad role back
4) If it is really not going to plan roll further back
4) Repeat until you get the code where you want to go

This is a pretty aggressive way of working, and in order for it to work partially working/half-baked/frankly embarrassing efforts get recorded along the way; it has to be quick; it has to avoid impacting upon other people and branch’n’merge has to be right in there. Git lets you do all that. SVN does not.

Subversion – it’s in with the Bricks

Many companies have a significant history using Subversion. SVN is perfectly fine for control and good for controlling projects.  People with an SCCS, DSEE, RCS, CVS, ClearCase, SourceSafe background find it is easy to follow.

Version control is however a team collaboration tool so there has to be agreement, respecting what each of these tools can offer and the momentum of history.

One day when the Subversion fans have all retired, the world will see the light and move to Git, but until then… let me tell you a secret…the choice between SVN and Git is a false one because they can co-exist.

Living sided by Side

One thing that many people don’t appreciate is that you can run Git and SVN on the same directory at the same time. This has been eased by the latest version of SVN client adopting the Git convention of a single .svn/.git directory at the top of the tree rather than throughout) which makes things a good deal tidier.

Provided that .git and .svn are listed in the .ignore files it works just peachy – so you can run your own private Git with local “commit/push to Git as often as you like”/rollback policy; and commit/update with SVN only at suitable landmarks e.g. each bugfix / feature introduction.

Tortoise Git and Tortoise SVN work fine in this configuration (with the exception of the icons, which is sugar anyway).

The usual rule of thumb of not leaving it out of SVN too long still applies.

# Ignored files
# Placed in the public domain by Springsmith Ltd in 2013
#
# Note: the first few lines are commented out as they concern
# deliverable executables and without a Maven repository you
# probably want to tie these in with the code that generated them.
#
# *.exe
# *.jar
# *.dll
# *.apk
*.suo
*.user
bin
obj
*.pdb
*.cache
*_svn
*.svn
*.suo
*.user
*.build-res
*.o
*.lo
*.la
*.al
.libs
*.so
*.so.[0-9]*
*.a
*.pyc
*.pyo
*.rej
*~
\#*\#
.\#*
.*.swp
.DS_Store
.git


There is always a debate among those in the software industry (and especially contractors) as to where technology is going to go and what skills are likely to be in demand. This post is an attempt to look at technologies in the whole software stack from  low level drivers to number crunching server software; from top to bottom; from by way of  mobile apps and web services; and surprisingly there is a commonality of themes between them all!

C to remain at the heart of low level drivers and native methods.

This is not really a prediction. It is just a fact  C is really little more than a macro assembler in terms of its abstraction capabilities – in fact it is really a macro assembler for a stack based machines. As such it is ideally suited to the very bottom software layer. Although C++ can add OO on top of that it is probably as well to jump to proper abstracting languages as rapidly as possible. There are exceptions to this for very time sensitive issues such as protocol stacks for communications but, in truth, those are few and far between.

The Java language to continue to make in-roads into the embedded space.

Android phones, e-readers such as Kindle, set-top boxes tablets and Smart-TVs are taking over the world. These platforms all run OSs based on Linux, and have Java based development environments. Increasingly, these are going to provide the standard for GUI interaction that consumers expect, on everything (as surely as colour LCDs took over from Starburst LEDs and Nixie tubes).

Anyone who has coded up a GUI by hand understands just what a tall order it would be to code up a system to compete (just ask Nokia and RIM). Thankfully all the fore-mentioned devices are supported by reference designs and backed by documentation and pool of talent (albeit an in demand pool).

Javascript, HTML5 and CSS to take over data-centric and enterprise applications.

Java applets on webpages are as dead as Flash. Where users interact with data the browser is already king; but the need for browser agnostic

There are fantastic tools for developing for Javascript, HTML5 and CSS; many of them drag and drop and customise.

All the facilities of modern devices can be accessed via such tools and using suitable frameworks, such as Spring, they can interface with the plethora of communications, SOA services and databases which make up the model and control aspects of modern systems.

Groovy and Spring  features (and then Java 8) to take the back-office by storm.

The productivity increases brought about by the use of Groovy and frameworks like Spring will make them an obvious choice for the back office. The devolution of responsibility to smaller SOA services will make the use of tools to generate and maintain such services a no brainer. Groovy’s integration with automated testing (via SoapUI) and its ability to hook straight into Java, will make it the RAD tool of choice.

The facilities provided by Groovy and Spring are both having an impact in the design and specification of Java 8; sometimes directly and sometime obliquely, but functional programming, easy data persistence and cross-cutting are definitely making their way into the Java roadmap. That change to Java will take some time but even once it is made Groovy and Spring based systems will interact more easily and port more readily; and further skills acquired with Spring and Groovy will be the closest thing to experience available in this fast evolving environment.