10 travel tips you might not read elsewhere.

May partner and I have been on the road for around 9 months now, travelling around Europe and South East Asia, and I’ve learned a few things about myself, the world, and how to travel. Some things are obvious, like how important it is to have decent travel insurance, buying local pay-as-you-go sim cards instead of racking up a big roaming bill, and setting some sort of spending budget…

However, here are ten tips (and a few bonus ones) that you might not read on the average travel blog.

Vietnamese lizard
  1. Everything breaks, so get good at fixing stuff, and learn to sew. Pack superglue, electrical tape, and a small sewing kit, and you can fix just about anything. I’ve repaired shoes, shorts, sleeping bags, watches, sunglasses, bags and cameras over the past few months.
    Repair on a sleeping bag.

    Sugru is also a great resource, but each pouch has to be used immediately once it’s opened, so take some, but use it as a last resort. And seriously, learn some basic sewing skills, like darning socks, sewing on buttons, or repairing rips and tears.

    solar charger, water purifier, backpack
    Halfway up to Annapurna base camp
  2. A good first aid kit is crucial. Stock up on antiseptic, plasters, bandages, bite cream, water purifying tabs, tweezers and anything else you might need personally. I even took some emergency tooth filling repair stuff, and I used it. You can also use superglue to patch up wounds, but be careful as it can get very hot when it dries, and the standard stuff sets stiff so it’s not good for cuts over skin that moves, like the soles of your feet.
    Kathmandu, Nepal

    Zinc oxide tape is great to prevent blisters and secure bandages. Electrical tape serves as a superb fix for a wound dressing if you’re going to get it wet. I cut my toes fairly badly while cliff jumping (whilst climbing up, not jumping down) and used bandages and electrical tape for a couple of weeks to keep it bandaged while in the sea.

    Cliff jumping in Vietnam
    Kayaking and paddle boarding in Vietnam

    Also stock up medicine when possible. Painkillers aren’t always available and you can go through them quicker than you’d expect. Take with you antihistamines, sleeping pills, anti-diarrhoea and rehydration salts. If you can, get some antibiotics like amoxicillin for general wound or tooth infections, and metronidazole for stomach bugs  and amoebic nasties.

    Our trekking guides, Santosh and Puskar

    If you find yourself somewhere like Nepal where you can get antibiotics over the counter, buy some. Buy more than you think you need (but not so many that you’ll be thrown in jail for smuggling prescription drugs). If you get an infection and you’re in deepest Cambodia, you really don’t want to leave it until you can find a reliable doctor.

    Walking in the Himalayas

    Buy hand sanitiser when you can find it cheaply, because it gets expensive when you’re remote. You’ll probably acclimatise to the local stomach bugs eventually, but using hand sanitiser regularly will reduce the likelihood of getting a bad one. I wasn’t careful enough in our first week in Kathmandu, and after vomiting in the street, and a very tense taxi ride, rather regretted it.

    Pub Street, Siem Reap, Cambodia
  3. Get a decent knife and learn how to use it and look after it properly. Buy one that locks open so that you don’t cut your fingers off when closing it. Keep it sharp using a decent stone or steel. Sharpening a blunted knife is really difficult, but keeping a knife sharp just takes a bit of discipline. I carried around a stone in my bag for 8 months just for this purpose. You’ll use your knife for everything from preparing food, repairing clothes, and cutting hair!

    Look after your knife.
  4. Eat local food whenever possible. Some of the most amazing food I’ve had travelling has been in the cheapest street stalls and markets. However, good local food isn’t always available. You’ll often find yourself forced to eat whatever is provided, and it might not be to your (or frankly, anyone’s) taste. Tabasco sauce can make all sorts of bland, weird, slightly off, or otherwise less-than-great food palatable. Take a little bottle of your your own with you, and even carry a few spices, salt, pepper, and sugar.
    Nepalese street food on the road to Pokhara.

    Cambodian market food
  5. Keep your hip flask topped up. I recommend whisky because it’s drinkable by itself and goes well mixed with lots of stuff from coke to coffee, gin is pretty nice to carry around but good luck finding tonic in rural SE Asia. Cognac could work for you if you’re an artist or something. Vodka if you’re doing the whole serious alcoholic thing. When you get invited to an impromptu beach party, or a chillout on a porch, you’ll be pleased you’ve got your old faithful hip flask with you.

    Chilling in Lisbon
  6. Buy a bunch of dry bags of different colours and sizes. You can almost never have too many dry bags. They’re really useful for simply keeping your kit organised and separated, so you’re not hunting around for your socks every day or wondering where your favourite big-night-out T-shirt is. It also means that if your bag gets wet or something springs a leak inside, most of your stuff will be ok. I used a big red one to keep dirty washing in (red for danger, obvs), and also used various dry bags for trips to the beach, backpacking in the rain, or kayaking trips. 

    Unpacking along the Annapurna Trek
  7. Be careful using squat toilets. In many parts of Asia, you’ll come across squat toilets. Once you get used to them, they’re actually pretty good, as long as they’re kept reasonably clean. However, make sure you zip up your pockets if possible, or at least put your phone and wallet somewhere else when you’re using a squat toilet. If something falls out, you really don’t want to be rummaging around down there, however fancy and expensive your phone is. 

    Riding around Koh Chang, Thailand.
  8. When travelling, if there are seatbelts, wear them. The same goes for helmets whilst riding motorbikes. It’s cool to be safe, kids. Driving standards outside Europe and the US are significantly lower, and in many places there’s not even a requirement to pass a test in order to drive on public roads. Our coach from Kathmandu to Pokhara overturned after having to avoid a speeding car on the wrong side of the road who’d miscalculated an overtake. We were fine, as was everyone in the coach apart from our Annapurna guide, who smacked his knee hard. We were lucky, but it could have been much worse.
    Everyone was fine, fortunately.

  9. Wear synthetic underwear. Seriously. If you’re walking a lot, or spending a lot of time in hot and humid conditions, you don’t want to be wearing cotton underwear, because they absorb water and will at best be very uncomfortable, and worst cause such severe chafing that you can barely move, or it gets infected. Synthetic underwear doesn’t absorb water, so it’s way more comfortable, particularly for trekking and/or humid weather. It’s also great for impromptu outdoors swimming, because your pants will dry quickly and frankly they’re also less transparent when wet than cotton pants…
    Swimming in cold water in El Bosque, Andalusia.

    Snorkelling in Thailand.
  10. Go offline. Going off-grid can be a great experience, especially if it’s for a decent amount of time. If you get a chance to get out into the wilderness, the mountains, or out to sea, then use that opportunity to go fully offline and away from the distractions of modern life. We went off-grid for about 12 days on our trek to Annapurna Base Camp, and it made an amazing experience even better.
    Prayer flags at Annapurna base camp

    Although initially you might suffer from bad FOMO, or fear that your parents and friends might worry if they don’t hear from you (by the way, you should probably tell people you’re going offline lest they spark an international manhunt), after a few days you’ll feel back in touch with the real world a little more, maybe feel a bit more calm, and able to be more present in the moment. You might even find that after a week or two of being off-grid, you really don’t want to reconnect after all.

    Taking the night train to Saigon
