CompTIA Cloud+ CV0-003 – Domain 1.0 Configuration and Deployment Part 2

  1. Cloud Architecture Analysis

Let’s go ahead and talk about cloud architecture analysis. It’s critical to understand a few things in this specific subdomain. The first is that “cloud architecture” refers to the components required for the cloud platform. These components are part of the front end or the back end of the cloud. Cloud computing, for example, is a more comprehensive approach. When it comes to migrating applications, it’s important to consider both the front end and the back end. Now, of course, as the customer, you’re not going to have too much access to the back end other than the API and setting up your resources. Again, the provider is going to provide you as a customer with the requirements to set up Amazon S3 the way you need it, or set up Google App Engine, or set up Microsoft Virtual Machines, whatever you’re trying to do. When it comes to cloud architecture, you want to look at the front end, the back end, as well as the networking. So generally, the front end is going to be how you, as a user, connect to the cloud service. That will typically be APIs as well as a mobile device, laptop, or desktop; whatever you use for the backend will also be the provider. Of course, that’s going to be their service that you’re going to tie into.

So, if you’re going to connect to Google Big Query, BigTable cloud storage, cloud spanner, or whatever you’re connecting to, you need to understand the connectivity requirements, any kind of configuration variables, and the programming languages that are supported, whatever networking it is. Now if you’re going to set up, for example, like an Amazon, a virtual private cloud, you need to understand that there are going to be technical requirements for your network, and they do need to be met to have that VPC functional and supported. When it comes to service models, again, you want to look at the different service models appropriately. The main thing you want to understand for this specific exam is that when you’re analysing a service model, you want to understand that that service model is, of course, deployed by a service provider. That service provider is going to give you specific requirements for setting up and configuring that cloud service, and it’s tied into your internal services. So, for example, it is very common to have customers go out there and set up a hybrid cloud. Hybrid clouds are great as long as you set them up right. So again, you need to tie in database services. Let’s say, for example, that you may have in-house applications, and those in-house applications may use, for example, a data warehouse that’s internal.

But you may want to have the service analyse mobile data, and that mobile data might be analyzed, let’s say, in GCP. So, for example, you may want to use Firebase services or other services such as PubSub with GCP, as there are many different variables to consider. Again, remember the characteristics when you’re looking at and analysing your architecture. Again, these five characteristics are going to be tested on the exam, and you do want to know what they are. Cloud Design When it comes to cloud design, it’s important to understand that architecture generally needs to address on-premise clouds but also off-premise clouds as well. Another quick note is that it could also be hybrid. Again, whether on-premises or off-premises, I see more than enough businesses leveraging on-premises services and integrating them with cloud services.

So, for example, you may have specific requirements. In this case, let’s say you want to go ahead and tie in Google Cloud SQL, okay? So Cloud SQL is essentially a relational database. And this relational database could be used for many different purposes, but generally, it’s relational. And so let’s say you have a transactional application. This transactional application may be hosted in-house, but data may be stored on Cloud SQL. Or, better yet, you may want to use CloudSQL as a point to run your relational database, but then you want to warehouse that data. You could also send that off to another service to be analysed or archived, whatever you need to do. So once again, there are many different options to consider. What are some of the best practises you want to use when designing for scalability and elasticity? You want to implement, automate, and orchestrate everything you can, right? Your time is valuable. You don’t have time to be manually entering stuff if you don’t need to. Again, it also reduces errors as well.Of course, automation has a big purpose in the cloud. You want to manage services, not servers. You want to optimise costs, but design for performance.

So, for example, you may have 50 terabytes of data on Amazon. Amazon, of course, has many different types of services and many different types of storage. For example, you may have data stored in Amazon’s three, but maybe that data is not actually archived yet, and it’s not even being used. Maybe you go out and archive that data into Glacier, create a Glacier volume, and archive it. It’ll reduce the cost significantly, as long as you don’t have to access it. So that’s sort of the benefit of Glacier. It’s really cheap if you don’t have to access it. Security is a priority. Once again, as I had mentioned earlier in the class, if you really need security, you don’t go to the cloud. And I know that a lot of vendors, a lot of partners, and a lot of customers believe the cloud is more secure than having something in house. And that could be true, especially if you’re an organisation that manages security poorly. Maybe it’s better to have someone else manage it for you. So it could be a better situation. But, once again, security, in my opinion, requires close scrutiny. Remove the single point of failure. Examine your architecture to see if load balancing is enabled. Check to see if your virtual machines have auto scaling or other features.

