One of the challenges many of us come across when taking a more automated approach to infrastructure is the sheer number of tools available. This is especially true when you come from a one tool for multiple roles environment. Every week, there appears to be another tool for you to choose from. Finding where to start is quite daunting, and the opinions of others leads to much second guessing. One of the lessons that would have helped me earlier on, is understanding what the role of a specific tool is and how it fits into the overall process.
If you’;re looking at Python to interact with API’;s, it’;s likely that you’;ll use the Requests module. Many platforms also offer SDK’;s to help. Such as, Boto3 which is the AWS Python SDK. Requests is very well documented, both official and community documentation. The official site for Requests is http://docs.python-requests.org/en/master/ In this post, we are going to cover the basics of performing a HTTP GET and working with the data.
To describe a VPC is to retrieve the values of it attributes. A task we might perform to validate configuration. This article will demonstrate the following: Find VPC ID using filters Retrieve VPC configuration values Information on Boto3 can be found here. This post assumes that you already have a working Boto3 installation. Including IAM configuration to perform the task. If you have not, click here for the install document.
Operations managers Intelligent workload placement used to be a challenge. Systems such as VMware’;s DRS provided simplicity. Operations managers take workload placement to another level. Ops Managers maintain a holistic view of DC performance and health. They have a large base of information to make decisions on. The more sources of data the better the output. Detection of possible failure conditions can trigger an automatic evacuation. OPs managers provide a range of capabilities outside of workload placement.
Traditional application architecture is not optimal for cloud services. They are big, singular and designed to be always on. Cloud requires small, mobile applications which handle failure without impact. Cloud is constantly failing. Systems are crashing, misconfigurations etc. We see it as stable through application design. When we interact with cloud systems, we are interacting with systems designed for failure. When there is a failure, the application is able to remain functional.
Data gravity imposes a significant constraint on assessing where a workload should run. Workloads perform better when close to the source of data. Data latency has a tangible cost associated. The timing might be in milliseconds, but the impact can be significant. A business loses money when employees are waiting. Customers are not patient and will look elsewhere if services are slow. Storage vendors make significant investments to lower storage latency.