We’re basically understanding total cost of ownership. So the real world advice that I have would be almost all organizations ask for total costs of ownership and return on investment, TCO and ROI, and it’s absolutely imperative we’re able to understand that as Cloud-based professionals needs to exist before the migration can begin, and ultimately, this is about you creating the business case. This doesn’t mean, by the way, that we have to have MBAs or be business geniuses. This just means we have to understand how to add, subtract, multiply, and divide, able to determine the business case to understand how the technology’s going to be applied. So this is the value metrics by which you’ll be measured against. Keep in mind as you provide leadership with key metrics, such as total cost of ownership and return on investment, that you’re going to see those again.

So if you’re promising, say, a 50% return on investment in the first two years of utilization of Cloud computing, chances are that’s going to pop up somewhere in your future, and you need to be able to answer for those. So, total cost of ownership or return of investment, we need to do the cost calculations pure TCO, total cost of ownership. In other words, what it’s going to cost us to run this thing first year, second year, third year, five years down the line? And what are the metrics as to total cost of ownership for applications, for databases, for Cloud instances? How does that differ from total cost of ownership now, with their traditional on-premise systems as move into the Cloud. We have to figure out transitional cost. In other words, what it costs to get us from the existing traditional systems on premise into the public Cloud-based system. And that’s going to be critical, because they’re going to look for those costs to be recuperated over time. So in other words, there has to be a business reason for moving into the Cloud, and ultimately, they’re going to look for that money to come back over a period of time. Is it going to be one year, two years, five years, 10 years, maybe never? And then finally, full program costs versus value calculations have to be there.

So once we figure out what it’s going to cost us to move to the Cloud, and we understand the operational costs, we understand the migration cost, we understand the refactoring cost, we understand the changes of security that needs to be made, changes of governance that need to be made, performance management and operations, the list goes on. Ultimately, this is about you looking at what the costs are versus your value metrics, or what you consider to be the value points that need to be determined, including agility, compressed time to market, you know, cost savings, things like that. That all goes to the reasons that we move to the Cloud. And then from that, you’re able to produce a set of metrics, or a set of predictions as to what value is going to come back to you, to the business from the use of Cloud. So value realization, you got a couple of things to consider, and this is just an example. You know, we may have improved agility, while in some cases, if you’re a tire manufacturer in the Midwest, your ability to do things faster or to change faster may not have the same value as if you’re a bank in New York, and so we weight it accordingly. And say this one is 92 out of 100, And the ability for a manufacturing company who does custom fabrication, for example, to automate a Cloud business process which allows customers to, in essence design their own fabrication online, and have the thing directly shipped to the fabricators which are able to automate the production of whatever they’re looking to fabricate, and there’s the ability to, in essence, remove some of the steps that business has to undergo to get to a revenue-generating event, and ultimately, that’s what Cloud computing provides. And finally, your ability to decrease costs. In other words, ultimately, is cost really a big issue for you? You’ll find that in the financial industry or other industries that have access to a great deal of resources, cost isn’t really as much of an imperative as somebody that may be in the retail space, for example, where cost goes to how much margins they’re able to charge, ultimately goes to the success of the business.

Make sure you do a couple of things. Number one, current state assessment, where you are now. Future state architecture, where you’re looking to go and estimates in terms of how those architectures are going to change the cost model. That leads you to the total cost of ownership model, or how much is it going to cost you going forward, and then finally, the business benefits, ROI. Your ability to, in essence, assign different ROI characteristics and understand the weight that you’re putting toward those characteristics in terms of expectations, as well as the reality behind the business. So, current state assessment, we do application inventory estate-level assessment in terms of what the existing as-is state is doing, sample application assessment, full estate inventory, in other words, what’s happening within the enterprise currently. Application migration approach we’re going to leverage.

Next, we get into service levels and operational environment assets. Current infrastructure and operational costs, current state architecture qualities and requirements, availability, security, compliance, scale, performance, resiliency, and current state operational model and processes. So the top five TCO/ROI overlooked areas you need to consider as well. In other words, areas where people who are Cloud professionals may go wrong. First, is the value of agility. We often get that wrong, because it’s very difficult to determine what the value of agility really is within a particular business. I can tell you that it’s typically undervalued. In other words, people don’t consider agility as much of a valuable asset than it is, even if you’re a manufacturing company that hasn’t changed a lot in the last, you know, 50 years, you may find that having the ability to change will enhance the business. Cost to retire selected applications, infrastructure, or data centers.

People don’t understand what are the tax issues around retiring, or putting an application away, or basically stop using hardware? We may be depreciating existing on-premises hardware systems in such a way that actually moving to the Cloud, even though it may be better for the business in other ways, may cost us a great deal in the sacrifice in terms of the tax benefits that we’re going to see. Changes required to maintain service levels. In other words, what you have to do to, in essence, get up to the service levels that we need to provide in the Cloud, and what changes need to occur to get there. Software costs, how much the software is actually going to cost, both on-premises as we change things, but also considering moving to the Cloud. How much is the software going to cost, say, running Oracle on-premises versus running Oracle on Amazon Web Services, for example. And then organization transformation costs. In other words, what it’s going to cost to change the personnel, what it’s going to cost to change the organization, change the structure, change locations as to where people are going to be. All these sorts of things are typically missed as we migrate into the Cloud. So, these often overlooked, but it doesn’t have to be overlooked by you.

Migration planning

