This article lists the major decisions you will need when designing a new SaaS system. It’s in the form of a checklist, with some nudges toward typical contemporary solutions. It covers storage processing, networking and a bunch of operational and business questions.
This is a follow-up to my previous article about hosting WordPress on AWS. A few months of production experience shows the site is performant and the operational tooling works. There have been three outages of unknown cause- but I was alerted by the monitoring and could quickly restore service. The design scores well against the AWS Well-Architected guidelines in all pillars except Security. Some fundamental design decisions of WordPress would make it imprudent to store large amounts of Personal Data. However, this design stacks up well for its prime purpose – running blogs or small websites.
This continues the data security theme with the most important security principle – defence-in-depth, This means having at least two strong defences against any attack, with monitoring to detect when either is breached.
Recently, we have seen attacks on weather bureaus, ambulances, sporting clubs – hardly “high-value targets”. A decade ago, strong defences applied to banks, government, and such – now it’s for all of us. We can’t turn all software architects into security experts so in these articles I will give security blueprints. You can apply them without fully understanding why you need them, or how they work, and the result will be a more robust system.
AWS and WordPress are gorilla products – one is the largest cloud vendor, and the other powers 43% of all websites. Let’s walk through a well-architected solution for hosting WordPress on AWS and try to meet commercial levels for reliability, security, performance, maintainability and CO2 footprint. It’s a struggle but ends with a provisional tick of approval.
This shows the power and convenience of the AWS toolset and the problems of pushing WordPress a bit further than it was meant to go.
Software developers often make invalid assumptions about how their software is operated in production. As a result, systems eventually and too often fail in ways we care about – security, performance, reliability, and scalability. This article describes six dangerous assumptions that software developers make about their colleagues in operations.