Jade relaxing on a snorkelling trip in Thailand

Finally, here’s a few bonus tips that didn’t quite make it to the top ten:

  • Shower gel is a fine alternative to washing machine detergent. Just don’t use too much.
  • Toilet paper is valuable stuff, always keep some with you, especially on a mountain trek. A roll of toilet paper can cost the same as a night’s accommodation high up in the mountains.

    The Himalayas at sunrise
  • Always carry snacks, because you will definitely find yourself in places or on journeys for considerable lengths of time with no access to food. Individually wrapped cereal bars are great. Try to avoid things that melt.
  • Take digital photos of your passport and other important documents, in case you lose them, or in case you need to show them to someone but don’t have the documents on you.
Putting our feet up during a Himalaya trek.
  • Take rechargeable batteries for torches and other gear, and a charger for them. 
  • Learn to open beer and wine bottles without openers. Don’t use your teeth. 

    Mucking about (fallen angel pose) in Lisbon.
  • Carry some US dollars for emergencies. Almost everywhere accepts them as currency, or at least to change them. They’re often essential to pay for visas at the border around SE Asia too.
  • If it’s within your budget (or someone else’s), get yourself a proper adventure camera. Jade bought me the amazing Olympus Tough TG-5, which is waterproof, drop-proof, and packed with features.

    Olympus TG5 camera.
  • Get a Curve card. It’s a Mastercard, so it’s accepted nearly everywhere, and you can use it instead of your credit and debit cards, so you can keep them safe somewhere and only expose your Curve card to potentially risky ATMs and restaurant owners. Curve also converts currencies for you, saving you money on fees. Shameless promo: sign up for Curve here with code NPWZA and you’ll get £5, and so will I.
  • Take a tablet or laptop with you in order to work, research and book travel, or simply watch Netflix. We spent many, many hours on shonky wifi connections from nearby cafes watching Anthony Bourdain on Netflix. Try to download stuff to watch or listen to later if you know wifi might be patchy.

    Lemon tree in Prado Del Rey, Andalusia
  • Practise mindfulness and meditation; you’ll many have periods of time when all you can do is sit and wait, so you may as well put it to good use, and you can continue to practise when you’re back in the “real” world. If you’re new to it or prefer a little guidance, there are some great apps out there for meditation practice, such as Headspace.
Getting to Annapurna base camp

Travelling is very much about experiencing abstract, intangible things. Meeting new people, seeing different parts of the world, experiencing other cultures, eating different food and finding ways to be at ease with discomfort such as sleeping in bad beds or walking for hours with a heavy pack on your back.

Don’t worry about buying souvenirs. They’re just added weight. Take photos, record the sounds, make memories and friends.

Vietnamese fishing boats

As Bourdain says: “It seems that the more places I see and experience, the bigger I realise the world to be. The more I become aware of, the more I realise how relatively little I know of it, how many places I have still to go, how much more there is to learn.