So now, let’s talk about the wonderful world of migration planning, and again, the old adage, if you don’t have a plan, you’re going to plan to fail. So, the advice that I have would be migration planning must be detailed out ahead of time. And so, as you’re looking at your current state and where your to be state’s going to be you need to make sure that you’re going to, in essence, provide a plan as to what are the major steps, how to do it, and how to carry it out, and the resources you’re going to need. If you don’t have a plan, you’re not going to be as effective as those who do, and while it’s boring and often monotonous to actually create a plan for migrations because you are thinking about very detailed things and not necessarily new and exciting, it’s absolutely an imperative for you to be successful. Make sure to learn as you go, and for most this will be the first time you’re moving to cloud, and so, you’re going to be entitled to make mistakes.

You’re going to be recovering from those mistakes. You’re going to have to set up a culture as you migrate to the cloud as to the fact that people aren’t typically going to be punished for making mistakes. So, keep in mind we have a couple of things that we’re doing with the existing applications that are on premises. Number one, we’re replacing them. We’re reusing them. and we’re going to reuse it in a way Replacing means we’re just outright replacing the application. the same business processes and we’re replacing the software which means we’re changing portions of the application. cloud platform we’re moving to. Replatforming, in other words, as we’re migrating and that just means we’re leveraging a new operating system, perhaps new memory models, new storage systems, things like that, because we’re looking as to how in the public cloud. Rehosting means we’re just lifting and shifting, and so, in other words, we’re picking up the application code and typically the data which may be bound to the application or loosely coupled, and we’re moving them to platform analogs, or basically the same platform on the public cloud. And so, we may be running on a Linux system on premises and we’ll move it to the same Linux system that exists in the cloud and the same databases as well.

And so, what we’re trying to do here is minimize the amount of work that we’re doing to, in essence, and this is the fastest way to move, and leverage some of the cloud native services. And then retain, in other words, we’re just keeping the application where it is, and in many instances an obligation to move everything to the cloud, and there are applications that just aren’t cost effective to move to the cloud, such as legacy mainframe systems. and therefore moving them to the public cloud can be You know, as I’m going out there and working with enterprises I’m finding that as many as 10% of the applications that are currently in the portfolio haven’t been used for the last five years, and, but they’ve been maintained, and backed up.

So, it’s a matter of auditing the existing application portfolio and finding those applications that aren’t necessarily being used, or may not be providing value for the business, and just sunsetting them, and retiring them, in other words, take them off the platform. Sometimes they may be replaced, but most of the case, we’ll just shut them off, and they cease to exist and the business operates just fine. What’s key here is that you estimate the application migration resource level you’re going to need over time. So, in this case we’re looking at 2014, ’15, and ’16, or the full time employees that we’re going to need to, to the right at the same degree, or the same pitch that you see on the particular graph right now because we’re obviously going to increase costs We’re going to increase use of platform. redundant costs for some time.

There is an accordion of cash you need to spend in order to make the migration into the cloud, and it’s typically going to be increasing at least until you get the first 50% of the applications and databases migrated. So, you need to understand the relative investment and value over time. So, the more we invest, we should accelerate the value that we bring to the organization, and you have to remember that moving to cloud in many instances, even though we have tactical end goals, in other words, the ability to spend less money and the ability to leverage more modern platforms, the ability to be more agile, the ability to compress time to market, all these sorts of things is tactical goals. Ultimately, this is about increasing revenue, increasing innovation, and making the business more valuable. You’ll find that a technology company that able to leverage cloud computing as a technology is typically going to get a better valuation cloud computing, and the reason is So, a couple of things that need to be done. and system integration points that exist and migrating to. Determine an integration strategy for internal and we talked about that in terms of TCO and ROI, as for migrating into the cloud. But this is where we say the how, in other words, how we’re going to do it, what platforms we’re going to move to, what tools we’re going to leverage, the processes we’re going to leverage.

Select a cloud provider

All right, let’s talk about selecting you know, versus understanding the requirements and a lot of the things we’ve outlined thus far in the post. So even though I’m going to walk you through how to pick a provider, the business needs, the value that it brings to the business, and then, backing the appropriate technology into those requirements. Cloud providers all differ in features and functions, and so, they do things differently in terms of how they do storage and compute, and now, the cloud providers have basically gone after feature and function wars between themselves, and they’re building different services that do different things, and so, while cloud computing providers, certainly infrastructure as a service providers, you know, such as Amazon, Microsoft, and Google, networking, storage, compute, platform support, things like that.

Now, they’re basically into everything. So artificial intelligence and machine learning, In fact, they’re typically turning out between 10 to 20 services per month, and therefore, it’s up to you as a cloud computing professional to keep up and understand where these things are going. So need to look at your own requirements and if you make a mistake, just try again. Ultimately, this is not about you winning some sort of a game and that we’re going to iterate through this in the fact that we’re going to try to make the right decisions, and cloud providers in general, elasticity and scalability. dynamic scale-up and scale-down of resources, seamless support of multiple clouds, flexible resource quotas, all these things really need to be fed and how we evaluate this technology. Such as role-based access controlled governance, image lifecycle management, and how that folds into monitoring and management of the system. into all cloud endpoints, and how do we do that? Robust self-service catalogs, end-to-end automation, support application programing interfaces to communicate with one another, and then, how do they support agility? Are they doing self-service resource provisioning? Your rapid elasticity. In other words, are we able to get the resources in line as quickly as we need them? And by the way, are we able to scale those resources up as we need them and scale them back as we don’t need them? Capacity on demand basically ensures resources are always available, and it’s a protection for us running out of resources.

