If you are a Cloud expert, this may not be relevant for you. Otherwise, “if you are just taking your first lift-offs towards the Moon”, if you are interested into getting the Cloud IaaS Big Picture, making your first steps into IaaC ( Infrastructure as a Code ), if you are interested to find out about Configuration Management and in particularly learning ( how to learn ) Ansible, if you are interested in DevOps and Cloud Architecture, then this and following Posts could turn to be an interesting reading for you ( hopefully ! ).
This is an Introduction Part as part of series of Posts I am planning to publish on this topic: “Automation in the Cloud“.
Total Ops Beginners. You can be from any Line of Business, like for example you can be a Developer that would like to do the extra steps into the Ops, a Project Manager at your Cloud Start Journey, new System Administrators to the Cloud etc …
The big goal, as the Post Title says, is to achieve Automation in the Cloud ( in any Cloud for now ), but hey ! to be able to achieve that … well, let’s learn to walk before we’ll go for an easy run, and even before that, let’s setup the high level itinerary.
Why would you want to achieve Automation in the Cloud ?
At least because you want to achieve:
- An easy way to manipulate Cloud Resources as needed – aiming for fully Automation if and when possible; a quick note here: you cannot really achieve Continuous Delivery without fully Automation. Fully Automation is not easy to obtain, but the higher you aim the better.
- A mandatory step towards managing your Cloud Security. Let’s say mandatory at least for enterprise, though I believe that even if you work for a small/medium business ( or for yourself ) and have a few servers that should still be at some minimal interest for you, think IAM ( Identity Access Management ).
- A mandatory step towards managing your Cloud Cost Control. You wouldn’t like your CEO/CFO calling you at midnight and giving you an ultimatum of a few hours ( or a few days in best case scenario ) to review all the Cloud Instances, because the costs are currently in a total chaos and no one knows what is it paid for, who’s using it, if it is being used at all, and so on.
- A mandatory step towards managing your Cloud Compliances, and/or other various Cloud Policies and/or just Policies that must be embedded into the Cloud etc.
There is a plethora of open source technologies to choose from ( how nice this is ! ) and you have the luxury today to pick from such a large existing variety. Actually, there are so many out there today, some due to the massive adoption, they became de-facto standard ( this is the best scenario ), but in some areas new “tools” are being created and many alternatives are being offered and is hard, if not even very hard, to select the ones that will suit you the best, therefore this luxury may turn into time consuming, time that you do not have it, so let me say right from the start, that the best to do when it comes to decide your selections of instruments and tools, is to always consult and look for professionals that can help you and guide you in making the best selections.
So now that I’ve covered that, I can brag about any kind of tool I want .
To the Point:
Achieving IaaC is not easy, particularly if you are planning to be Cloud Agnostic and have a Multi Cloud approach as you should really do, especially if you are an enterprise.
Yes, major IaaS cloud providers like AWS, Oracle, Google, Microsoft and others are already defining similar IaaS Architectures, at least on the high level, but still, different vendors may have different implementations, so if your goal is to be Multi Cloud compliant, you need to stay as flexible as possible. What flexible means ? Well, it can be open source, non-open source, or a combination of both, it really depends on many factors and constraints.
So let’s pick up some tools here ( the minimum setup ), pick any of your favourites here, it won’t matter, I just mention these tools as a minimum setup to position yourself in blockstarts:
- Source Control Management (SCM ): Github
- Project and Issues: Github Projects
- Editor: I find myself lately using Visual Studio Code again ( left it loooong time ago, when I moved from C/C++ into Java, and fall for IntelliJ ) among vim and/or nano
Unlike with the above tools, for the Configuration Management I will be selecting Ansible. Among other famous tools like Chef and Puppet, I will select Ansible in my Post. And this will be one of the main core tools for Configuration Management around which I will try to build the fully Automation itinerary.
Myself came to hear of Ansible from my colleagues at times when I was using Chef.
There are many reasons that made me pick Ansible and I’ll just mention a few I found suitable for my described goal:
- is open source
- is agentless
- adoption grows and many libraries are starting to be available ( many already existing for the major Cloud Providers )
- a quick google search may display a lot more PROs and even some CONs
So, starting with the next Post I will focus on how to set up your learning curve for Ansible.
Happy Sailing !
How useful was this post ?