Wild swimming in a pool in Koh Chang, Thailand.
Jade at Ninh Van Bay, Vietnam.
Getting bamboo tattoos in Thailand
Barcelona beach

Leave a comment with any travel tips you have.

Why the UK Porn Block is an Awful Idea

From 15 July 2019, the UK’s age verification system for online pornography will become mandatory. Here’s why it’s a terrible idea.

  1. It actually doesn’t block much porn at all. It only applies to commercial porn, which you need a credit card to access anyway, and children generally don’t have credit cards. It doesn’t apply to porn on social media, free sites, or P2P sharing, which is much easier to access.
  2. It will likely do more harm than good. It may provide many parents with a false sense of security that their children can no longer access porn online, resulting in a lower emphasis being placed on parents properly managing their childrens’ internet access. Parental controls on home wifi, home computers, and mobile devices are widely available and relatively easy to use.
  3. It plays into the hands of the big commercial porn providers. The main age verification system (AgeID) is owned by the same company that runs the most popular and lucrative porn websites in the world. The largest porn company in the world is being tasked with controlling access to porn. Already, some smaller businesses in the realms of ethical porn and feminist porn have shut down because implementation of this system is too expensive for them. If we’re going to have porn on the internet (and who are we kidding, there will always be porn on the internet), do we want it controlled by one big US firm?
  4. It has serious privacy implications. The age verification systems will contain the personal information and erotica browsing history for every adult who’s ever wished to access online porn from July onwards. If (or more realistically, when) this database is breached, it will be a treasure trove for identity thieves and blackmailers.
  5. It just won’t work. Technologically, it’s easy to bypass the system. Because it only applies to the UK, a simple VPN to break out to a different country will easily and cheaply circumvent most controls. At the same time, as has been seen in China, India and other authoritarian regions, consumers simply switch to other channels, such as torrenting, social media, newsgroups (yes, they’re still a thing), and the dark web.
  6. It’s based on flawed evidence. Whilst there’s anecdotal evidence that children “stumble across” online porn, there’s very little evidence that they access commercial porn sites, particularly when parents make some effort to manage internet access. The main study cited as the catalyst for the Act “found” that “almost a tenth of all 12- to 13-year-olds thought they were “addicted” to pornography”, and was carried out by OnePoll, the same people who generate such hard-hitting research as “German men are the world’s worst lovers” and “Fifty percent of British adults think Mount Everest is in the UK“. There is evidence that children access porn online, and some evidence that it’s harmful, and some that it isn’t as harmful as you’d think. Whichever way it’s cut, this age-verification approach is not evidence-based.
  7. It’s censorship and control. It provides a mechanism for the government to monitor online activity and decide what content is acceptable or unacceptable for the population to access, and change this definition as they see fit. The terms in the act even include the ability to block “material other than the offending material”. We may trust today’s government (though do you, really?), but we’d be foolish to implicitly trust future governments not to extend the controls to other content. As the award-winning English lawyer Myles Jackman put it, “Pornography is the canary in the coal mine of free speech: it is the first freedom to die. If this assault on liberty is allowed to go unchallenged, other freedoms will fall as a consequence.”

Technologically, this approach is fundamentally flawed, is unlikely to work at all, and creates some worrying implications for digital identity and privacy in the hands of large US corporations.

Using Hugo and AWS to build a fast, static, easily managed and deployed website.

Most of my websites are built using WordPress on Linux in AWS, using EC2 for compute, S3 for storage and Aurora for the data layer. Take a look at sono.life as an example.

For this site, I wanted to build something that aligned with, and demonstrated some of the key tenets of cloud technology – that is: scalability, resiliency, availability, and security, and was designed for the cloud, not simply in the cloud.

I chose technologies that were cloud native, were as fast as possible, easily managed, version controlled, quickly deployed, and presented over TLS. I opted for Hugo, a super-fast static website generator that is managed from the command line. It’s used by organisations such as Let’s Encrypt to build super fast, secure, reliable and scalable websites. The rest of my choices are listed below. Wherever possible, I’ve used the native AWS solution.

The whole site loads in less than half a second, and there are still improvements to be made. It may not be pretty, but it’s fast. Below is a walk through and notes that should help you build your own Hugo site in AWS. The notes assume that you know your way around the command line, that you have an AWS account and have a basic understanding of the services involved in the build. I think I’ve covered all the steps, but if you try to follow this and spot a missing step, let me know.

Notes on Build – Test – Deploy:

Hugo was installed via HomeBrew to build the site. If you haven’t installed Homebrew yet, just do it. Fetch by running:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Then install Hugo:
brew install hugo

One of the things I love about Hugo is the ability to make rapid, on-the-fly changes to the site and see the result instantly, running the Hugo server locally.

hugo server -w -D

The option -D includes drafts in the output, whilst -w watches the filesystem for changes, so you don’t need to rebuild with every small change, or even refresh in the browser.

To create content, simply run

hugo new $postname.md

Then create and edit your content, QA with the local Hugo server, and build the site when you’re happy:

hugo -v

V for verbose, obvs.

You’ll need to install the AWS CLI, if you haven’t already.