Rapid disaster recovery, active-active application support or the basically, the ability to keep two systems running in a redundant state. One’s the primary, one’s the secondary, so we basically never go down, and then, finally, seamless support for different endpoints. Then cost, we have metering and chargeback. In other words, are we going to have the ability within the cloud system to understand who’s incurring what costs and how they’re charged back to different organizations or how they’re billed internally or billed externally? Pay as you go, your ability to, in essence, move this through as an as a service model. Consumption-based, and reliable asset tracking and usage reporting. This is an example of an analytical tool that allows you to pick different public cloud providers that are out there. In this case, we’re evaluating AWS, Microsoft, Google. Typically, you’re going to go through this kind of an evaluation ’cause typically, you’re going to have to pick an infrastructure as a service system to make it happen, and as you can see, up there, we have the disruptive vectors, storage, provisioning, management, governance, networking, compute, and security, and then, we gave them relative importance to us, the client. In other words, I gave everything 15% and one 10%, but you can allocate those in different ways.

If the security, for example, is very important to you, As to the different weights or the different scores, we’re able to provide the different vendors, in this case, AWS, Microsoft, and Google, as to the different disruptive vectors we outlined above, and what you’re looking at to get out of a public cloud provider, that may change, and this is just a representation of what we just saw that looked at the various AWS, Microsoft, and Google, and how each of these cloud providers these disruptive vectors, these ways of evaluating things that are important to us as those who are going to be consuming this technology.

Establish cloud security

Now let’s look at understanding security. So, a couple things to consider here is that clouds are basically complex distributed systems at the end of the day. So, ultimately, this is about an existing architectural pattern that we’ve known for a long time, outside the enterprise on different cloud platforms, and certainly very complex distributed systems that we’re basically living with today as we’re moving into cloud. So, we have to figure out a way to secure those. Need to look at your own requirements. Again, this basically drives everything in terms of how you pick anything, including security. And the most effective security is proactive security. Your ability to, in essence, put things in place that are able to adjust to things such as an attack occurring, basically, spotting that as to some sort of a monitoring capability of looking at how we’re looking at particular processes and be able to take evasive action.

So, Cloud Security Maturity, Risk and Agility. including how we’re reactive and point products that we’re leveraging. Have to look at layered tools, help people react faster. Have to look at integrated tools. Correlation analysis, things like that. The ability to kind of spot an attack that’s occurring because something’s occurring that’s also correlated with something else and having that as a known pattern of an attack, and therefore we can take things and take evasive action. Situational context and common management as well. We help identify and remediate risks, and automate responses. So, your ability to be proactive, which is a key element to cloud security, is your ability to react ahead of time, before you spot a breach. And so, this is not about security systems by looking at different patterns that are emerging, becoming proactive in how you’re dealing with security. or trends that are occurring today, but we can also be predictive. We can actually look into the future as to what’s going to occur based on the patterns of data that we’re seeing. Based on breaches, based on IP addresses that are being turned away from our particular cloud provider, and be able to log those and really kind of assess a larger and greater threat through predictive analytics is basically a weapon to defend yourself against cyberattack.

So, a couple of things. We have the business domain to consider. We need to find security-related business processes Application interface security, audit and assurance, business continuity and operations, change control, define security-related business processes and policies but do so at a business level, without having to assign everything into a particular breed And then the technology domain, which solves the business problems that we just brought up, In security governance domains having to do with technology, we deal with the security architecture, security infrastructure, technology policy, technical standards, tools and technologies, protocols, processes, procedures, data strategies, technical scope, technical functionality, technical requirements, and then translating business logic into programmatic logic, meeting conditions, configurations, schemas. All those things are going to be part of that, and security operations. We’re able to take the business understanding So, when assessing, or basically, we’re looking at three major stages. We’re looking at discovery where you gather all information from relevant areas to start to form a picture as to what the security requirements are.

You look at assessment. Analyze data gathered from discovery phase to uncover issues. Are we looking too much at encryption when we should be looking at identity-based security and management? All these are is basically terms that we deal with, security and cloud computing and different models and approaches, and in essence, when we understand what are requirements are at the discovery phase, the assessment phase will be, what are we doing now? What problems need to be solved? And what are, kind of, the patterns of enabling technologies we need to engage to make our security better? And recommendation, all the tools and technology you need to bring in to solve a security problem, and coming to a conclusion as to the requirements. What the requirements really determine in terms of patterns, or solution patterns, that we need to engage, and then recommendations, the final end-state technology we’re going to leverage.

New skills

Let’s look at the new skills we need for cloud computing. Couple of things to remember here is number one, you need to splurge on training. Ultimately, this is about you taking people in your organization that are loyal to you, and changing their skill set so they can adapt to the evolution and the adoption of cloud-based systems. Sometimes, however, you need to hire outside consultants for the first project and basically engage them as mentors, and so, they should be able to train people as well as doing things. And you have to remember that you’re going to have to repeat this over and over again for the next several years and the ability to understand or basically provide on-the-job training is going to be paramount.

