Cloud means DevOps - No Cloud without DevOps

I strongly believe that you can't be successful in the Cloud without also adopting DevOps. Here is why.

My latest definition of DevOps is

• if every person uses the same tool for the same job
• codified knowledge:
  everybody contributes his part to common automation
• if all people have the same privileges in their tooling
• if human error is equally possible for Dev and Ops
• replacing people interfaces by automated decisions and processes

but most of all DevOps is the result of doing the right thing and not a process, methodology or even tool set of its own.

Looking closely at public cloud vendors and their interfaces I see a close correlation with this DevOps definition. Cloud vendors

• give every person the same interfaces and tools to work with
• are API based and make it really simple to code the entire setup
• give all users the same privileges - that of a customer
• let all their users make the same mistakes indisccriminately
• provide most change requests through automation and automated decisions

For example, an engineering team working with an AWS account starts out working DevOps style. As long as all the team members have the same permissions in their AWS account and share the same duties towards their organization this remains the case. DevOps starts breaking only when the organization doesn't trust the team to be fully responsible for their account and imposes restrictions so that the team cannot - for example - create IAM roles.

In such a case it is the customer who introduced a new management process that breaks the DevOps definition given above: Now some engineers have more privileges in their tooling and different engineers use different tools for the same job: The security engineers review, approve and apply IAM roles within AWS while all other developers cannot use the AWS interface to do so but must submit their IAM roles to the security engineers via some process. Even if this is highly or fully automated the developers cannot use AWS with its native tooling like Cloud Formation.

Maybe the company policies require this kind of split responsibility. However, most likely the underlying motivation is not one of preventing DevOps or hindering developers. Typically this split responsibility was the only practical solution available to establish security governance over the AWS account.

Automating such challenges is also the road to achieve or keep true DevOps: Automate all processes and remove the human factor from as many decisions as possible. Let the developers work with the native tooling without introducing abstractions as security gateways. Use these DevOps principles as guidelines to design a good solution that works for all.

A workable solution for the IAM role example given above could be an automated process that checks new IAM roles as soon as they are created. With CloudWatch Events and Lambda functions this is not a big challenge to implement. If a new or modified IAM role violates the company policies simply delete it (or revoke all trusts) and alert the person who created it. They will be thankful for the help in keeping the policies and they will be thankful that they can work with the native tooling.

In turn, the degree to which all people enjoy the same privileges can be also used to actually measure DevOps adoption.