This is the first of a multi-part series. Check back for future installments.
When you have a SaaS application that the FDA cares about, there are certain things you have to do. Usually there are really good reasons. Take for instance the regulatory requirement that when you install your application on a web server, the server must pass an installation qualification. In layman’s terms, that means you have to prove one way or another that what you want installed on that box is actually what’s installed on that box.
Maybe your application is written in PHP, and your installation qualification document says that you need the following packages installed (among others, of course). Why does it say that? Because you’ve gone through an extensive validation process to all but prove mathematically that your application works the way you say it will.
- php-5.3.3-40.el6_6.x86_64
- php-symfony-2.3.9-1.el6.noarch
- php-pdo-5.3.3-40.el6_6.x86_64
You did things the modern way: you got yourself an AWS account and used CloudFormation, Autoscaling, Chef and other great tools to create a stack of web servers that work perfectly. You go the extra mile and make sure that all the packages listed in your IQ are pinned in Chef. Good for you.
Time passes, Amazon shuts down some of your instances. No surprise there. They come back up fine. Just like you designed it. You knew it would work correctly.
A couple more months pass. Your architect has suggested that you consider upgrading your version of PHP to, you know, something WRITTEN THIS DECADE. The quality assurance team is happy to play their role, but boss man grits his teeth when QA tells him that it’ll take 2 months to redo validation and update the installation qualification. Man, that’s expensive. But you’re also thinking about upgrading MySQL, and that’ll require re-validation and an updated IQ, and hell … you might as well only go through that process once. The team decides to upgrade both PHP and MySQL at the same time. No problem. You guys are good.
Two weeks into the project, your alerting tools start letting you know there’s a problem with production. When increased traffic hit your web server stack just after lunch, your two new web servers didn’t come up correctly. Checking your logs, you see:
No package php-5.3.3-40.el6_6 available.
You have a problem.
To be continued …
Read part two of Building an RPM repository in AWS.
[…] This is the second installment of a multi-part series. You can start at the beginning with Building an RPM repository in AWS. […]
LikeLike