Always evaluate and market costs for talent. Ultimately, cloud computing people are going to be expensive because there’s a scarcity of those resources right now and that obviously drives up price and we need to figure out what we can afford now and how best to gather the talent and get our best bang for the buck. A couple of things. We have cloud architects, as well as cloud developers, as well as cloud security engineers, and just as an example, by the way, and we have people that are Cloud Governance Specialists, Cloud Performance Specialists, Cloud Network Specialists, and the list goes on and there’s probably three or four dozen titles that we see out there in terms of cloud based professionals that are working on these cloud based systems. Cloud architects are probably the most hardest people to find because they have to have an array of skills. They have to basically know how to design, build, deploy cloud based environments, cloud based technology, and so therefore, they have to know a little bit of everything. There’s typically architecture certifications for big cloud providers such as Amazon Web Services, Google, or Microsoft, but basically, you’re looking for a breadth of experience that may go many years because they understand how things work on premise, how things work in the cloud, ultimately how to tie all these things together. Cloud developers are people who build cloud-native systems on cloud providers, and so, they may be an AWS cloud developer, a Google cloud developer, a Microsoft cloud developer. And what they do and the purpose for them is ultimately to figure out how to build applications as efficient as possible on the particular cloud platforms that you’re building them on. And then, cloud security engineer, obviously, cloud security is a paramount issue in most of the organizations, and people have the skills and understand how cloud security works, and how they work and play well with existing applications and net new applications is extremely important.

Cloud architects understand the cloud holistically, they understand the process of application migration, they’re able to guide the organization through it, they have good understanding of cloud providers. They may not have a detailed understanding of a cloud provider, like know everything about a particular native security system, but again, they just need to be good at lots of things, not necessarily an expert in specific things. And so, their ability to kind of divide and conquer is going to be to their success. Cloud developers understand how to build applications on specific cloud, are cloud-native, understand how to leverage cloud-native features. And then, cloud security engineers, they understand how to deal with cloud security solutions for the cloud, understand the security tools that are out there and the technology that’s available. And so, they, again, have to understand a lot of a lot of things, but they just focus on the security domain where the architect focuses on everything. The developer typically focuses on a specific thing such as a cloud-native application development tool that runs on a particular public cloud provider. You have to keep in mind that we’re adapting organization structures as we’re adopting cloud, and so, where it used to be acceptable to have a highly-structured organization, almost an autocratic organization, people are looking at organizations that are a little less structured and more flexible. Matrix organizations are, in some instances, there’s really no sense of an organization at all. That doesn’t mean that we don’t report to people and we don’t have a boss and we don’t have the normal things that we expect at work, but what we’re doing is allowing people to operate outside of whatever boxes we’re providing them, whatever job description we gave them, and this allows them to, in essence, look at a lot of stuff, engage a lot of people, and absolutely streamline productivity because there is no structural issue. There typically is no politics. We’re trying to eliminate politics. And there is no hindrance in someone getting something done, and also, there is no excuse for them saying that it’s not my job.

Your first cloud project

All right, let’s get to work, let’s talk about our first cloud project. So, a couple things to remember here is that, take on only a few applications at a time. Don’t try to boil the ocean, this is not a speed test. This is about you being successful a bit at a time, in some sort of incremental and repeatable way. Do a mix of new applications and migration, don’t focus all on one thing. If you build all net new applications, that’s a completely different set of skills. If you just migrate applications, that’s another completely different set of skills. You’re trying to get a mix of experiences, and scale that mix of experiences up over time. Make sure to follow the previous video, and get the talent you need. And make sure that you get the mentoring talent. Make sure you infuse a few people who’ve been through this before, and may have the experience and scars to prove it, before you’re able to, in essence, find the right path, ensuring that you’re listening to people that have been successful in the past. And by the way, this may be, you hire junior people that may not direct the organization, but may provide specific skills, for example, around governance and security, or this may be you hire a veteran guru of cloud-based systems to really kind of drive the various cloud-based projects that you have going on.

So a couple of things. Think small. Please don’t go out there and get those mission critical applications up on the cloud. This is about you experiencing things, and getting things up in the cloud, not necessarily about you, you know, showing everybody that you’ve put the biggest and baddest application in the enterprise up in the cloud, and you’ve slain the dragon. This is about you, in essence, taking incremental steps. So select only the workloads that will likely show success. Think simple, you know, don’t boil the ocean, pick the easiest applications first. One of the things that people recommend who have built cloud-based systems is that you look for something that, number one, is non-critical, and number two, is fairly simple in its function. And so you’re not going to port or build in that new ERP system in the cloud, or a custom inventory system in the cloud. You know, this is about you picking things like a credit check system.

You know, something with a very discreet functionality that you can port, move, build, in a very short period of time, to show success. So budget for mistakes. Make sure you allow enough time for errors, and keep in mind that the errors are going to be learning events. And so, we’re going to have to budget errors into the cloud migration thing, ’cause you’re going to make mistakes. You’re going to move things to the wrong platforms, you’re not going to get the performance you need. Some of this stuff is just going to be an honest mistake, some of this stuff is going to be issues, or lacking pieces of technology that we thought was there. So make sure you get approval from the top. So ultimately, this is about you getting acceptance from the stakeholders in the organization, that this is the right way to go. If you don’t get approval from the top, you in essence try to operate a project out of the way, on the down low, on the secret, that’s not going to result in a good outcome. No matter if you’re successful at migrating your cloud application or not. Make sure you are well funded. Moving to cloud computing requires lots of cash. We need to hire people, we need leverage technology, and by the way, typically, we’re maintaining and running our existing systems at the same time, so obviously we need people to maintain and run the existing business of IT, get those things up and running, as well as people to migrate applications to the cloud, to do the testing. To set up the DevOps organization, to do lots of things that need to be done at the same time, and if you don’t have the money, it’s going to be very difficult to do that, so make sure you get the funding.

