2024-11-29
Objectives
grade 4, very effective, Rating Description
- achieve committed objectives and surpass some of the most critical ones, contributing to the overall success of the team and the organization
- achieve quality of work meeting all and surpassing some of the agreed-upon work standards
- anticipate their customer needs and proactively drive solutions
- proactively and quickly adapt their approach to effectively manage changes in the work environment
- demonstrate personal accountability and go the extra mile in pursuit “stretched” achievements, working with limited or no supervision
- demonstrate and developed additional skills and behaviours that enabled a better than expected result for the business
- set an example by finding better and more effective ways of doing things and sharing them with others
- provide support, guidance, mentoring and training to others especially when the need arises or when called agreed-upon
response
Objective 1: We have successfully consolidated the three tools identified (adviser, crtxctl, inspector) into a single integrated tool available through web, command line and api channels. We have clarified that the ‘operations’ repo is used to ‘incubate’ ideas with the successful ones being promoted in due course. We have avoided any other new tools emerging.
A good proof point of this was when a new question arose during planning of how frequently a certain deprecated configuration occurred. The project is now set up in such a way that a simple change of a dozen or so lines in a couple of classes could provide the answers. And rolling it out automaticallly was possible in a single pull request.
Objective 2: The Inspector repo is now vertically integrated with all Inspector code from infrastructure to user interface in that single place. It also has a build system that supports the standard project lifecycle (test, package, verify, publish, deploy) supported by tooling native to the development stack. Furthermore, the same build lifecycle is used within CICD (Github Actions) to minimise the risk of divergent behaviour. I strongly believe this integrated approach offers lower cognitive load and better auditability than the previous approach of multiple repositories whose connection is only apparent with either tacit knowledge or long investigation.
This has been well received and adopted within the immediate team and aligns well with the wider organisation SDLC initiative. I believe the opportunity exists to expand this use more widely in 2025, management support permitting.
Both objective 1 & 2 permitted me to demonstrate mentoring and raising the effectiveness of other team members.
Objective 3: Progress has been in the form of ruling things out rather than finding a solution to pursue. Existing serverless platforms that build on Kubernetes platform are either defunct (OpenWhisk) or fail to reduce cognitive load (Knative). On the other hand platforms that could reduce complexity (AWS serverless technologies such as Lambda, Step functions and EventBridge) are too far from the skills and culture of the existing organisation to be readily adoptable.
By Q3 we started discussing what we termed ‘Cortex Apps’, that I believe captures the essence of the ‘Serverless’ ambition in a way better suited to existing Elsevier technologies and teams. There are still differences in the way different people describe this but I believe we are starting to coalesce around something to take forward into 2025. I have used Dev10 time to prototype one incarnation of this in order to better build a shared understanding.
Behavioural feedback
To me the ‘humble, authentic and collaborative’ objective means being brave in asking the ‘stupid questions’, owning the areas I have less experience than others and ensuring that I listen to the alternative approaches since there is never a single solution in software engineering.
I believe I have demonstrated these this year in several ways:
- the successful collaboration with Build team on the smoke testing is an example of working together to overcome different perspectives as well as using a contract-first approacch to allow both sides to progress their efforts independently.
- challenging myself and the team to not ‘walk past broken windows’ but ask why things are the way they are and whether the reasons that led to it are still valid.
- setting out problems and seeking input on preferred approaches in Slack, or setting up focus conversations around them.
In the mentoring mentioned previously it has often been necessary to consider how best to provide feedback so that it is actionable. Concisely outlining options permits us to recognise when we are making decisions for pragmatic reasons; taking on ’technical debt’ when it makes sense but not doing so unconsciously.
2024-11-27
- need to mention
- holding team to account on quality
- mentoring KA
- alignment of build-release (objective 2) with SDLC
- contract-first collaboration with Build to successfully deliver smoke tests
- planning q about our own missing request specs
- culmination of crtxctl-inspector-captests to be able to react to new questions in a matter of hours and a handful of lines of code.
2024-11-18
Objective 1: We have successfully consolidated the three tools identified (adviser, crtxctl, inspector) into a single integrated tool available through web, command line and api channels. We have clarified that the ‘operations’ repo is used to ‘incubate’ ideas with the successful ones being promoted in due course. We have avoided any other new tools emerging. The number of places to look for data has been reduced. Most questions are answerable from Inspector UI or CLI according to user preference. The other major ones are New Relic and Backstage. Key result is all clusters queriable in one place Additionally… cap tests
Objective 2: The Inspector repo is now vertically integrated with all Inspector code from infrastructure to user interface in that single place. It also has a build system that supports the standard project lifecycle (test, package, verify, publish, deploy) supported by tooling native to the development stack. Furthermore, the same build lifecycle is used within CICD (Github Actions) to minimise the risk of divergent behaviour. TODO Use this for behaviour (accountable)
Objective 3: Progress has been in the form of ruling things out rather than finding a solution to pursue. Existing serverless platforms that build on Kubernetes platform are either defunct (OpenWhisk) or fail to reduce cognitive load (Knative). On the other hand platforms that could reduce complexity (AWS serverless technologies such as Lambda, Step functions and EventBridge) are too far from the skills and culture of the existing organisation to be readily adoptable. Nonetheless, should an opportunity arise in 2025 to work with a Partner on a modernisation programme it would be worth doing so on an early-adopter basis and evaluate the outcome.
2024-10-10
Horizon scanning
Redefine Key metric:
At this stage we have no Partner to validate such an offering.
Roof: Document a proposal for further investigation and share it with CE management to gain buy in.
Moon: Achieve sufficient buy in to develop a proof of concept that caters to the organisations need for applications to ‘just run’, without deep knowledge of how infrastructure is set up.
Domain driven automation pipeline pattern
- realign to SDLC training
- team meeting on 15 Oct
- blog post to present 2 principles
- CICD automates what is already possible manually
- standard lifecycle
- ❓ validate - validate the project is correct and all necessary information is available
- ❌ compile - compile the source code of the project
- ✅ [unit] test - test source code using a suitable unit testing framework. should not require the code be packaged or deployed
- ✅ package - package code in its distributable format, such as a wheel and / or oci image
- ❓ verify - run any checks on results of integration tests to ensure quality criteria are met
install - install the package into the local repository, for use as a dependency in other projects locally- ✅
deploypublish - done in the build environment, copies the final package to the remote repository for sharing with other developers and projects. - ✅deploy - push software to runtime environment
- ❓ accept - run checks on runtime environment
- acceptance test -
- (ref Maven)
- team meeting on 15 Oct
Consolidate ops tooling
- consolidation of Inspector
- formalise contract
- integration of cap tests
- integration with build
- failure to prevent OpsTool and XRay tool
- streamline, next step apparent
- Jira automation drives next step
- removal of prisma (others?) reduces the places to look
- “progress then order”
- spin refactoring of inspector
2024-03-27
Entered into Workday
Objective 3: Horizon scanning
Kubernetes / Cortex provides many advantages including self-healing applications and running heterogenous workloads side by side. However, it still places quite a large responsibility on Partners to understand and adopt the best practices, recent examples include difficulty persuading them to use resource request and limits, choosing the best storage class for a given job and different views on the amount of storage necessary to cache images.. Therefore, there is clearly an untapped demand for an even simpler platform. The obvious candidate is some kind of serverless technology.
Key results
At this stage we have no Partner to validate such an offering. Q2 result will be to define some candidates for further elaboration.
Ideas:
- https://thenewstack.io/state-of-serverless-computing-and-event-streaming-in-2024/
- https://www.antstack.com/blog/top-serverless-platforms-to-look-out-for-in-2024/
2024-03-20
Objective: Consolidate ‘ops tooling’
FG steered away from advisor-crtxctl-inspector?
Lots of little tools have been created to support the work of operations team. They are generally short bash or python scripts, sometimes used directly, sometimes packaged as cronjobs inside k8s. The problem with this is that there is lots of duplication (eg how to connect to GitHub / Jira) and lots of cognitive load in switching between tools that all do things slightly differently (eg parse parameters or fetch data).
Key results
Ideas
- quotidian
- kotidian
- daily
- ops-driver
- opsctl
Alignment: doing more with less, productivity
Rating:
Key results:
Objective: Domain driven automation pipeline pattern
Currently we group projects by technology (eg tio-terraformcontrol-ce) This makes it difficult to navigate dependencies.
Instead, develop a domain-driven, vertically integrated pipeline to keep all related resources together. Kong will be the examplar, but the goal is to develop a pattern
Rating:
Key results:
2024-02 Team brainstorming
- esp. 2 (Capability testing) & 4 (BAU automation)
2024-03-20 Town hall
2024-01-31
- integrate advisor & crtxctl, benefit: jump in visibility / usefulness of Advisor
- deployment pipeline pattern
- prepare (terraform), deploy (helm), verify (capability tests), report (advisor? operations website?)
- cortex bpm