brew install awscli

Check it worked:

aws --version

Then set it up with your AWS IAM credentials:

aws configure
AWS Access Key ID [None]: <your access key>
AWS Secret Access Key [None]: <your secret key>
Default region name [None]: <your region name>
Default output format [None]: ENTER

You don’t need to use R53 for DNS, but it doesn’t cost much and it will make your life a lot easier. Plus you can use funky features like routing policies and target health evaluation (though not when using Cloudfront distributions as a target).

Create your record set in R53. You’ll change the target to a Cloudfront distribution later on. Create the below json file with your config.

{
            "Comment": "CREATE/DELETE/UPSERT a record ",
            "Changes": [{
            "Action": "CREATE",
                        "ResourceRecordSet": {
                                    "Name": "a.example.com",
                                    "Type": "A",
                                    "TTL": 300,
                                 "ResourceRecords": [{ "Value": "4.4.4.4"}]
}}]
}
And run:
aws route53 change-resource-record-sets --hosted-zone-id ZXXXXXXXXXX --change-batch file://sample.json

Create a bucket. Your bucket name needs to match the hostname of your site, unless you want to get really hacky.

aws s3 mb s3://my.website.com --region eu-west-1

If you’re using Cloudfront, you’ll need to specify permissions to allow the Cloudfront service to pull from S3. Or, if you’re straight up hosting from S3, ensure you allow the correct permissions. There are many variations on how to do this – the AWS recommended way would be to set up an Origin Access Identity, but that won’t work if you’re using Hugo and need to use a custom origin for Cloudfront (see below). If you don’t particularly mind if visitors can access S3 assets if they try to, your S3 policy can be as below:

{
  "Version":"2012-10-17",
  "Statement":[{
	"Sid":"PublicReadGetObject",
        "Effect":"Allow",
	  "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::example-bucket/*"
      ]
    }
  ]
}

Request your SSL certificate at this time too:

aws acm request-certificate --domain-name $YOUR_DOMAIN --subject-alternative-names "www.$YOUR_DOMAIN" 

ACM will automatically renew your cert for you when it expires, so you can sleep easy at night without worrying about SSL certs expiring. That stuff you did last summer at bandcamp will still keep you awake though.

Note: Regards Custom SSL client support, make sure to select ONLY SNI. Supporting old steam driven browsers on WinXP will cost you $600, and I don’t think you want that.

The only way to use https with S3 is to stick a Cloudfront distribution in front of it, and by doing this you get the added bonus of a super fast CDN with over 150 edge locations worldwide.

Create your Cloudfront distribution with a json config file, or straight through the cli.

aws cloudfront create-distribution --distribution-config file://distconfig.json

Check out the AWS documentation for details on how to create your config file.

Apply your certificate to the CF distribution too, in order to serve traffic over https. You can choose to allow port 80 or redirect all requests to 443. Choose “custom” certificate to select your cert, otherwise Cloudfront will use the Amazon default one, and visitors will see a certificate mismatch when browsing to the site.