So never be afraid to fail, and ultimately, you’re going to find there’s a lot of failure in this, and even in the out years of cloud computing, as it’s becoming more mature, and we understand more of the patterns of success as well as the patterns of failure, you’re going to find that it’s inevitable that you’re going to do things wrong, and so ultimately you need to have a culture of trial and error, and you need to have a culture of acceptance that people are going to fail at times. So now we have to get to work. So what do we have to do? Well, number one, we have to do cloud strategy and readiness, in other words, what’s going on with our current environment, and where the business is going strategically, and how ready are we to make the move to cloud? Next, we have to migrate to cloud, we have to go ahead and do it. What applications are we going to be most successful as we migrate into cloud, and how are they going to be migrated, and what tools and technologies are we going to leverage? Is it going to be simple applications, complex applications, important to the business, not as important to the business? All those decisions are made here. And then cloud enabled solutions.

In other words, once we get things in the cloud, and how do we leverage the technology via cloud native technology, or whatever features and functions that the cloud provider provides, to allow us to, in essence, create the solutions we’re looking to use, to revolutionize the business. And then finally, cloud managed services. How we’re going to operate things, how we’re going to, in essence, put the ops into cloud. The ability to, in essence, run these things in a day in, day out basis, and run them as mission critical systems.

Cloud Security:

Cloud security planning

It’s been my experience that security is the most important aspect of any cloud project. Unsecure clouds will fail quickly. Make sure you understand the security options, including certain security models, technology, and tools. Being proactive is the best defense, as we covered in the past videos. Make sure that you focus on monitoring and taking corrective action. It’s the most important aspect of cloud security. Cloud security requires that we understand the very basics, such as being reactive to the ultimate security solution where you can be more predictive, or spot issues before they become real problems. Using this maturity to understand the differences between the basic layer tools and integrated tools, then being proactive and predictive. Note that just after using the integrated tools that we reach minimum viable cloud security, which is good enough.

Most enterprises however set the objective to be predictive and thus more secure. Deal with the basics first. This means that we’ll set a foundation of security that provides the minimal amount of security we need. It’s important that this is the foundation else we might focus too much on the proactive and predictive stuff and could be vulnerable at the primitive level. Understand that the maturity model presented in the last slide is progressive, in other words, take it in orderly fashion. Be proactive, meaning that the heart of any good cloud security architecture and technology is the ability to spot issues before they become problems. By the time a hacker has accessed your data, it’s too late. But you can easily see how they progressed to the point and stop the attack before it becomes an issue. Drive standardization needed to achieve business benefits while encouraging adaptability, flexibility, and innovation. This means that we should leverage security standards, and there are many, but should do so with productivity in mind. If using a standard, not required by law means that we’re making the end users less productive then perhaps we should not be using that standard.

Provide clarity and security policies, standards, processes, roles, and accountabilities. Security is as much about people issues as it is technology issues and thus we need to focus on what roles and processes exist. For example it’s the job of the DBA, database administrator, to report strange activity on the database to the security administrators, so that the issue can be looked in to. If anybody takes the position that it’s not their job, chances are clear indications of a breach will go unnoticed. Measure and communicate results, drive continual improvement, build on existing capabilities. This means that we’re looking to improve and thus there is a sound feedback loop that exists to allow cloud security admins to improve cloud security ongoing. In some instances this could be moving to a new level of encryption for data at flight or at rest that’s more secure and easier to manage.

Security requirements

In my experience, your security requirements are everything. You should work from a checklist of your own making, meaning that your issues are not the same issues of the company down the street. Never assume that things are secure. You should assume that they are very much not secure and prove them to be secure as you go through this process. As you build requirements, make sure that you centralize. This includes policies so that everyone is on the same page when it comes to setting roles as well as access controls, our consistent use of access control technology throughout the cloud deployment. Also, APIs, application programming interfaces that ensure that we can programmatically access the security features. Also repositories, so we can keep track of all of the entities within the cloud computing problem domain for security and governance purposes.

Maintaining centralized logs to ensure that we have a centralized understanding of what’s happening. Finally, integrating and monitoring through a single pane of glass so we have one place to look to determine what’s going on now. In addition, we need to understand consistency across systems, meaning industry standards or the ability to leverage security standards where they benefit the organization. Some standards zap productivity, and that should not be used. Encryption strategy or how we’re going to encrypt data in flight and data at rest, common tool chain, meaning that we’re using the same tool sets, as well as standard OSS and BSS, which is operational support systems as well as BSS, which stands for business support systems. Shared security services are security services that should be shared with on-premise and cloud-based systems.

Finally, eliminating human errors. We need to consider blueprints or how we’re going to implement security services, who will do what and when, patching, or how we’re going to patch software issues that can lead to vulnerabilities, scanning, meaning that we’re looking proactively, scanning the environment to ensure that we’re not seeing problems. Event management, or that we’re able to deal with hacking events in a preplanned and orderly way using tools to automate the process. One touch deploys so we’re able to deploy security solutions with a single push, and finally, automated metadata tagging, meaning that we’re able to manage data better by providing identifiers. Discovery, as we presented in the last chapter, meaning to understand the security architecture, controls, and stakeholder requirements. Here we understand the needs of the business by looking at the target architecture, talking to the business leaders, identifying domains, things like that. This is a good template for you to use as you gather your own security requirements. We’ll break down the other two process components in the next set of videos.

Select the right technology

