CompTIA Cloud+ CV0-003 – Domain 4.0 Management Part 2

5. Forecasting Resources

Forecasting resources when it comes to managing your cloud environment. One of the day-to-day challenges that operations will face is determining the appropriate amount of resources to allocate at what time and identifying any performance issues that need to be addressed. So this is where forecasting really sort of comes into play on this exam. There’s going to be a couple areas around forecasting that we want to make sure you understand before you take this exam. So, what exactly is forecasting? This is a process of making predictions based on past and present data, mainly by analysing trends.

For example, if you can look at the previous year’s cloud resources and notice that for some reason, you’re using more storage in January than other months, that might give you an idea about whether you need more storage. But, of course, that doesn’t answer why. You may want to look into why as well. Forecasting, of course, can be complex. And one of the difficulties I frequently face with my customer base is accurately forecasting, and before I go any further, I want to emphasise that forecasting is not an exact science. I call it artwork because, again, if you’re in a production environment, this only becomes ten times harder if you’re working with a cloud provider. But, if you’re just managing a private cloud with a hybrid cloud component, you should be able to make some educated guesses based on stakeholder feedback, past usage, and any management input. With that said, it’s still complex.

This is not an easy part of the job when it comes to forecasting resources. You’ll need to monitor those resources and plan accordingly. For example, most of the cloud platforms have very solid management and monitoring dashboards that you could use. Now there’s a cost to using some of this, especially if you’re going to monitor a significant number of objects, of course. But with that said, if you’re not monitoring your environment, then how do you know what you’re really using, what is actually utilized, and what is not? So you’ll need to look at VM, storage network bandwidth, number of objects, et cetera, applications—a lot of things to look at. Cost allocation is critical to understand as well, because once again, as I previously stated in one of the earlier modules, your biggest cost in the cloud is going to be your virtual machines or your storage. In most cases, a baseline This is a term you’ll want to know. This is essentially a minimum level or starting point that you’re going to use for comparisons. Now a baseline drift Here’s another term that I like to make sure you know. This is essentially where the purpose of your cloud at first was just to store objects and data, and then over time, that cloud changes its usage from just storing data to running your VDI environment. So that’s called a “baseline drift,” where the purpose of that cloud has sort of changed from its original use case. Again, this can cause some challenges to the baseline, and if that happens, then that can also increase forecasting challenges as well. You want to create a baseline to compare your cloud usage, performance, security, billing costs, etc, etc. When it comes to monitoring resources, monitor what you need to monitor and plan usage accordingly.

Look at anomalies. What can happen is more than possible. You could see that over time, the resource usage went up, and then you hit what’s called a brick wall over here. That’s where there aren’t really any more resources to provision or allocate, whatever term you want to use. You could also use it to determine deviations, especially when it comes to usage and billing. These are areas that can really help you determine how effective your cloud allocation is. Now, in AWS, you could use what’s called a budget. You could create a budget to keep track of your cloud usage. And this could be very helpful, especially if you have a strict budget and you want to make sure that resources aren’t just being allocated out and just being wasted. Once again, generally, here’s what I see. Usually people spin up VMs, but they don’t spin them down. Generally, customers add a lot of snapshots, but they don’t remove those snapshots when they don’t need them anymore. They store a lot of data that doesn’t need to be there, and so on and so forth. With that said, create a budget to help monitor some of this. And of course, this is just one of the many ways in which you can monitor your resources in AWS. A baseline drift can occur when the original purpose of the cloud changes over time. This is where you add features, remove them, et cetera. Here’s an exam tip. Understand that a “baseline” is a minimum level or starting point that you’re going to use for comparisons.

6. GCP Cloud Estimator

So I’m over here at the Google Cloud Calculator. So this tool here is a tool that you can use to get a cost estimate for your cloud services. So, for example, if you want to know how much something will cost as an estimate, you can enter your estimates here and it will provide you with a reasonable estimate. I wouldn’t say it’s super close, but it’s an estimate about what things cost. So you go here and select the VM class. for example, regular or pre-emptible.

Now, pre-emptible means that the VM can be stopped at any time if Google requires the resources or if the cost of the VM service exceeds what you’re paying for in general. And again, you can just go through and play around with this to get an idea. Select the location that’s important to know. For example, the cost of the operating system, whether free or paid, will be significant, so include that in your estimate. So to use 100 VMs, just a base microinstance, which is pretty much the least expensive they have, would cost about $388 per month. That is without any other services like storage or anything like an app engine, for example; that’s platform as a service. So again, you go through and play around with this. Let’s say you need storage and want regional storage. So we’ll just put in a thousand gigabytes there, add that to the estimate, and again, that jumps up. That’s about $400 a month just for storage.