Also, to try to determine networking routing and look at how something gets routed, Cloud components. Again, different components necessitate special attention: the main areas are servers, storage, and networking. Also, again, you need to look at APIs as well. It is also necessary to comprehend capabilities. There are a lot of different things to look at. Okay? So when it comes to architecting a cloud, always refer to the cloud provider’s best practices. Know how cloud characteristics play into design. That’s really probably the main thing you want to know about this module. For the exam, there’s going to be a couple of questions, and I’m going to go through some practise questions at the end of the course to help give you an idea of the type of questions that you can expect on this exam. But generally, you’re going to look at a situation and try to figure out what you would do to address that problem for the customer. For example, if the customer doesn’t have business continuity, what about RPOR? How do you address that? Right? Other characteristics. Again, maybe the customer really doesn’t need that type of storage. Maybe they’re in the wrong type of storage. Maybe they have the wrong virtual machine image. Who knows? It could be many, many different things. Let’s carry on.

  1. Implement Deployment Plans

Okay, well, let’s go ahead and talk about implementing deployment plans. Okay. One of my favourite subjects There’s nothing more fun than rolling out cloud services. So this exam of course will test yourhigh level knowledge of rolling out services.

Looking at deployment plans and areas of that nature. Let’s talk about what “rapid deployment” is. Well, rapid deployment is essentially more of an application-based approach where you provision resources to the cloud efficiently. And this is something that comes from the development world, where you would create a service, and part of that development process would be to get that service rolled out quickly and efficiently. Now rapid deployment—again, you want to know what this means. It means, essentially, at a high level, the ability to provision resources to the cloud efficiently. So if you’re on a development team, one of your priorities is, of course, to develop a solid application that’s tested and ready to be deployed to the cloud. When it comes to deployment facilitation, there’s orchestration, automation, and migration. These are areas that you generally want to focus on. Now orchestration is what this is going to be, essentially taking automated tasks and making them work together to deploy these services. For example, if you have VMware, you have the orchestrator services. So, if you want, you can use the VMware orchestration set to orchestrate all of your automated tasks. Also, Google and Amazon both have tools that you could use. You could also use other services, especially in-house developers who love to use puppet, for example. Chef, you see that quite a bit as well. migration, for example. If you want to migrate from Amazonto Google you can do that.

There is a migration tool that Google has that allows you to do that. sort of interesting. Again, you want to look at how you’re going to migrate that service, whether it’s to the cloud or from the cloud. Some of the best practises involve using the right methodology. When it comes to methodologies, there are certainly many different approaches to consider. If you work in development, you may be interested in learning more about the agile practises you employ. So if you’re in other types of organizations, you may be using a lot of those frameworks. Best practises have methodologies that you could use to address deployments and roll out new services. You could also look at, for example, using containers. There are different approaches you could use there as well. You want to use correct planning. You want to make sure you have a project plan in place. You want to validate everything before you deploy it. You want to make sure you have a good baseline—that you know where you are and where you need to go.

That’s really the best situation to validate and confirm the use case. That’s all part of the validation process. Some of the considerations would be workloads, network bandwidth, user training, and stakeholder buy-in to resources as well. So, for example, if you take a workload that is sequential, that sequential workload is going to likely require different network parameters as well as resources to perform the way that your users would expect it. Whereas a transactional application may not require as much overhead as, say, something that has a peak workload. So you need to look at your workloads in detail. For instance, if you work in retail, this is a great example. Retail, as we know typically, and again, I’m going to speak for the US and Canada because that’s what I’m familiar with, but I assume it’s fairly true overseas as well, is where a lot of the demand is around the holidays. As a result, Christmas and New Year’s You have Black Friday and Cyber Monday. If you’re in retail, you may need to scale up your resources to address the workloads that you’re going to run into. As a result, you must understand not only your average workload but also your peak workload. Typically, you want to design these types of systems for a peak workload. User training—yeah, user training isn’t that wonderful.