My advice is that you don’t get caught up in what others are doing. Focus on your needs as defined by the previous video. Make sure you test your tools. Never assume that things will work. Cloud security tool providers can’t test everything on everything, and therefore, your configuration can be the one that doesn’t work. You need to find that out upfront. Continuing on our process to assessments: keep in mind that the objective is to leverage learnings from the previous step in the process and alignment of client needs to cloud security best practices. This means that we take what we’ve learned, align it with best practices and use that to select the tool set.

Continuing to recommendations: we make conclusions as to what tools to pick based on evolving processes and understanding thus far. At this point, we should know what the requirements are including business and technical requirements. Moreover, what are the best bets in tools and technology that are most likely to be the best justification for our investment? Understand that target tool sets need to work above existing traditional cloud systems. This means our security approach and tools need to work for public clouds, private clouds, and traditional systems. So we’re not just selecting security tools for clouds, but we’re selecting security tools that are going to become systemic to our entire IT infrastructure.

So what are the best practices? Here are a few that I recommend that you understand. Security systems availability responsiveness needs to be considered a top priority. This means that you need to test and benchmark your security tools. Degree of compliance with deployed technical standards needs to be considered, as well. You’re in an industry. There are typically laws you have to adhere to. So, how are you doing that from a technical point of view and which laws are present? Degree of compliance with deployed business policies needs to be considered also. You’re in an industry. There are typically laws that you have to adhere to, so how are you going to do that from a business point of view? Where the previous was technology, now we’re focusing on the business.

Number of application groups/developers trained on security tools, including operation, developers, and other roles that exist in the organization. They have to be up to speed on what those tools do, and how to operate them. Percentage of systems and applications utilizing security services needs to be understood. If few applications are leveraging the security technology, the holistic approach to cloud security has much less value. Completeness of system documentation, meaning that we need to complete a set of documentation to insure that we’re detailing out the use of the tools in the same consistent way. Finally, improvement in the ability to enforce security and privacy policies, meaning that we’re automating this process as much as possible.

Security implementation and operations

Operations is where security can fall down, since so much of the solution is proactive monitoring. Other advice that I have includes making sure to focus on training. The cloud security game is a matter of people and processes. Finally, make sure to focus on monitoring. Can’t stress this enough, considering the importance of being proactive. Data should be everything around security operations including requiring transparency, meaning that we can see what’s going on, and react accordingly. Make data available everywhere and to everyone, either through APIs or a dashboard, allowing anyone to see the current state of security and monitoring of the data. Be proactive, not reactive. Yes, again, the data will provide you with the ability to be proactive and predictive. As you recall both are important to advanced cloud security. Mine data for patterns. This will lead you to trends that will lead you to finding issues that need to be corrected before they become problems.

Always evaluate key performance indicators and service level agreements. Keep in mind that there are places where the security tools will run into conflicts. You need to get ahead of those. Fast feedback loops trigger higher learning, as well as providing real time data as much as possible. The number of security standards is daunting. The good news is that most won’t apply to you. And you need to be aware of which standards are required and which ones are just helpful. Standards should be employed where there is a clear benefit, and where they don’t hurt productivity. Don’t let this graphic scare you. It’s pretty much everything that you need to do when doing cloud operations, and a few things more. What’s at issue here is you need to integrate security operations with cloud operations, including dealing with the same people, processes, and technology. There cannot be one security operations team, and one cloud operations team. This needs to be something that’s combined, and everyone understanding each other’s tools. If you break down the process you’ll see before you, you’ll understand that security should be systemic to operations.

Cloud operations overview

but it means the same thing. Ultimately CloudOps goes beyond simple operations. to basically leverage continuous operations and your ability to have feedback loops that go back to the developers, to make sure they’re continuously improving those things. By the time it goes through testing and deployment So we’re no longer waiting for point releases, point one point one, point one point two, two point one. or continuously putting out new binaries within the cloud-based system as we have to improve those systems.

So the rise of the cloud to the public cloud-based platform going forward. We’re able to do monitoring and management. We’re able to do governing operations using very sophisticated tools. Indeed, most of the R&D dollars are spent by the technology providers out there on cloud-based systems, almost to a three-to-one mix, and the reason is, is because they look at the cloud as the next destination for these tools. That’s good news for you, cause if you’re moving into the cloud, you’re benefiting from those R&D dollars which are providing you with the operation tools you need to be successful.

So CloudOps equals continuous operations, your ability to keep things going always, your ability to in essence have zero downtime, and your ability to continuously improve the products. To achieve the goal, the software must be updated and placed in production without interruption of service, and we have to get very good at this. This is no longer having system outages that may be planned or unplanned. This is about you constantly improving the experience of the user, the experience of the business, and doing so without interruption of service. So we focus on zero downtime. If the objective of CloudOps is zero downtime, then ultimately we need to understand the best practices So going forward, you have to think about redundancy as a core weapon to maintain systems, to keep system uptime solid over a long period of time. that we can bring up system analogs business continuity disaster recovery types of processes, that move from one cloud instance to another cloud instance.

The benefits of leveraging cloud computing, it’s not a requirement that we buy hardware and software. We’re able to set this up in a virtual world, do so very quickly. Well use that as a force multiplier to become very good at operations and to eliminate downtime. So as we move systems to public or private clouds, the demand for users is no outages. This is a tall order given that cloud-computing platforms are relatively new, but they are being sold as more reliable, more scalable than traditional systems, and traditional data centers. So you got some pretty heavy expectations have a very good record of uptime, they’re typically few and far between because they’re major press events, and because the cloud providers themselves are getting better at their own operations. So what you need to do is basically leverage their operational excellence into your particular problem domain, and ensure that you’re leveraging best-practices procedures, and that you’re putting redundancy in place where it needs to be put in place. So, in essence, if things go wrong, you have backup and contingency plans for them. So each domain works as part of an interconnected system. and then finally On-Premise Domain.