So like I said, that gives you an idea of what you’re looking at, and then networking as well. Remember that every one of these services that you’re using—and another thing is that if you see those little arrows, you should select them so you can see that there’s a good number of services that you could use and specify. And again, with these data services, there are all kinds of costs that generally go along with them generally. So even though it doesn’t look like a lot, this stuff can definitely add up. I especially like the number of nodes that you’re going to be using. And then, as far as knowing, if you go over here to Dataproc again, how many nodes you need in the cluster, all this stuff can just add up pretty quickly. If you’re going to use monitoring, keep in mind that all of this volume logs, so we’ll just say ten gigs and leave that blank for now. And you can see that I added Stackdriver. So again, you can see that the cost is somewhat high there. So all of this adds up. So one of the things I always recommend to my customers or clients is to be very judicious with their costs, but also understand that these costs may not be exactly what you think. Again, it’s just an estimate, nothing more.

7. Chargeback

Chargeback. Let’s go ahead and talk about what Chargeback is and what Show back is, and make sure you understand the terminology and the difference between the two approaches. One of the first things to be aware of when it comes to setting up a private cloud, especially, is to make sure that the proper organisations in your company pay for their fair share of services. Or if your company isn’t structured like that, at least be able to do a show back and at least say, “Hey, here’s what development is using.” Or here’s what HR is using.

And this is part of financial management. And I know we touched on financial management in an earlier module, but just be aware that chargeback and show back are part of that area, that this is part of accounting, budgeting, and charging for the services. Now, chargeback is essentially an act or a policy of allocating the cost of an organization’s strategically located resources to the individuals or departments who use them. The goal is to provide visibility, but also to report on that chargeback generally, which usually incurs some kind of procurement process to bill for those services. in most cases. Again, every organisation I’ve seen has a different setup in which some people pay a bill directly, others get certain credits every month, and once those credits are used, there is additional backend reporting and backend processes to follow. Then there’s showback, which is different in that it’s more of a reporting procedure than a charging procedure. It provides the same benefits as chargeback, but the main difference is that the costs are not actually billed back to the organization. That’s the main difference. When it comes to reporting, you generally want to look at how you’re going to report on chargeback and Show back.

Some organisations like to have a company-based policy, some like to use a cloud provider-based policy, and some like to use an SLA-based policy. The main difference is that if the company is going to create the policy, then whatever the goal of the organisation is for performing chargeback and showback, those processes are going to follow whatever the company policy is. For example, every quarter it needs to provide a report to, say, the CIO. Again, it could be as simple as that, or it could be more complex; whatever it is, you have the cloud provider policy. This is usually driven by the cloud provider, who can A good example would be going into Google Cloud or Amazon, but let’s just say Google, and creating what’s known as a project. And that project could be the policy that’s set up for that organization. So development, production, legal, human resources, and so on, and create individual policies based on the project that is being established. SLA-based is really based on the SLA itself for that application.

Now once again, there’s different approaches. Whatever works in your organisation is certainly up to you to appreciate and implement. When it comes to Amazon webservices, Amazon does have some indirect options for performing chargeback and showback. You could also use a third-party vendor like Cloud. Ability is a good example. You could set up what’s called the “Linked” account. You could also use tagging. Now, Google Cloud is a little different in that you have the ability to create organisations and projects. And like I mentioned earlier, projects are probably the easiest way to use the cloud. Google does a really good job at this, separating those resources and creating a container that you could prioritise under what’s called an organization. Of course, many of these functions will be dependent on whether you use Google Cloud for work, Gmail, or whatever services you use with organizations. But projects can be used immediately. When it comes to chargeback, just remember what it is. It’s a policy of allocating the cost of the organization’s centrally located resources to the individuals or departments that use the resources. Here’s an exam tip: make sure you know the difference between chargeback and showback.

8. Application Lifecycles

Application lifecycles. Let’s go ahead and briefly discuss application lifecycles and why they’re important for the Cloud Plus exam when it comes to managing your applications. Generally, your development group should have some kind of ALM setup, which is an application-like lifecycle management approach. This is essentially the supervision of a software application from initiation to retirement. Now, essentially, what should happen is that these applications that are being deployed in the cloud are going to be specified, developed, tested, deployed, and maintained. The ALM will essentially refer to how changes to the application are documented and attracted. For example, SDLC is a popular approach. Tools from different vendors are out there. When it comes to app development, there’s generally a shift in how applications are developed.

A lot of this is due to the fact that mobile and cloud applications are generally written using more rest API approaches,  but devops has also played a major role. A lot of factors go into this. For the exam, though, I want to make sure you understand that when it comes to development lifecycles, this represents essentially a shift from static configuration to on-premises deployment to more of a cloud approach. The goal is to be able to react, and this is essentially DevOps. SDLC is what they’re talking about, and they just want to make sure that you understand that life cycles are out there and are going to be utilised in cloud environments. It’s a good practise as well to deploy these solutions in multiple cloud zones to eliminate the failure of a specific cloud platform serving a single zone. And what they mean by that is that you don’t want to just deploy your production app in one zone. If there is an issue, then again, shame on your organisation for not having redundancy if that is a true production application. Again, from a testing perspective, just be aware of what a life cycle is when it comes to business requirements. Just be aware that businesses change, get bought, merge, are sold, and go out of business.