So it’s funny because the longer I train, the more I realise a lot of organisations just don’t want to train their staff as much, and this is what we’re seeing. So I’m sure a lot of you are here because your company may not provide appropriate training. Now again, user training is important. when you’re deploying a new service. You need to let the users know how to access that service and how to use it efficiently and effectively. Any documentation really needs an acceptable use policy. A lot of other things we’re going to talk about in further modules will be, of course, the service model, the deployment model, and the essential characteristics. So, for example, the way you deploy to a private cloud may be very different from the way you deploy to the public cloud. Again, you may have full bandwidth and full control of your private cloud, whereas in the public cloud you don’t. When it comes to deployment planning, it’s important to understand the use case, confirm the workloads, and also assess the provider. So, for example, when it comes to understanding use cases, you want to understand why your organisation or your customer is actually going to the cloud. Is it because of functionality? Is it because of economics?

Is it because of security? Is it because of performance? Is it to provide new capabilities to the organization, whatever it is? Now every cloud provider is going to have a whole bunch of different cupcakes for you to choose from, especially when it comes to infrastructure as a service or even platform as a service. And what I mean is that if you compare each of the providers against each other, there’s a tool called the right scale cloud comparator that you can use to understand not only the capabilities of each provider, but also what they support and what they don’t support. So you want to look at the providers in detail. For example, you may require specific operations for specific applications. Maybe one provider doesn’t support it. Perhaps you require specific types of big data workflows to be supported by all of the major providers. But maybe there are specific workloads or Apache options that may not be supported by Google or Amazon. So you really need to dig into the details and minimise complexity, right? The simpler the better. Portability. Can you go ahead and take that service and move it over? Again, your developers really should be developing the application to be as portable as possible.

What I mean is, for example, that most cloud providers are going to support languages like NodeJS, Python, and PHP, right? All those are widely supported. But maybe there are specific versions that are supported by all the providers, for example. But if your developers choose to go with an unsupported version, let’s say on Amazon, and it’s only supported on Google, that could affect the portability of that application, right? when it comes to deployment planning. Okay, create a plan. So, pretty straightforward, right? Before you do anything, you have to create a plan. You have to know where you are and where you want to go. You want to designate a project manager. Now, when I’m working on a project, I frequently encounter this. I wouldn’t say all the time, but routinely, you’re going to have organisations that somehow decide to take services to the cloud and not have a project manager. And the architect is usually the one dealing with everything. This is not fair to the architect, and it’s not fair to the organisation as well as the users as well.Because what typically happens is if the project falls behind or something goes wrong, guess who they’re going to blame? The cloud architect So you need a project manager to be the middleman, right? To be able to sit there and say to the developers, “How are we doing on completing your tasks?” Are we on schedule? You need someone to talk to the architects.

How is the migration going? Are we there yet? Is it set up for the developers or is it not? You need the security team to do their part. So these are projects that need to be managed as a project.When it comes to deployment planning and change management, you need to look at and understand any approval processes. And again, you want to have that plan ready, right? When it comes to deploying to the cloud, you need to consider, of course, servers, storage, and the network as well. Once again, these are components; we talked about them briefly. We’re going to talk more specifically later about, for example, memory and CPU storage, as well as networking. But we want to make sure that you understand that each of the components can play a major role when it comes to architecting, deploying, etc. So again, all of these could be issues to deal with when you deploy a cloud service. Usually, this requires concise and efficient planning. Let’s go ahead and talk about an exam tip. Rapid deployment is a common method used for cloud migrations. Let’s proceed.

  1. Change Management

Change in configuration management. So this is an area that I think is important to definitely understand because, of course, on the exam you’ll get tested in certain areas. Now, change management is essentially the process for managing upgrades, installs, and removals of configuration changes and IT or cloud resources. Now, it’s important to understand that you have configuration management and change management as well. So let’s talk about some of the differences as well. With configuration management, this is more about the configurations. For example, what kind of images do you have, what storage configuration, networking configuration, and configuration control do you have? And also, it’s generally part of change management. Now change management is more focused on documentation, such as change requests and asset control, and usually you’ll have a CMDB that’s going to be your change management database.