So the idea here is that we have to think around how we’re going to componentize the various aspects of operations. We can’t just look at everything So in using these sorts of models, all the machine learning and AI-based systems, Governance Domains, all the governance systems, on-premise, using the same operational procedures So by doing this, this basically removes some of the complexity because this is going to be a challenge to complexity. You’re going to have a cloud-based system which is a distributed system, a distributed computing system, and your ability to operate it really gets in to your ability to decompose it to these various subsystems, or subdomains, and your ability to manage them independent of one another.

Technology and toolsets

So, now let’s talk about technology and tool sets required for cloud computing. Keep in mind that we have a tendency to focus on this far too much when we’re building our cloud-based solutions, and there’s a reason why, because this is where the hype’s occurring, the excitement’s occurring. We’re going to conferences to learn about this technology, and that’s where everybody has a tendency to focus their time. So, those tasks with cloud operations, or CloudOps, focus too much, typically, on these tools, ultimately, and not enough on the processes that they need to figure out.

We’re going to look at a tool to save us when we should look at processes, approaches, best practices as ways in which we modernize our operational practices. So, again, don’t look at tools as your guide to CloudOps excellence, that’s more about people and process, and if you think about it, your tools are going to change consistently over the years, where your people and processes should not. So, the ability to set up redundant systems is only part of the CloudOps battle. So, keep in mind that as we’re looking at IT organizations out there and we’re looking at different technologies out there, that redundancy is one of our weapons, and it’s a major weapon, but we have other things to consider as well. We have the ability to restart systems automatically, to make them self-healing, to do lots of tricks that, by the way, your cloud provider provides, which allows you to maintain uptime.

We have tools such as cloud management platform tools and services that are out there which allow us to, in essence, abstract very complex operational environments, such as configuration, automation, governance, global, services, public cloud providers, private cloud providers, internal data centers, through a common set of tools that are able to simplify the automation of operations, and basically, how we take care of things. And so, through resource governance, we’re able to allocate storage the same way whether it’s on Amazon, Microsoft, or Google. We’re able to allocate computing the same way on the different platforms. So, it allows you to take very complex multi-cloud environments, or very complex distributed computing environments that may leverage internal systems and things that are in the cloud, and by removing you from that complexity, allows you to perform better operations, more successful over time, and it simplifies your life.

So, the other thing, metrics and monitoring system tools on private and public clouds ultimately are more data-driven. The great thing about today is that there’s no time that your cloud-based operations are operating where it’s not gathering data around those operations. Very much like we do with everything today. We gather data when we drive our cars. We gather data on our wristwatches, our health-based monitoring systems that are out there. We’re constantly gathering information as we’re operating in the cloud. Use that data, it’s one thing to gather it, but it’s another thing to actually leverage it to make your job better. And if we’re able to spot trends in terms of failures that are occurring, I/O systems that are occurring as a failure, and be able to, in essence, proactively fix issues, the more successful we’re going to be. In fact, a lot of monitoring and management tools out there not only gather information, but they provide you with machine learning-based analytical systems, which allow you to spot these trends to make sure you’re proactively taking care of issues as they come up, before they come up. So, of course, CloudOps is not only about what tools you buy, but how you use them, and the procedures and processes you place around them. So, why we can focus on tools, and certainly, that’s going to be kind of a default position most who are building cloud operations are going to worry about.

This is about becoming pragmatic with the different tool systems that are out there, including implementing pragmatic procedures, things that can be followed, really trying to make things very simple, automated, and ultimately, less stressful. And the more you do that, you’ll find, the better track you can keep of your cloud-based systems that you’re operating, and the more uptime you have. Many enterprises fool themselves into thinking that new technology or tools will provide CloudOps capabilities with only a small fraction of what you need to get done. And so, you’re going to have probably 23 tools that you’re dealing with when you’re operating cloud-based systems. Some of them are going to be built into the cloud provider you’re using, such as Amazon or Google, and many of them are going to be third-party tools that may run on-demand in a cloud, such as Amazon or Google, or they may work directly from the enterprise and they may work with your existing operations and monitoring systems that you had before you moved to cloud. So, the tool configuration is going to be adjustable based on the requirements that you have for cloud operations, but it isn’t everything it needs to get done. So, set your sights on greater insights. Easy governance, higher returns.

And so, again, I urge you to place things into domains. These are suggestions, by the way, data, services, process, cognitive, security, governance, automation, cloud, on-premises, and basically, dealing with the different subcomponents underneath that, such as security, security abstraction, integration, common directory service, security ops. And looking at, number one, the policies and procedures that are going to be a part of those particular subcategories, as well as the tools that may make your life easier. So, in this case, there may be one or two tools for each of these subcategories, under each of these domains, and so, therefore, you’re tracking lots of tools. You’re tracking lots of processes. You’re going to have a pretty complex job. So, your idea is to, basically, put complexity into its own domain, suggestions are here, and make sure that you create tool chains and tool sets and technology servings that allow you to, in essence, be the best at operating these particular domains.

Monitoring and management

