This post was written by Jovile Bartkeviciute.
This Tuesday I had an opportunity to attend DevOps Showcase North conference in Manchester. The event was organised by UNICOM and was co-located with 2 other conferences – Testing Showcase North and Agile Showcase North. Due to the unique conference format, all keynotes were held together in a joint morning session and attendees had a chance to listen to the leading experts in all three fields, while the afternoon was split into separate tracks.
The conference was chaired by Matthew Skelton, our co-founder and principal consultant, who opened the event.
Here is a quick summary of the talks I managed to catch:
“Testing, Agile and DevOps – their roots and evolution” – Dorothy Graham (@DorothyGraham), Software testing consultant, speaker and author
Dorothy took us down the memory lane and reminded us that a lot of current “new” ideas actually been there for awhile, just were waiting for their own time to shine. Some key points:
- Previously, testing was not a desirable career move, however, nowadays it is popular and respectable.
- Nowadays, agile is a flavour of the month, most people would not admit that they are not doing agile.
- Previously, similarly to agile now, you could not admit you do not have a quality management system – waterfall was all the rage.
- From programmer to software engineer – suddenly the position changed the name as it was more fashionable
- Grandfather of DevOps and Agile: Tom Gilb. Agile manifesto was inspired by his ideas.
- Automation is necessary, but not sufficient: “Automated chaos is just faster chaos” – from Cast Report (1991)
- “If you do not know what you are doing, don’t do it on a large scale” – Tom Gilb, POSEM (1988)
- Evolutionary Delivery (Evo) vs DevOps:
- Agile and DevOps are here to stay:
- Responsiveness to customer needs
- Tool support for all processes
- Focus on people and good communication
Useful links:
“How to break apart a monolithic system safely without destroying your team” – Matthew Skelton (@matthewpskelton), Co-founder and Principal Consultant, Skelton Thatcher Consulting Ltd
Key points:
- We aim for safer, more rapid changes to software systems – gives us business agility.
- Conway’s law – organisations are producing designs which are copies of the communication structures, Reverse Conway’s law – you can change your organisation’s structure to match the structure of the system’s that you want.
So, to break apart a monolithic without destroying your team, you need to: determine the monolith type, apply code forensics, find fracture planes, assess cognitive load for teams and use the monolith-splitting recipe:
- Cognitive load for teams
- Cognitive load – the total amount of mental effort being used in the working memory
- Stress impacts team performance by narrowing or weakening the team level perspective, if they have too much to consider, they’ll cease to perform as a team.
- A well-performed team performs better than a group of well-performing individuals.
- ‘Monolith’
- Monolithic thinking – assuming that one-size-fits-all for teams, assumption that minimising variation is a good thing.
- Dangers of splitting a monolith:
- Reduced domain consistency, unintentional data duplication, additional operational complexity due to distributed system and async messaging, degraded UX across the product
- Choose the right technique and understand the nature of the monolith
- Code Forensics
- “Your Code as a Crime Scene” – Adam Tornhill
- Code, Crime, Complexity: Analysing software with forensic psychology
- Team-first boundaries
- devopstopologies.com
- You can use a monorepo only if your organisation has published a scientific paper on Computer Science. Otherwise, use one repo per deployable runnable thing.
- Find natural ‘fracture planes’ for splitting a monolith with the team in mind.
- Monolith-splitting recipe:
- Instrument the monolith – logging
- Grok data flows and fault responses
- Align teams to available segments
- Split off segments one-by-one
- (Invest in Build & Release Engineering)
Slides:
“Microservices: The tip of the iceberg” – Giovanni Asproni (@gasproni), Lead Consultant, Zuhlke Engineering Limited
Key points:
- What do we hope to get from microservices? – flexibility of delivery, flexibility of deployment, flexibility of response, flexibility of implementation. (flexibility of employment?)
- “There ain’t no such thing as a free lunch”, microservices have drawbacks as well.
- What could go wrong? – surprising failure modes, additional complexity due to distribution, mistakenly shared resources, one service to rule them all.
- Make sure your microservices are not just a monolith in disguise.
- When should you use microservices? – When you are ready as an engineering organisation.
- When adopting microservices, first:
- Know why you are doing microservices
- Adopt incrementally
- Avoid premature structure
- Invest in tooling and support
- Align organisational structure
“Agility not Agile: the challenge ahead” – Amany Elbanna, Senior Lecturer in Information Systems, Royal Holloway University of London
Key points:
- Theory says – any system would flourish when exercising their own creativity.
- When people have performance measurements, they will work towards the measurements, not the goal.
- The time we “save” in development – we waste in operations
- You need to have in mind, that the team who started the project will be a different team, than the one who will be working on it later.
- In a typical system, 45% of features and functions are never used.
- Agile business is a different story from an agile team.
- Businesses do not care if you adopt agile successfully, they need results.
“DevOps: Changing Culture: (Tips, tricks & transforming)” – Stephen Walters (@rathgorn), Software Lead Solution Consultant, HPE
5 tips and tricks:
- Start with why – Simon Sinek
- To be agile, think agile
- How do you want to transform? Set your deadline, set your constraints. Then you will become vision driven.
- Deliver What
- Cultural backlog
- Think big, start small
- IT4IT – an open standard for running the business of IT
- Journey to value – accelerate customer outcomes – advise, transform, manage
- Using a 3rd party
- Advantages: culturally agnostic, previous experience, re-use of solutions, arbitration, minimises BAU disruption, customised training, IT4IT organisation.
- Beware of: partnership, own the requirements, governance & visibility, vendor tie-in, complete handover, value driven delivery, technology agnostic.
Case Study: The Forgotten ‘llity’ – Ash Winter (@northern_tester), Principal Test Engineer, Sky Betting and Gaming
Key points:
- “Testers often don’t get it” – paradigm, opportunity, narrowness.
- Initially, they had a big shopping list:
- Live Environment
- Local Environment – you actually need something that you control – better to have local environment
- Fix the Past
- The past is a foreign country – missing intent
- Team Learning – the system was undeployable, the learning the team went through to deploy really brought the team together
- Log all things
- Log what matters only – bloating, spam first, include external, understand log levels
- Learn PHP
- Actually learned PHP
- Live Environment
- Know thy neighbour:
- You need to be aware of adjacent testability, need to know adjacent systems – they need to be testable as eventully you will need to test the totality
- Mockeries are important and need to be realistic
- Operations, Operations, Operations!
- Testers need to know what operations are doing, get to know their pain,
- Need to talk less about more persistent environments, time machines, ‘big’ testability and more about flow feedback and time to recovery.
- Upcoming book: “Team Guide to Software Testability”
Slides:
“The Seven (More) Deadly Sins of Microservices” – Daniel Bryant (@danielbryantuk), Chief Scientist at OpenCredo and CTO, SpectoLabs
The sins:
- Lust – using an (unevaluated) latest and greatest tech
- Need to evaluate if microservices are a good fit
- Beware of confirmation bias!
- Gluttony – communication lock-in
- Greed – what’s mine is mine (within the organisation)
- microservices are about people, as much as they are tech
- Sloth – getting lazy with NFRS
- Wrath – blowing up when bad things happen
- Envy – the shared single domain fallacy
- Pride – testing in the world of transience
“The Automated Docker Container Deployment Pipeline” – Jussi Nummelin (@JNummelin), Resident Wharfie, Kontena
Jussi talked about containers and run a live demo on deployment of a CI/CD pipeline using container management. Key points:
- Why use containers? – efficient use of resources, application portability.
- Why should you care about agility?
- There will be somebody going faster than you, so you need to keep up with the competition in order not to lose your customers
- Containers benefits: reduced risk, believable process
- Misconceptions:
- Containers are no magic bullet
- Containers don’t build CD themselves
- You can do CD without containers
- Misconceptions:
- Truth:
- Containers do not build anything for you, but they can help
- More controlled packaging
- Environment parity
- Script everything, version control everything, yes, everything! (Everything but secrets)
To sum up, the talks were informative, useful and entertaining. One of the repeating themes was about finding your ‘why’ – finding the reason why you would wish to adopt one or the other technology. Quite a few speakers have talked about the business side of things and business agility as well as teams, DevOps Topologies have been mentioned a few times too.
Looking forward to DevOps Showcase North next year and other UNICOM events!
Skelton Thatcher 