Cloud, AWS and DevOps engineering
Infrastructure decisions made by people who do not maintain the application tend to produce infrastructure the application has to work around. These are the same hands that write the code.
Does this sound familiar?
You are probably here because of one of these
Deployment is a manual process that one person knows how to do, performed nervously and out of hours.
Your AWS bill has grown faster than your business and nobody can fully explain why.
Bugs appear in production that cannot be reproduced locally, and time disappears into the difference.
Onboarding a developer takes a day or more before they can run the project.
Your infrastructure was set up years ago by someone who has since left.
You need to scale and are not confident the current architecture will take it.
What this covers
The work itself
Not a capability list — these are the specific things an engagement in this area actually involves.
AWS architecture
Designing and improving infrastructure across EC2, S3, RDS, Lambda, ECS and CloudFront — sized for the load you actually have, with a clear path to the load you expect.
Docker and environment standardisation
Containerised development and QA environments defined in the repository, so that what a developer runs, what QA tests and what production serves are the same thing.
CI/CD pipelines
Automated build, test and deployment, so releasing is a routine event rather than one requiring a specific person and a quiet evening.
Cloud cost optimisation
Finding where the bill actually goes and reducing it. On a healthcare platform this meant replacing a managed transcoding service with a purpose-built one, because the managed service was charging for a great deal the product never used.
Deployment and release process
Zero-downtime deployment, sane rollback, and environment configuration handled properly rather than through files nobody is allowed to touch.
Linux and operational depth
Comfortable at the command line where infrastructure problems actually get diagnosed, rather than only in a console.
Typically involves
- AWS
- EC2
- S3
- RDS
- Lambda
- ECS
- CloudFront
- Docker
- CI/CD
- Linux
How the work runs
The approach
Consistent across engagements, because the order these things happen in is usually what determines whether a project goes well.
- 01
Understand the application first
Infrastructure serves an application. Designing it without understanding how the application behaves under load produces something technically impressive and practically wrong.
- 02
Automate the thing done most often
Deployment is usually the highest-value automation, because its manual cost is paid repeatedly and its failure cost is paid publicly.
- 03
Make environments identical
Most of the mystery in software comes from environments differing in ways nobody has documented. Removing that difference removes a whole category of problem.
- 04
Right-size deliberately
Cloud costs grow by default and shrink only on purpose. Architecture matched to real usage is usually both cheaper and simpler than architecture matched to imagined usage.
Evidence
Where this has been done
Real projects involving this work, with the reasoning and the results.
Questions
What people usually ask
- Do you only work with AWS?
- AWS is where the depth is — EC2, S3, RDS, Lambda, ECS and CloudFront across many years — with GCP exposure as well. The underlying principles transfer, but you should expect AWS-specific advice to be the strongest.
- Can you help reduce our cloud bill?
- Often, yes. It usually starts with working out where the money actually goes, which is frequently not where the team expects. Sometimes it is right-sizing; sometimes it is an architectural decision that made sense once and no longer does.
- Do you offer infrastructure work without application work?
- Yes, though the most valuable engagements are usually the ones covering both — because the largest infrastructure improvements tend to require an application change, and vice versa.
Have a software problem, project or idea?
Tell me what you are trying to achieve and where it is currently going wrong. You will get an honest read on it from someone who has built this kind of thing before — including if the answer is that you do not need what you were about to buy.
Prefer not to call? Send me a message
Working with businesses across Australia — Melbourne, Sydney, Brisbane, Adelaide, Perth, Canberra and regional Australia.