So let’s talk about the inside baseball of monitoring and management Cloud, shall we? So, what’s important here is that monitoring, as with security, is one of the most important parts of CloudOps, and so your ability to have an ongoing dashboard, and you’re gathering information as to what’s going on, allows you to be proactive instead of reactive when solving issues. So the management aspect means that we’re understanding how to be more proactive going forward, and that we’re gathering data. We always know the state of our systems. We always know when things are likely to occur, and we’re always able to take preventative action to make sure that they don’t occur. If it’s some sort of an issue such as a storage system going down, such as a compute system going down. We need to be able to become more proactive than we are right now.

So, monitoring and measurement practice provides you with a proven and proactive way to monitor the performance of various workloads and components. We’ve been doing this for years on-premise, and ultimately, this is transferring the same sort of approaches in technology to the public Cloud providers, and many instances, the public Cloud providers themselves may provide measurement and monitoring capabilities, logging capabilities, things like that, it’s better to leverage third-party tools, where you have different Cloud providers that are there, and leveraging the same third-party tool to monitor behave at different levels of use, and decreasing loads over time. So again, it’s about gathering behavior. Understanding trends. And be able to spot repeatable trends that basically wrap up to issues that you are able to proactively resolve. you have governance systems, too much on the Cloud providers we’re leveraging, and the Cloud services we’re invoking. of these various application platforms, very much like we monitor our own health. The ability to not only gather the information, but report it out so we understand the different aspects and make strategic decisions as to things that need to be fixed.

As we begin to leverage hybrid clouds as private and public Cloud platform options, becomes a key value of leveraging this technology, and so whether this is a private and public cloud that are bound together, or this could be several public clouds creating a multi-Cloud architecture, we need to think about the portability between these various systems, and this has actually been moving by leaps and bounds lately. And we have technologies such as containers and serverless technology, and Kubernetes that allows us to provide container orchestration. Not going to get into that here, but basically you need to look at the viable options to provide portability in platforms that are out there that allow you to, in essence, without having to do a lot of rework. And we are hitting our stride in getting to a point in time in the future on one platform and move them to other platforms as we need to. Not there yet, but we’re getting there. Core to all this is to provide the wholistic collection of data that determines both the operational health of all systems, Cloud or not, holistically, as well as overall, as well as targeted performance metrics. So, you need to think that we’re focusing on specific things. or the health of a CPU in terms of its saturation points And this kind of roles up into a larger practical view of what we’re seeing in terms of how all these systems work and play well together, and so we think holistically, but we operate on a specific nature when we’re dealing with monitoring. Now, what we don’t want to do is to get bogged down in the detail, and so in many instances, these tools will abstract us from the underlying monitoring capabilities, so they’re able to do, in terms of operating these systems in effective ways, and fixing things proactively as they operate, and we’re only alerted if something tragically goes wrong, and we still have a good way to monitor on the holistic health of the various systems that are out there, again, from a global or holistic point of view, and not necessarily from a specific point of view.

So we may have thousands of things that are going on at the same time in terms of things that are happening within our systems that are specifically monitored by our particular tools, however, we sit in a position where we’re able to make decisions, and we’re only bothered by issues if they become bigger issues if they’re not able to be automatically fixed or self-healed by the tools we selected. So, moving to hybrid Cloud that we’re dealing with a mix of private and public Cloud in terms of hybrid Cloud, Your ability to run applications does not mean de-coupling or separating those things. may exist on the private Cloud, or vice versa. So we have to consider it as one wholistic platform. and built the net new systems, you know, suddenly someone raises their hand, And then we start bolting tools on, and without thinking around a strategy, while thinking about the different domains of operations and monitoring, and just how important it is to the success of Cloud computing. Keep in mind, this is how most people are going to experience our solutions. They’re going to look at how it operates over a long period of time, not just the first day that we roll out the application, or the first day that we roll out the database. So this needs to be systemic to your thinking, at every step of the game in terms of migrating, building net new, building DevOps platforms, all these things should be done with an understanding of how monitoring and management is going to work.

Next steps

So where do you go from here? Well, cloud architecture and your ability to understand cloud basics is going to be an evolving science. In fact it’s probably the fastest moving area of technology right now, so you’re going to be in for an exciting journey in understanding where this technology is going and how to keep up. Some of the real-world advice that I have, the cloud is driving a systemic change in how we do IT, so it’s going to keep on moving this way for quite some time. It’s fast moving, and your ability to obtain new information is paramount, so not necessarily drinking from the fire hose and getting lots of information that’s coming at you at the same time, but the ability to in essence select pieces of information that are typically going to be more important that you follow.

So a couple of places that I recommend that you look is my blog on infoworld.com, and I’ve been doing a cloud computing blog there for quite some time, and there’s lots of topics that I cover that are very germane to what we’re talking about here. You’re ability to in essence look at how cloud computing is evolving, but not necessarily chasing the hype but understanding where we should consider the next moves in cloud computing, and what will be technology that’s most going to affect us. Network World has a cloud computing section. It’s very good. So make sure that you hit that magazine once or twice a week, or even better yet, sign up for their email that comes out once a week which may depict some of the topics you’ll be interested in.

Podcasts are another great way to learn. I listen to a lot of podcasts. I have a podcast called Gigaom Voices in the Cloud. Check that out. But there are other cloud computing podcasts out there, as well. Make sure that you look through iTunes, and you’ll find that getting a 20 to 30 minute update each week, something that you listen to in the car, is going to be easy way to consume information. And ultimately, it’s the path of least resistance. It’s also the path of most joy.

What is cloud computing in a nutshell? Now you can better explain. Have a nice future in cloud computing.

Author:

David Linthicum

Chief Cloud Strategy Officer at Deloitte Consulting