No Permissions? No Problem? How we did without console in AWS
I work with some of the smartest customer staff I have seen and as all of us had one common goal — we wanted to enable “very high speed delivery to production”. This means, we wanted to compress the cycle time it takes to from from idea to realization. Where it would take us 3 to 6 months in analyses and design, we wanted it compressed down to days if not hours. That, as many of you may know, is what tech avant garde such as Amazon.com, Google, Facebook does all the time. For example, Amazon.com changes it’s website every 11.6 seconds. Other people have put this frequency at a change per second. Compared to that, our release timeline of one bu fix every month or major release per quarter seems to have come straight from the dinosaur age.
Granted, our site is diddly compared the Amazon behemoth, however, I have a feeling that the short release cycle is not something that Amazon has because it can “have” it or because it can “afford” it. IMO, it is because Amazon really wants it, because it is a key idea for them. There are many contemporary tomes out there expounding the value of speed as a key strategic idea. My point is, high speed IT operations can only assist, not impede, the business. That opinion, combined with the fact that it can be really inexpensive to run automation on the Amazon Web Services Platform, makes it important, if not downright smart to at least evaluate how can release cycles be shortened. That evaluation and adoption, we did — diddly or not!
Coming back to the topic, one thing we decided early on in the development of our main client facing product is that infrastructure will be written as code. Meaning, no one should have the ability to go to a visual interface and change anything in any environment. To affect any change of any type (code, configuration, capacity), developers must change code in their workstation and have it run through AWS CodePipeline. True to my principles at my company FastUp, all tooling is AWS native. This means CodePipeline would invoke CodeBuild and then invoke CloudFormation to eventually deploy to an environment. Most testing (such as regression and performance testing) is targeted to be automated. Developers cannot make any changes through the AWS console, however, they can see the outcome of their code changes that led to infrastructure changes. Initially, there was resistance to this approach, very soon, the team adopted it and actually found this to be a liberating power. Seeing infrastructure as something that “I coded” gives developers a new sense of pride and responsibility. They loved it!
The way to do this is to delegate all powers of deployment to CodePipeline and CloudFormation. In our world, we created a Service Role each for CodePipeline, CloudFormation and CodeBuild. This can be further secured (or walled up — depending on requirements) to create a service role with specific permissions for a specific product that is built in the tooling. We did not feel the need for that just yet. These service roles had all those permissions in AWS that, normally, a human would have had. For example, if a human wanted to create a Lambda function, that human would need at least the permission to create a function, among many other actions. In our world, instead of providing that permission to a human, we provided it to CloudFormation. Developers wrote CloudFormation templates that declared the infrastructure. This way, Developers did what they did best and monotonous operations were completely automated. Cool beans!