Ashish Pitrodafield notes
All plates

Field guide Plate 05

AWS & speed

Getting an application onto AWS and keeping it quick once it is there. Not a devops practice — I deploy what I build, so the deployment is designed for the application rather than the other way round.

— servers, and the speed of them

I

Where it’s found

who this is for

Deploying is frightening

because one person knows how and it involves a document. Deploys should be boring, repeatable, and something anyone on the team can run on a Friday.

The site got slow

as traffic or data grew. Worth measuring before spending: the fix is often an index and some caching rather than the larger instance you were about to buy.

The bill keeps climbing

and nobody is sure what for. Usually a handful of resources nobody turned off, and storage classes left at the default since the day the account was opened.

II

Field marks

what the work actually is

  1. Getting it deployed

    EC2, Nginx, Postgres, media on S3 and CloudFront in front. Certificates that renew themselves, and a deploy written down rather than remembered.

  2. Backups you have tested

    An untested backup is a belief, not a backup. Restoring one is part of the job, not an optional extra to be done later.

  3. Performance, measured

    Profiling first, then the fix, then the same measurement again. Database queries, caching, image delivery and asset pipeline, in the order the numbers justify.

  4. Monitoring

    Enough to know something is wrong before a customer tells you, and few enough alerts that people still read them.

  5. Cost

    Right-sizing, storage classes, and turning off what nobody uses. Frequently the cheapest week of work on this page.

III

Behaviour

how it runs

  1. 01Measure

    Numbers before anything changes, so the result can be judged rather than felt.

  2. 02Cheapest first

    The fixes in order of value per hour, not in order of interest to me.

  3. 03Change one thing

    So it is clear which change did what. Several at once teaches you nothing.

  4. 04Write it down

    Runbook in the repository, including how to undo each change.

IV

What it costs

what decides the price

Performance work is usually the best-value item on this page, because it is bounded: measure, fix the top three, measure again. A fresh deployment is predictable. Inheriting infrastructure nobody documented is the one that needs a look before a number.

Defined work is quoted fixed. Where the current state is unknown, the first step is a short paid audit that produces the plan and the number, and the audit is yours regardless.

V

Questions

the ones I get asked

Should we move to Kubernetes?
Probably not. Most applications I see are well served by a couple of instances behind a load balancer, and the operational cost of a cluster is paid every week by whoever is on call.
Can you take over infrastructure someone else set up?
Yes. The first deliverable is a written description of what is actually running, which surprisingly often is the first time anyone has had one.
Will this need ongoing work?
Security patching does, yes. That can be a small retainer or it can be your team with a documented runbook — I would rather you had the choice than depended on me for it.

Send a note

Tell me what you have, what is wrong, and what it should do instead. I will tell you honestly whether I am the right fit.

Write to me or read the other plates