Links: 4-4-2011

  • Perspectives – Prioritizing Principlas in "On Designing and Deploying Internet-Scale Services"
    Quote: "Have Well Defined Architectural Roles and Responsibilities: Robust systems are often described as having "good bones." The structural skeleton upon which the system has evolved and grown is solid. Good architecture starts from having a clear and widely shared understanding of the roles and responsibilities in the system. It should be possible to introduce the basic architecture to someone new in just a few minutes on a white-board. Minimize Variance: Variance arises most often when engineering or operations teams use partitioning typically through branching or forking as a way to handle different use cases or requirements sets. Every new use case creates a slightly different variant. Variations occur along software boundaries, configuration boundaries, or hardware boundaries. To the extent possible, systems should be architected, deployed, and managed to minimize variance in the production environment. Clean-Up Cruft: Cruft can be defined as those things that clearly should be fixed, but no one has bothered to fix. This can include unnecessary configuration values and variables, unnecessary log messages, test instances, unnecessary code branches, and low priority "bugs" that no one has fixed. Cleaning up cruft is a constant task, but it is a necessary to minimize complexity."
    (categories: architecture scalability scaling saas failure versioning debugging deployment )

  • Jetpack
    Quote: "Jetpack supercharges your self‑hosted WordPress site with the awesome cloud power of WordPress.com." Cool example of on prem / self hosted software + SaaS.
    (categories: saas plugins wordpress tools blogging jetpack )

  • OmniTI ~ On the Engineering of SaaS
    Great article on the difference between on prem and SaaS software, excerpt: "An upgrade process, for example, is an entirely different beast. Making it robust and repeatable is far less important than making it quick and reversible. This is because the upgrade only ever happens once: on your install. Also, it only ever has to work right in one, exact variant of the environment: yours. And while typical customers of software can schedule an outage to perform an upgrade, scheduling downtime in SaaS is nearly impossible. So, you must be able to deploy new releases quickly, if not entirely seamlessly — and in the event of failure, rollback just as rapidly."
    (categories: saas engineering software deployment qa agile testing )

  • Building SaaS: High-Metabolism Software Development
    More on SaaS as it relates to QA.
    (categories: saas agile deployment testing )

Leave a Reply

Your email address will not be published. Required fields are marked *