When speaking to members and customers about their cloud adoption, I often use a phase to describe the development required for members of the team that will ultimately be deploying and managing resources in the cloud.
I describe the need for these individuals to become “good cloud citizens”.
This, of course, is followed by the question, “what is a good cloud citizen?” or, “how do I become a good cloud citizen?”.
My thinking here is not ground-breaking, but it is critical. My intension is to focus on how team members must adjust their own thinking and behaviours to be a good member of the organisation’s cloud community… i.e. to become good cloud citizens.
Some of these are simply good practice. They are behaviours that the team should have already been demonstrating. However, with the pace of development in the cloud these are more important than ever before.
Let’s consider, first of all, the major differences between consuming resources in a traditional environment versus the cloud. To my mind these can be summarised by cost and agility.
The consumption-based model of the cloud and the vast range of ‘tools’ in the cloud toolbox should be one of its strengths. But to maximise this we must exhibit the correct behaviours and, let’s be honest, with some of the over-provisioned on-premise infrastructure we have all worked on in the past, we’ve probably all picked up bad habits!
So, how should we refocus?
Only take what you need!
Optimise your solutions, monitoring them carefully for performance. If you only need 2 CPUs, only provision 2 CPUs, don’t be tempted to add a few ‘just in case’. And be comfortable that you are working with infinite scale so when you need more, it will be available. There is no need to ‘hoard’ performance.
Be tidy!
Pick up after yourself and don’t leave your litter hanging about! Delete anything you no longer need, especially in development environments. This is not just a good practise to support your management of costs, it also removes any ‘noise’ from the platform. And you can do this sound in the knowledge that, having created your resources using Infrastructure as Code (IaC), you are only a few minutes away from deploying it again if needed. Which neatly brings me onto….
Use Infrastructure as Code!
This is not just best practise, allowing greater collaboration, version control and enabling deployment pipelines, but a fundamental enabler of many of the other attributes that we want our cloud citizens to have.
And the great news is IaC is getting more accessible – For Azure, check out our recent Project Bicep blog, written by Neil Sayer.
Operate within the law!
Be aware of, and follow, any governance or operational practises that have been implemented by your organisation. These requirements may not be enforced by platform tools like Azure Policy or AWS service control policies. So, don’t be tempted to save yourself five minutes and, for example, not populate resource tags or not conform to your organisation’s resource naming conventions.
Test your infrastructure in the right place with the right data. Don’t allow yourself to introduce shadow IT as it was just easier to “promote your development environment to live”… have I mentioned IaC?!
Be secure!
Whilst you maybe 100% confident with security measures at the edges of your environment, there will always be potential for compromises. News of zero-day exploits are not uncommon. Therefore, we must always do our best to be a ‘hard target’. Ensure that system ‘micro segmentation’ and ‘least privilege’ concepts are implemented. Doing so will vastly reduce the velocity of any lateral movement from a compromised system.
Be knowledgeable!
Keep yourself up to date with your chosen cloud platforms. This is now more important than ever, with the increased pace of innovation and cadence of feature releases. Ensure you share your knowledge with your team and encourage them to reciprocate. There are so many feature releases, it typically takes a whole team to keep up with them, particularly if you are working in a multi-cloud environment.
Don’t allow your solutions to introduce technical debt. Regularly review your work with your newfound knowledge; and remember you can easily test any innovations by slipping them into your IaC and releasing them to development environments.
Documentation, documentation, documentation!
This should not be onerous. Documentation takes many forms and you don’t have to write war and peace. Instead, ensure that any IaC is carefully commented, all resources have appropriate tagging and any supporting documentation is accurate and references these assets where appropriate. As workloads are introduced into service make sure you seek feedback from the support teams on your documentation. Could they find all the answers?
Pride!
Take pride in being the best cloud citizen you can be! And promote these values to others.
Ultimately you will find that operating in this way will allow you to produce better, cost-effective solutions and at pace!