DevOps Showcase North: DevOps and Microservices

Summary

Jovile
Published by
Jovile Bartkeviciute (@jovilebart)
PUBLISHED: February 23, 2017 3:46 pm
ESTIMATED READING TIME: 11 MINUTES

IMG_4376

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.

IMG_4384

 

 

 

 

 

 

 

 

 

 

 

Here is a quick summary of the talks I managed to catch:

IMG_4388

 

 

 

 

 

 

 

 

 

 

 

 

“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:

IMG_4397

 

 

 

 

 

 

 

 

 

  • Agile and DevOps are here to stay:
    • Responsiveness to customer needs
    • Tool support for all processes
    • Focus on people and good communication

Useful links:

 

IMG_4403

 

 

 

 

 

 

 

 

 

 

“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
  • 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:

 

 

IMG_4410

 

 

 

 

 

 

 

 

 

 

 

“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

 

IMG_4414
“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.

 

IMG_4430

 

 

 

 

 

 

 

 

 

 

 

 

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

 

IMG_4437

 

 

 

 

 

 

 

 

 

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
  • 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:

 

IMG_4466

 

 

 

 

 

 

 

 

 

 

 

 

“The Seven (More) Deadly Sins of Microservices” – Daniel Bryant (@danielbryantuk), Chief Scientist at OpenCredo and CTO, SpectoLabs
The sins:

  1. Lust – using an (unevaluated) latest and greatest tech
    1.  Need to evaluate if microservices are a good fit
    2. Beware of confirmation bias!
  2. Gluttony – communication lock-in
  3. Greed – what’s mine is mine (within the organisation)
    1. microservices are about people, as much as they are tech
  4. Sloth – getting lazy with NFRS
  5. Wrath – blowing up when bad things happen
  6. Envy – the shared single domain fallacy
  7. Pride – testing in the world of transience

 

IMG_4467

 

 

 

 

 

 

 

 

 

 

 

 

 

 

“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
  • 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!

logo

 

 

 

 

Comments