And because of that, the business requirements will change. So therefore, enterprises really should choose a life cycle where it’s easy and rapid to migrate, retire, upgrade, or deploy resources. For example, the last few years have proven to be pretty dynamic not only in the tech world but also in the financial world. There have been numerous mergers and acquisitions, for example. And I can tell you right now that a lot of companies, when they merge, have almost no real synchronization, if that’s the term I want to use, between their applications that are essentially in-house, essentially. So this poses some challenges. Application lifecycle management is the supervision of a software application from its initial planning through retirement. So remember, ALM for the test. And here’s a test tip. It’s a good idea to deploy the solution across multiple cloud zones. And the reason you want to do that is to eliminate failure in that single zone. That is ALM. And one of the questions in the test I did see was sort of interesting, where they gave you a scenario and wanted you to select the right solution. Again, you don’t want to deploy an application if it’s production-ready in a single zone. You need to have multiple zones. That’s the lesson learned here.

9. SLA Management

SLA management. Let’s discuss why managing your service level agreements is critical to your organization’s success in the cloud. When it comes to financial management, one of the challenges that typically confronts the average technical worker is understanding areas around financial management like accounting, budgeting, and charging. These are areas in the cloud that, generally, the average IT architect, VM administrator, and cloud administrator now have to be aware of because, again, if you’re in traditional infrastructure, you’re not worried about a lot of the financial areas.

But when you move to the cloud, this changes significantly because every month you’re going to be put in a position to justify these OpEx expenses in a lot of cases. For example, how do you justify the same type of usage in the cloud, and then one month your bill goes up 30%? And again, a 30% jump in resources is significant. You jump from, let’s say, $5,000 a month to, let’s say, seven and a half, $1,000. This can be noticed pretty effectively. And this is also where you have to start looking into why we are using more resources. Do we need to look at charge back? Do we need to look at making sure our user base removes resources they don’t need after they use them? This is where I think the major challenge comes in for the exam. Just be aware that financial management is going to provide accounting, budgeting, and charging. Now let’s talk about what an SLA is.

Now, I know we talked about an SLA early in the course. This is an important area in the cloud, and that’s why we’re going to talk about it again. An SLA is an agreement between a customer and a provider that states an agreement on what to measure and why, how to measure it (KPIs), and how to use and validate results. One aspect of cloud management is ensuring that your organisation receives the appropriate resources based on the SLA. In other words, is your uptime four nines? Is it three nines, two nines, or whatever it is? Hopefully it’s not two nines. But if it is two nines, for some reason, does your SLA state that you’re going to get some kind of credit back or bill credit? This is money for your organization. So you, as the cloud administrator or cloud guru in your organization, need to pay attention to this stuff because you could be leaving money on the table for your company if you don’t pay attention. When it comes to SLAs, there is a best practise in the industry to use what is called the “smart approach.”

Now make sure you know what the smart approach is before you take the Cloud Plus exam. Basically, the acronym it stands for is as follows: specific, measurable, agreeable, realistic, and time-specific. Basically, an SLA should be detailed in the sense that it specifies what you’re going to measure. that what you’re measuring is actually measurable. For example, both parties agree that uptime can be measured, that it is realistic, and that it is time-bound. How, for example, is uptime measured? Right. Is it going to be sampled every day, every hour, and every month? Whatever is going to be sampled when it comes to ITIL Now, this is not something that’s on the exam, but I threw it in there because a lot of the organisations in cloud environments use ITIL. ITIL has some really good, what I would call “toolsets” or “approaches” to SLAs that can be utilized. And there are three types of SLAs in ITIL. There are three types of models: customer-based, service-based, and multi-level. Now, I’m not going to go into detail about what these are because, once again, they won’t be tested in the exam, but I want to make sure that if you’re an ITIL organization, these are some areas you go back to in reference to your ItIL structure and determine whether or not this is something you’re going to use in your environment. KPIs.

Now, KPIs are key performance indicators. This is a measurable value that will demonstrate how effectively a company is achieving its business objectives. For example, one of the things that a KPI should do is be really measurable and clearly defined. Specifically, uptime, response time, round-trip time, and latency. These are things that you can measure pretty easily when it comes to cloud-specific KPIs. Some of those KPIs you’re going to see regularly are going to be around availability, workload utilisation, resource allocation, and response time. Those are pretty common. Make sure you know what an SLA is. Again, this is an agreement between a customer and a provider. Lastly, here’s an exam tip. Make sure you know what Smart stands for.