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.
Data breaches – a $5 million average cleanup cost and $11 trillion drain on the world economy. That’s the GDP of the 130 poorest countries on earth. As software architects, we enabled all that. In our hubris, we put insecure systems on the Internet, declared them ‘done’, and set up our users and employers to become victims. We should be ashamed.
Personal Data is the target of the big data breaches, and when it’s at rest it’s easiest to steal. This post will show strong and easy-to-follow techniques for protecting personal data at rest.
Reporting and ETL “just work” in a DB-centric design, when the data is in 3rd Normal Form. In a microservice design, they do not. If you apply the traditional ETL tools to your microservice stores, you will lose your microservice benefits. Let’s see a way to get better-than-SQL reporting, without sacrificing time-to-market, team velocity or SLAs, and opening a path to the CQRS pattern.
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.
Traditionally, transactions are seen as a database issue with little to do with UI, networking or processing. They are also seen as a technology issue for developers and DBAs, and not particularly interesting for BAs or end-users. I’m going to challenge both of those premises and suggest a new user-centred view – “Transactions let a user move on with their life after they use our system.”
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.
On the 17th of November, 2022, Fred Brooks passed away. The man who invented the 8-bit byte and the field of Software Engineering and who first said, “Adding manpower to a late software project makes it later”.
Let’s see how his magnum opus, The Mythical Man-Month, has fared after 50 years.