Now for the exam, you’ll want to make sure that you know what a CMDB is and why. We have a CMDB. Again, things are fairly straightforward around change management and CMDB. I assume most of you have that experience, but remember that a CMDB is generally going to be considered a central repository where you’re going to use a central repository in an organization, and generally, you’re going to use this for your configuration management documentation of its assets. Generally, the CMDB is going to track inventory as well. Generally you’ll see documentation around serial numbers, asset locations, could be data center locations if you’re a larger organization, any kindof maintenance agreements as well. Sometimes the CMD is important, but just be aware of why we need one for this exam. Approval Process:

So there really needs to be an approval process before changes are made. Now, do you need to have formal approval for every change? There really should be ways of identifying different levels of change. In addition to a backup plan Now, a backup plan is what you have if you make a change to an image and deploy it, and for example, the startup script does not start up as expected. Do you have a backup plan? Are you going to go back? Are you going to identify another image? To use? In lifecycle management, it’s very common to see ITIL in a fair number of organizations. It’s a very popular reference framework. You don’t need to know much about ITIL; just be aware that it is a reference framework. Monitoring. So once again, you need to monitor your changes and track changes. You want to compare it to the baseline as well as identify, for example, trending data. Now, trending data is generally going to be accumulated, or as I prefer to call it, obtained or received from network monitoring. You’re going to typically have analytics that are going to be used. So for example, a lot of organisations may use Splunk to replace other tool sets that are out there that collect a lot of data, and you get to analyze, for example, how this application is performing over a period of time or at certain times of the day. A common issue is around geography, especially with content delivery and maintenance windows.

So you definitely need to have a maintenance window. Now, there are two types of maintenance windows. There are scheduled and unscheduled times for the exam. You may want to know the difference between the two. and it’s very simple. Scheduled is what? “Scheduled” means that you are planning to do this. You’re documenting getting the appropriate approvals for the maintenance window. So generally, too, you want to communicate this maintenance window to everybody in the organisation that needs to be notified. Unscheduled is generally going to be used for emergency maintenance, for example. So, for example, if you’re rolling out new patches and these patches are not critical to your host OS, they’re more for the application. You could probably do it on a regular basis, but suppose it’s a firm or issue. Something isn’t working out right, and typically, that could be more unscheduled. Generally, unscheduled maintenance usually results in downtime, based on what I have seen. So again, just be aware of the two types. Change management uses a CMDB to track and maintain changes. Here’s an exam tip. Remember that there are two types of maintenance windows. There are scheduled and unscheduled events. Let’s proceed on to the next lesson.

  1. Standard Operating Procedures

Let’s proceed and talk about standard operating procedures. As with any technical environment or technical service, the cloud is essentially a technical service where, again, if you’re going to update anything, make changes, or migrate services to it, you need a procedure to be able to do it properly. And the reality is, pretty much all the providers have very good operating procedures to enable you to get to the cloud. So we’ll talk about essentially why we need a SOP, and then we’ll talk about some of the differences between the providers as well. So a standard operating procedure is usually a step-by-step instruction. This is used to execute a specific task. So, for example, if you haven’t spun up a virtual machine in Amazon EC2, there are instructions on how to do that, and it walks you through how to set up the VM. It’s essentially an instruction set that you’re going to run. Now, the standard operating procedure is there for a reason.

The first is that you want to make sure that there are detailed instructions and that the quality is there, as well as inducing efficiency into the process. So if you don’t follow instructions, you don’t get it done quickly, and it’s not very efficient. So follow the instructions. That way, everything should work out and reduce mistakes. Now, each of the cloud vendors and providers has different names for their SOPs. For example, AWS calls them operational checklists or best practices. GCP likes to call them a “launch checklist,” and Azure likes to call them “checklists,” depending on the use case. You don’t need to know this particular page for the exam; I’m just pointing out that the SOPs are labelled differently, and I want to make sure you’re aware of that. Remember to follow the instructions. It’s important when you are looking at deployinga cloud service or deploying a new VMor adding new storage, follow the proper procedures. This will enable you to remember to increase your efficiency, reduce mistakes, and be more efficient at your tasks. Right? Just be aware that the SOP is there for a reason. There’s not much else to say about an SOP, but just remember that an SOP is used to specify a detailed process workflow.