When configuring my Cloudfront distribution, I hit a few issues. First of all, it’s not possible to use the standard AWS S3 origin. You must use a custom origin (specifying the region of the S3 bucket as below in order for pretty URLs and CSS references in Hugo to work properly. I.e.

cv.tomgeraghty.co.uk.s3-website-eu-west-1.amazonaws.com 

instead of

cv.tomgeraghty.co.uk.s3.amazonaws.com

Also, make sure to specify the default root object in the CF distribution as index.html.

Now that your CF distribution is ready, anything in your S3 bucket will be cached to the CF CDN. Once the status of your distribution is “deployed”, it’s ready to go. It might take a little while at first setup, but don’t worry. Go and make a cup of tea.

Now, point your R53 record at either your S3 bucket or your Cloudfront disti. You can do this via the cli, but doing it via the console means you can check to see if your target appears in the list of alias targets. Simply select “A – IPv4 address” as the target type, and choose your alias target (CF or S3) in the drop down menu.

Stick an index.html file in the root of your bucket, and carry out an end-to-end test by browsing to your site.

Build – Test – Deploy

Now you have a functioning Hugo site running locally, S3, R53, TLS, and Cloudfront, you’re ready to stick it all up on the internet.

Git push if you’re using Git, and deploy the public content via whichever method you choose. In my case, to the S3 bucket created earlier:

aws s3 cp public s3://$bucketname --recursive

The recursive switch ensures the subfolders and content will be copied too.

Crucially, because I’m hosting via Cloudfront, a new deploy means the old Cloudfront content will be out of date until it expires, so alongside every deploy, an invalidation is required to trigger a new fetch from the S3 origin:

aws cloudfront create-invalidation --distribution-id $cloudfrontID  --paths /\*

It’s not the cleanest way of doing it, but it’s surprisingly quick to refresh the CDN cache so it’s ok for now.

Time to choose a theme and modify the hugo config file. This is how you define how your Hugo site works.

I used the “Hermit” theme:

git clone https://github.com/Track3/hermit.git themes/hermit

But you could choose any theme you like from https://themes.gohugo.io/

Modify the important elements of the config.toml file:

baseURL = "$https://your-website-url"
languageCode = "en-us"
defaultContentLanguage = "en"
title = "$your-site-title"
theme = "$your-theme"
googleAnalytics = "$your-GA-UA-code"
disqusShortname = "$yourdiscussshortname"

Get used to running a deploy:

hugo -v
aws s3 cp public s3://your-site-name --recursive
aws cloudfront create-invalidation --distribution-id XXXXXXXXXX  --paths /\*

Or, to save time, set up npm to handle your build and deploy. Install node and NPM if you haven’t already (I’m assuming you’re going to use Homebrew again.

$ brew install node

Then check node and npm are installed by checking the version:

npm -v

and

node -v

All good? Carry on then:

npm init

Create some handy scripts:

{
    "name": "hugobuild",
    "config": {
        "LASTVERSION": "0.1"
    },
    
    "version": "1.0.0",
    "description": "hugo build and deploy",
    "dependencies": {
        "dotenv": "^6.2.0"


    },

    "devDependencies": {},
    "scripts": {
        "testvariable": "echo $npm_package_config_LASTVERSION",
        "test": "echo 'I like you Clarence. Always have. Always will.'",
        "server": "hugo server -w -D -v",
        "build": "hugo -v",
        "deploy": "aws s3 cp public s3:// --recursive && aws cloudfront create-invalidation --distribution-id  --paths '/*'"
    },
    "author": "Tom Geraghty",
    "license": "ISC"
}

Then, running:

npm run server

will launch a local server running at http://localhost:1313

Then:

npm run build

will build your site ready for deployment.

And:

npm deploy

will upload content to S3 and tell Cloudfront to invalidate old content and fetch the new stuff.

Now you can start adding content, and making stuff. Or, if you’re like me and prefer to fiddle, you can begin to implement Circle CI and other tools.

Notes: some things you might not find in other Hugo documentation:

When configuring the SSL cert – just wait, be patient for it to load. Reload the page a few times even. This gets me every time. The AWS Certificate manager service can be very slow to update.

Take a look at custom behaviours in your CF distribution for error pages so they’re cached for less time. You don’t want 404’s being displayed for content that’s actually present.

Finally, some things I’m still working on:

Cloudfront fetches content from S3 over port 80, not 443, so this wouldn’t be suitable for secure applications because it’s not end-to-end encrypted. I’m trying to think of a way around this.

I’m implementing Circle CI, just for kicks really.

Finally, invalidations. As above, if you don’t invalidate your CF disti after deployment, old content will be served until the cache expires. But invalidations are inefficient and ultimately cost (slightly) more. The solution is to implement versioned object names, though I’m yet to find a solution for this that doesn’t destroy other Hugo functionality. If you know of a clean way of doing it, please tell me 🙂

 

Compliance in DevOps and public cloud.

As a DevOps engineer, you’ve achieved greatness. You’ve containerised everything, built your infrastructure and systems in the cloud and you’re deploying every day, with full test coverage and hardly any outages. You’re even starting to think you might really enjoy your job.

Then why are your compliance teams so upset?

Let’s take a step back. You know how to build secure applications, create back ups, control access to the data and document everything, and in general you’re pretty good at it. You’d do this stuff whether there were rules in place or not, right?

Not always. Back in the late 90’s, a bunch of guys in suits decided they could get rich by making up numbers in their accounts. Then in 2001 Enron filed for bankruptcy and the suits went to jail for fraud. That resulted in the Sarbanes-Oxley Act, legislation which forced publicly listed firms in the US to enforce controls to prevent fraud and enable effective audits.

Sarbanes-Oxley isn’t the only law that makes us techies do things certain ways though. Other compliance rules include HIPAA, ensuring that firms who handle clinical data do so properly; GDPR, which ensures adequate protection of EU citizens’ personal data; and PCI-DSS, which governs the use of payment card data in order to prevent fraud (and isn’t a law, but a common industry standard). Then there are countless other region and industry specific rules, regulations, accreditations and standards such as ISO 27001 and Cyber Essentials.

Aside from being good practice, the main reason you’d want to abide by these rules is to avoid losing your job and/or going to jail. It’s also worth recognising that demonstrating compliance can provide a competitive advantage over organisations that don’t comply, so it makes business sense too.

The trouble is, compliance is an old idea applied to new technology. HIPAA was enacted in 1996, Sarbanes-Oxley in 2002 and PCI DSS in 2004 (though it is frequently updated). In contrast the AWS EC2 service only went out of beta in late 2008, and the cloud has we know it has been around for just a few years. Compliance rules are rarely written with cloud technology in mind, and compliance teams sometimes fail to keep up to date with these platforms or modern DevOps-style practices. This can make complying with those rules tricky, if not downright impossible at times. How do you tell an auditor exactly where your data resides, if the only thing you know is that it’s in Availability Zone A in region EU-West-1? (And don’t even mention to them that one customer’s Zone A isn’t the same as another’s).

As any tech in a regulated industry will appreciate, compliance with these rules is checked by regular, painful and disruptive audits. Invariably, audits result in compliance levels looking something like a sine wave:

This is because when an audit is announced, the pressure is suddenly on to patch the systems, resolve vulnerabilities, update documents and check procedures. Once the audit is passed, everyone relaxes a bit, patching lags behind again, documentation falls out of date and the compliance state drifts away from 100%. This begs the question, if we only become non-compliant between audits, is the answer to have really, really frequent audits?

In a sense, yes. However, we can no longer accept that audits with spreadsheet tick box exercises, and infosec sign-off at deployment approval stage actually work. Traditional change management and compliance practices deliberately slow us down, with the intention of reducing the risk of mistakes.

This runs counter to modern DevOps approaches. We move fast, making rapid changes and allowing teams to be autonomous in their decision making. Cloud technology confuses matters even further. For example, how can you easily define how many servers you have and what state they’re in, if your autoscaling groups are constantly killing old ones and creating new ones?

From a traditional compliance perspective, this sounds like a recipe for disaster. But we know that making smaller, more frequent changes will result in lower overall risk than large, periodic changes. What’s more, we take humans out of the process wherever possible, implementing continuous integration and using automated tests to ensure quality standards are met.

From a DevOps perspective, let’s consider compliance in three core stages. The first pillar represents achieving compliance. That’s the technical process of ensuring workloads and data are secure, everything is up to date, controlled and backed up. This bit’s relatively easy for competent techs like us.

The second pillar is about demonstrating that you’re compliant. How do you show someone else, without too much effort, that your data is secure and your backups actually work? This is a little more difficult, and far less fun.

The third pillar stands for maintaining compliance. This is a real challenge.  How do you ensure that with rapid change, new technology, and multiple teams’ involvement, the system you built a year ago is still compliant now? This comes down to process and culture, and it’s the most difficult of the three pillars to achieve.

But it can be done. In DevOps and Agile culture, we shift left. We shorten feedback loops, decrease batch size, and improve quality through automated tests. This approach is now applied to security too, by embedding security tests into the development process and ensuring that it’s automated, codified, frictionless and fast. It’s not a great leap from there towards shifting compliance left too, codifying the compliance rules and embedding them within development and build cycles.

First we had Infrastructure as Code. Now we’re doing Compliance as Code. After all, what is a Standard Operating Procedure, if not a script for humans? If we can “code” humans to carry out a task in exactly the same way every time, we should be able to do it for machines.

Technologies such as AWS Config or Inspec allow us to constantly monitor our environment for divergence from a “compliant” state. For example, if a compliance rule deems that all data at rest is encrypted, we can define that rule in the system and ensure we don’t diverge from it – if something, human or machine, creates some unencrypted storage, it will be either be flagged for immediate attention or automatically encrypted.

One of the great benefits of this approach is that the “proof” of compliance is baked into your system itself. When asked by an auditor whether data is encrypted at rest, you can reassure them that it’s so by showing them your rule set. Since the rules are written as code, the documentation (the proof) is the control itself.

If you really want your compliance teams to love you (or at least quit hassling you), this automation approach can be extended to documentation. Since the entire environment can be described in code at any point in time, you can provide point-in-time documentation of what exists in that environment to an auditor, or indeed at any point in time previously, if it’s been recorded.

By involving your compliance teams in developing and designing your compliance tools and systems, asking what’s important to them, and building in features that help them to do their jobs, you can enable your compliance teams to serve themselves. In a well designed system, they will be able to find the answers to their own questions, and have confidence that high-trust control mechanisms are in place.

Compliance as Code means that your environment, code, documentation and processes are continuously audited, and that third, difficult pillar of maintaining compliance becomes far easier:

This is what continuous compliance looks like. Achieve this, and you’ll see what a happy compliance team looks like too.

 

Re:Develop.io History of DevOps talk

I recently gave a talk at Re:Develop.io about the history of DevOps, and this page is where you can find the slide deck and other relevant resources.

Video of the talk

Re:develop.io DevOps Evolution Slide deck

The Theory of constraints

Agile 2008 presentation by Patrick DuBois

10+Deploys per day, Dev and Ops at Flickr – Youtube

10+deploys a day at Flickr – slide deck

DORA 

Nicole Forsgren research paper

2018 State of DevOps Report

My “Three Ways” slide deck

Safety culture

Amazon DevOps Book list

Deming’s 14 points of management

Lean management

The Toyota Way

The Agile Manifesto

Beyond the phoenix project (audio)

Netflix – simian army

My Continuous Lifecycle London talk about compliance in DevOps and the cloud

 

 

 

 

Going solo

This is the view from where I’m living now.

I’ll explain. A couple of months ago, my partner was offered a once-in-a-lifetime opportunity to live and work in Andalusia, doing digital marketing for an organisation that is part retreat centre, part permaculture farm, and part yoga teacher training school. With brexit looming and faced with such a great opportunity to do something very different, we both rapidly left our jobs in the UK, packed up what stuff we didn’t get rid of or put in storage, and moved.

All of which means I’m now working with the organisations here (suryalila.comdanyadara.com and froglotusyogainternational.com ) alongside developing my own consultancy business and working as CTO for ydentity.com (so new we still have lorem ipsum text). I will freely admit that coming off the salary drug is a tough task, but having the freedom to do my own thing, develop my skills and work the hours that I want is proving very satisfying so far.

For the moment, I’m getting involved in a really wide range of work, from project management, tech consultancy, AWS engineering, to digital marketing and analytics, security consultancy and more. The reason for me getting stuck into such a wide range of tasks is so I can really work on evaluating what the most suitable area is for me to focus on in the future, both from a perspective of what I’m good at and enjoy doing, and also what I find there is most demand for in the marketplace.

If you would like to work with me or you’d like to discuss an opportunity for us to collaborate, drop me a line through LinkedIn, email me at tom@tomgeraghty.co.uk or pop in to see me in Andalusia, if you can get past the goats on the highway.

GDPR, and how I spent a month chasing my data.

sherlock holmes basil rathbone

In May 2018, I received a letter from a local firm of solicitors, Roythornes, advertising a property investment event. I hadn’t heard of them and I was damn sure I hadn’t given them my permission write to me at home. They were wide of the mark to say the least- I’m an unlikely potential property tycoon, unless we’re playing Monopoly. Even then, I’m a long shot.

It was a quiet week at work so given the recent implementation of GDPR and the fact that I really don’t like junk mail, I thought I’d give the new Data Subject Access Request (DSAR) process a whirl.

I couldn’t find contact at Roythornes to send a DSAR to but, helpfully, GDPR places no restriction on the medium someone can use to make a request, so at around 9am that day I filled in their online contact form, despite my concerns that it would get picked up by a clueless admin assistant. I requested a copy of the data they hold on me, the source of that data and the evidence of my opt-in for direct mail. I also asked that they delete the data they hold on me and send no further marketing material.

At 1:42pm, I had a from “Norma” of Roythornes (not joking, sorry Norma), asking for a copy of the letter and stating that she couldn’t find me in their database. So far, so good…

At 1:55pm, I received an automated recall email from Norma.

A few hours later, another email arrived, this time from the firm’s “compliance partner”, stating that they had acquired my personal data in a mailing list they purchased from Lloyd James Media, on the 1st of May 2018, and that my letter was sent out on the 21st May 2018. She stressed that the purchase of the list, and the sending of the letter itself was prior to the GDPR implementation date of 25th May 2018, and therefore legal.

Solicitors abiding by the letter of the law, not the spirit of the law? Imagine that.

Dancing around technicalities notwithstanding, Roythornes did confirm that my data had been deleted and I wouldn’t be hearing from them again. Phase 1 complete, but who exactly were Lloyd James Media, and how did my data fall into their hands?

For Phase 2 of my quest, a quick google told me that Lloyd James Media “is a multi-channel data agency focusing on the intelligent use of data to optimise customer acquisition and retention.” I can only assume this translates as “we make and sell mailing lists”. So, off went my DSAR email to their sales email address, because yet again, there was no contact information available for non-sales enquiries, let alone DSARs.

Andrew of the compliance team at Lloyd James Media only took 24 hours to get back to me. He confirmed that they sold my personal data to Roythornes for a postal campaign. They had acquired my data from another firm, “My Offers”, and the consent for postal marketing was obtained by them, apparently. Helpfully,  Andrew suggested I get in touch with the “compliance team” at My Offers. Evidently, this is a team of one, someone called Saydan, whose email address Andrew provided. I reminded Andrew to remove my data from their system and headed off to continue the hunt for the true source of my data, feeling like a geek version of Bear Grylls tracking an elusive squirrel. Phase 3 had begun.

My Offers are “Europe’s leading online direct marketing company with a database of 22.2million registered users.” I fired my third DSAR email off to Saydan later that day. One week later, I’d heard nothing. According to GDPR, there is no need for an immediate response, as long as the DSAR is executed within a month, but the silence was unnerving. Was Saydan trying to ghost me? I found their Facebook page and sent a message to whichever poor soul supports their social channels. For good measure, I also dredged LinkedIn for their employees, emailed Ivan, one of their directors, and in true annoying millennial style, tweeted at them. The only response was from their Facebook team, who reiterated that I should email the enigmatic Saydan, then also went quiet on me.

Over the next few weeks, because nothing seemed to be happening, I pinged their facebook team a courtesy message once each week with a gentle reminder of the impending deadline for a response. Part of me was relishing the prospect of not getting a reply, and I began googling, “What to do if someone doesn’t respond to a DSAR.” I was way too invested in this.

Then, exactly one month to the day since the original request, an email from Ivan, the My Offers director arrived in my inbox. Ivan’s email was straight to the point and only had a few spelling mistakes. Attached was a password protected CSV file containing all the information I’d requested. The password was sent in a separate email. So far, so good (though, yet again, I had to remind him to remove my data from their systems).

The CSV file was interesting. And by interesting, I mean in the way that hearing the creak of a stair when you’re in bed, and there’s nobody else in the house is interesting. The data contained my full name, birth date, gender, home address, email address, phone number, data subject acquisition date and source (Facebook), as well as a list of businesses that my data had been shared with in the past year. The list totalled around 60, including Lloyd James Media, various PPI and no-win no-fee firms, and more. That explains all the marketing calls over the past year then.

This CSV file was the smoking gun. However, the trigger was evidently pulled by my own fair hand. At some point, possibly whilst drunk, bored at work, or both, I’d clicked on a campaign offering me a beard trimmer. I still don’t have a beard trimmer (I do have a beard), so I presumably I didn’t pursue this purchase but in getting only that far, I inadvertently provided My Offers with access to my personal data, and consent for direct marketing. Sounding eerily familiar, I wondered if my voting choices in the last election were my own making.

So, just over a month after I sent my first DSAR to a local firm, what have I learned from this?

Firstly, GDPR actually works. Not only was the DSAR process easy to do, it was free (for me), and two out of three firms responded within 24 hours. Presumably GDPR is also helping to reduce unwanted junk mail; after all, Roythornes as good as admitted that they wouldn’t have posted the initial letter to me after the GDPR implementation date.

Secondly, once your data is out there, it gets around. It only takes one “online direct marketing company” to get hold of it, and your personal information will spread faster than nationalism in Europe.

Finally, don’t be dumb on facebook (like me). We know about Cambridge Analytica of course, but they’re not the only guys trying to harvest information and profit from it. Resist the lure of data-harvesting surveys and competitions, even when drunk.

Compliance in the Cloud

Continuous Lifecycle London slide deck:

https://docs.google.com/presentation/d/103csVh12upw-VfC7JoGBDElThYqeuWzg1SripJA_phs/edit?usp=sharing 

AWS compliance information:

https://aws.amazon.com/compliance/

ENISA cloud computing security doc:

https://www.enisa.europa.eu/publications/cloud-computing-risk-assessment

AWS security products:

https://aws.amazon.com/products/security/

Life without SSH:

https://www.youtube.com/watch?v=fEuN5LkXfZk

https://www.cisecurity.org/

www.devsecops.org

https://www.sans.org/reading-room/whitepapers/analyst/cloud-security-compliance-primer-34910

Contino Compliance as Code pdf:

https://www.contino.io/files/Compliance-as-Code-March-18-v13.pdf

Curve is making using money whilst traveling much easier.

Most people who know me are somewhat aware that I travel quite a lot. I love visiting new places, and I really enjoy being on the move. One thing that often bugs me, however, is how awkward using money in different countries can be.

Getting local cash at a decent rate can be a pain. Using an ATM abroad incurs fees from your bank, and you don’t necessarily get good rates. Going to a currency exchange can be a hassle too. I usually carry some dollar notes on me anyway, because they’re accepted almost everywhere.

Using your debit or credit card abroad incurs yet more fees, with unpredictable and usually poor rates.

This is where my new Curve card comes in. A Curve card essentially acts as a proxy between the world and your existing cards. You can add multiple credit and debit cards to it, and select which one to use for each payment (or even change it afterwards!). Using your Curve card doesn’t incur any currency conversion fees, and you receive a better rate than most high street currency exchanges.

Cleverly, all the transactions on your Curve appear as purchases on the “source” cards, which means you can also take cash out of an ATM using your Curve card, and choose to source the cash from any of your cards, including credit cards (without incurring the cash advance fees that you normally would), debit cards and pre-paid cards.

So what does this mean for travelers? Firstly, using your Curve card saves you money abroad, both when using it to purchase goods and services, or getting cash from an ATM.

Secondly, it’s far more secure. Just take your Curve out with you, and leave your main cards in the safe at the hotel, or simply keep them elsewhere on your person. If your Curve card gets stolen or lost, simply open the app and deactivate it. Even if it somehow got cloned by some unscrupulous bartender or waiter, you’ll receive instant alerts of any payments, so you’d know the instant it was used, which means you could instantly disable the card and request a refund.

Thirdly, you get real-time feedback and notifications, making budgeting far easier. You can tag your purchases, add notes, and scan receipts to add to purchases. This means you can keep track of your spending, check how much you’re spending on travel, food, shopping, etc, and even use it to form the basis of your expenses claim if travelling for business.

In my opinion, Curve is still lacking a few features though. You can’t yet add it to Apple Pay, which would streamline payments even further. You can’t add a single debit or credit card to multiple Curve accounts either. The reason for this is that when travelling as a group or a couple, you could all add some money into a shared pre-paid card (e.g. Monzo), and then add that to your individual Curves. This would solve all those split-payment problems when you’re paying for supplies or travel costs for the whole group. If there’s any “debate” around a certain item being charged to the group card, it’s easy to “go back in time” (as Curve put it), and charge it to a different (i.e. personal) card.

I’m pretty sure the group payment challenge is solvable, either with existing tech, or by someone shortly bringing out fintech joint accounts. Either way, using Curve has definitely made my travelling life a lot easier, and I’m excited to see what they do next.

Shameless promo: sign up for Curve here with code NPWZA and you’ll get £5, and so will I.