Poor user experience - or DevOps and definitely no SRE.

 In my continuation to find examples of where software systems have not moved beyond the SDLC of the 1980s and 90s, or have started doing DevOps, but haven't realised that now we're in to SRE, and if you think SRE is DevOps, then there's a problem.

DevOps = Automation, implement the new features, make sure it's reliable and stable, make sure "we" can fix an issue when it occurs.

Right, you probably think that includes SRE because you're thinking about the client/stakeholder, but how do they (the client) know if the problem is them or you?

So many organisations don't provide enough information to a client when they have an issue, either through an update, or an outage of some kind.

SRE requires our understanding of the user, not just in how they use the application, but making sure they don't have to be technical. It's not down to the user to uninstall and re-install the application and then have to log back in - that to a non-technical user is the biggest "bug bear" you could ask them to do. We're now in the 21st century and if you're a large organisation with lots of clients, should be able to think more about your customers experience. Yes, SRE has some nice principles for determining whether the user is experiencing a degradation in performance, or whether developers should be focusing on reliability rather than new features. BUT we should still be thinking, are we putting too much on the end user and assuming that they are comfortable in re-installing, or want keep putting in their password every week?

These are areas that we should be thinking about if we want to make our software more exceptional than the competition. If you can provide the experience to users that saves them logging in every 5 minutes, or having to re-install manually, then you're moving into a whole new area of customer satisfaction.

Today's poor practice;

Southern Water's application that 1000s of sea and river swimmers rely on at this time of year due to the amount of sewage discharges they do, even in non-extreme weather conditions is out for the entire day - see the picture attached.

https://riversandseaswatch.southernwater.co.uk/release-history?BathingSite=FOLKESTONE&Status=Genuine

Yesterday Tennis TV had performed an update without checking the client applications, causing the App to just quit with no warning messages - this in turn causing the user to become frustrated and panic.

Don't slip back to the 1970 and 1980s method of customer support and hide behind the Internet and ChatBots (in the 70s and 80s it was the phone), and not provide adequate information to the users. Today there are many practices and tooling that we should not be seeing this type of service as users.

Step in to the 21st century and start using DevOps environments to test your updates and upgrades for both application and infrastructure before deploying to LIVE. Ensure that your pre-Live environments have at least 1 of every resource so that there is NOTHING NEW when you deploy to LIVE.

TESTING is not a last minute options, it's a before you code to ensure you met requirements, and that you don't write code to suit the tests (1980s and 90s).

Provide meaningful error messages to your users, don't fail SILENT!

Why you should NOT run Docker containers as root

Why a Docker container should never run as root!

Most organisations ensure that you need to have sudo access to run the Docker commands on your systems, but even if you're using Kubernetes or OpenShift, or if you have added users to the docker group you run the risk of being compromised.

As a simple demonstration try out the following steps that would expose your /etc/shadow file to a docker container ran by an ordinary user;

1. Make sure your ordinary user is added to the docker group:

       sudo usermod -G docker steve

2. If you are logged in as that user you will need to log out and back in for the group to take affect

3. Check the user can run the docker command:

       docker ps

    You should see the docker ps header and any running containers on that system

4. Now let's cat the /etc/shadow file using a container from Docker Hub:

       docker run -it --rm -v /etc:/hack python:3.12 cat /hack/shadow

5. You'll notice that what you will be looking at is your hosts shadow file and not the shadow file in the container since that is in /etc/shadow.

If you're not doing the following to secure your environment then you will be at risk of people being able to crack the root password on your systems.

1. Create and use only your own organisations private Docker registry

2. Block access to docker.io, public.ecr.aws, quay.io, and any other public repositories you know of.  Access to these should only be allowed by those who will be building the base container images for your organisations

3. Any base images downloaded from the registries in 2 should be built as new images that run with a specific user ID greater than 1000.

4. If developers need to install software onto containers then this should be performed in the developer environments only, or through CI pipelines which perform the root level installs and then add the user to the end of the build.

Root running containers should only be used where software needs to be installed that the basic user cannot, which is why it is important to have the necessary base images available for developers so that they only need worry about their code and libraries.