A presentation at NDC Porto by Jessica White
I’ve worked with a number of systems which have been handed over from other developers. These systems, normally being a bit older, often get referred to as “legacy”. I think legacy is a dirty word.
If I were to advertise these systems on something like Gumtree I would probably say something like:
“A pre-loved, vintage system with a lot of its own personality”
Some people put time, effort and love into this system once. They may have had restrictions based on the tech available at the time, external pressures, time pressures, different standards. These unseen circumstances may have had an effect on what was built. Nonetheless, someone put effort into building and maintaining this system at some point.
It may have a few behavioural quirks, but that makes it interesting. It provides you with something to understand and maybe fix.
I think “legacy” removes empathy. Don’t hate these systems. See them as an opportunity to improve an area, have an impact and give whatever system it is the attention it deserves.
These pre-loved systems can be overwhelming and there is a range of problems that will be faced. You might not know where to start with getting these systems into a more stable, resilient and maintainable state.
In this talk, we will go through some of the high-level steps of working with pre-loved systems in the early stages. We will talk through the following stages
One of the difficulties that can be faced when working with different teams, department and pre-loved systems is language. Different words are used for the same things, or certain words can have a different meaning. This can lead to miscommunication and confusion.
The first thing to work out is the ubiquitous language. Make sure that everybody is on the same page. Some people arrange a glossary, others have guided conversations in meetings to assure that language is aligned.
@JessPWhite
@JessPWhite
https://landing.google.com/sre/
@JessPWhite
https://jesswhite.co.uk/2020/04/09/slo-sli-sla-post.html
Defined and measurable expectations of the service for availability and reliability. These are measured by SLIs and sometimes “enforced” by SLAs.
Contracts agreed with consumers, users and other parties determining the consequences of not meeting certain levels of service. These may link to higher-level objectives and are measured by SLIs.
A quantifiable measure of some level of service provided. Help to measure if SLAs and SLOs are met.
Targets for the maximum amount of time a service is unavailable/unreliable in a quarter.
Pizza SLO: 99% of pizzas will be delivered within 4 hours. Pizza SLA: If a pizza isn’t delivered within 4 hours, you will be refunded half the cost. Pizza SLI: Timer from order to delivery.
● Are the current tests automated or manual? ● Do the tests match the expected behaviour? ● Do they match the code? ● Are they maintainable? ● What’s the lightest most effective touch?
● Get an overview ● Prioritise ● Measure ● Communicate ● Be ready for failure
No software system is perfect. Deep down we all like that because it keeps things interesting, but what do you do when your system is further away from perfection than you’re comfortable with? It may be you are dealing with a legacy monolith or a system that has strange logic, no documentation and hardly any conventions you can recognise. Everything seems to be on fire and you need to stabilise the situation.
We’ll explore some techniques that are useful when working on systems that need a little love. At a high-level, we will go through approaching testing, monitoring, re-architecting and documenting these systems. We will also go through prioritisation when everything is urgent and the non-technical metrics that can help with buy-in for stabilising your system and team.
This talk is an intermediate level talk. The aim is for you to not only learn how to deal with these situations but want to tackle the challenges they present and be excited about the change you can lead.
The following resources were mentioned during the presentation or are useful additional information.
A post by Jessica White going through Service Level Objective, Agreements and Indicators at a high level.
A post exploring RED, USE and the Four Golden Signals
You’ve been working in an organisation that has seen the light of automated testing. You work in a cross-functional team bringing ops, dev, product, user research, content, testing and many other concerns together in harmony. You have iterated through a model greenfield project, have good test coverage and have obeyed the mantra of the testing pyramid. Just a few months down the line why is it so hard to change things? Why are people questioning the value of your tests? Confidence is dropping. During this talk, we will cover an overview of different levels/types of testing but specifically looking at the value they provide to developers and others maintaining software. We will use this information to challenge some conventional thinking and re-balance how confidence in our software is gained without harming its ongoing maintenance. This talk is suitable for people with exposure to automated testing methods who want to understand a balanced view of creating a sustainable test strategy through to production and beyond.
In their description of microservices James Lewis and Martin Fowler noted that: “The microservice approach to division is different, splitting up into services organized around business capability” But what is a business capability? How do you find them? And why does orienting a microservice around them make a difference.
In this session we will try to shed some light onto the black art of building a business capability map, and how you can use that to define the boundaries of your microservices. We will also look at ideas such as the Inverse Conway Manoeuvre and Products not Projects that enable greater agility and product velocity through the alignment of microservices and capabilities.
Finally, we will look at how some technical concerns, such as integration can be soothed by better understanding how a capability map gives you more effective boundaries.
Develop faster with DevOps DevOps embraces a culture of unifying the creation and distribution of technology in a way that allows for faster release cycles and more resource-efficient product updating. DevOps For Dummies provides a guidebook for those on the development or operations side in need of a primer on this way of working. Inside, DevOps evangelist Emily Freeman provides a roadmap for adopting the management and technology tools, as well as the culture changes, needed to dive head-first into DevOps. Identify your organization’s needs Create a DevOps framework Change your organizational structure Manage projects in the DevOps world DevOps For Dummies is essential reading for developers and operations professionals in the early stages of DevOps adoption
Here’s what was said about this presentation on Twitter.
for free. You
can too.