Defining Cloud Computing

This is a guide on defining cloud computing.

This is the Ankr Power Bank I have. It has been great and reliable when I go on trips or when I get on my laptop to write somewhere away from home.

I'll explore cloud deployment models such as public, private, hybrid and community, as well as serverless architectures such as Back-end as a Service and Function as a Service. I'll also explore cloud service models such as Infrastructure as a Service, Platform as a Service, and Software as a Service, and discover characteristics and common uses for each case. Finally, I'll examine the architecture of cloud deployments and explore common cloud security considerations, including lack of control, data breaches and compliance.

So to begin, we actually have to go back quite a bit to the days of mainframes and computers that took up entire rooms to store.

Despite their massive size, of course, the computing power of any given system back then could be outdone by your mobile phone of today. Plus, those systems were designed to work on only a single task at a time with input from a single user.

So in the early 1960s, the Defense Advanced Research Projects Agency, or DARPA, tasked the Massachusetts Institute of Technology to develop a computer that could be used by multiple people simultaneously. Now, this was hardly the advent of cloud computing as we know it today, and those who were imagining the longer term capabilities of these advancements, were more so envisioning the advent of the Internet rather than the specifics of cloud services.

But this did establish the use of the term virtualization, which also doesn't exactly match its current context, but it laid the groundwork for multi-user environments where each user accesses the same centralized system or service, which is effectively how we use cloud services today.

From there, we jump to the 1970s when International Business Machines or IBM developed and introduced the first real instance of virtualization, meaning that multiple software-based instances of servers could all run on the same set of physical hardware.

Again, this implementation didn't really match what we see as virtualization today because the VM operating system platform was still based on mainframes, but it allowed for separate and distinct instances of operating environments to be run simultaneously on the same physical hardware, which is still exactly how we use virtualization today. It's just significantly easier to create and use new virtual machines using the modern applications of today.

With the foundations laid, most of the 1980s and early 90s were focused on the personal computer and the development of the Internet. But by the late 1990s, cloud computing as we know it today was starting to take shape with most of the earlier implementations being software that could be purchased online, as opposed to having to buy package software from a vendor.

Now, in most cases, the software itself still had to be installed onto a local device in the same way you might install software from a CD or a DVD, but it allowed anyone with Internet access to purchase and download it from anywhere, at any time, with no physical media required.

In other words, a centralized source of information was now available to users, and once all users had the application installed, in many cases they could all connect to a centralized server or service such as a shared database, so that if one user entered a record, that record was available to all other users. Now, that was nothing new in terms of being in a local area network, but that centralized source of information in a LAN was simply one of your own servers managed by your administration.

With this new type of implementation, the centralized data source was on the Internet, managed by an entirely separate entity. A very popular example at the time was Salesforce, whereby each user could access the same database of clients, contacts, sales leads and other information, which in turn facilitated much better communication and collaboration among team members and their customers.

By the 2000s, we start to see some of the major cloud providers of today emerging, such as Amazon Web Services, with some of their early services including storage and computation, such as the ability for clients to create and use their own virtual machines in an online environment.

Around the same time, Google launched its Google Docs and Google Spreadsheets services, both of which allow users to create standard user documents and or spreadsheets, that were compatible with popular formats such as Microsoft Word and Excel, all with no local software required other than a browser. Then in early 2010, Microsoft officially entered the scene with the release of Azure, with a varying array of services, including storage, computation services such as virtual machine, virtual networks and content delivery networks for distributing and placing web-based content as close to the consumers as possible, just to name a few.

Now, obviously that's a very brief and high-level overview of how cloud services developed, but that development was not limited to very large scale companies such as IBM, Amazon and Microsoft.

In fact, the general idea of cloud services, as they are today, developed around the fact that these very large companies needed to develop very robust implementations just to support their own services, which they quickly realized could be scaled up in an almost limitless manner, so that by the time most solutions were fully implemented, they were only being used to about 10 to 15% of their capacity. So why not make use of the remaining resources by making them available to the general public?

This is almost exactly what we see in what's known as the public cloud. A provider, quite simply, implements all the necessary infrastructure to support just about any technology, and they will most certainly use some of that infrastructure to support their own business operations, which of course, in most cases these days is just that data center itself.

But the rest of those unused resources is then made available to the public on a subscription basis, and accessed over the Internet. Similarly, many other organizations found themselves in the same situation. They would implement rather robust solutions to support their own business needs by creating a centralized data center.

But then, if perhaps a smaller branch office was opened, rather than outfit that branch with its own infrastructure, they simply made some of the infrastructure of the primary data center available to the branch office in exactly the same manner as a public cloud, except that these services are limited to just that branch office; they aren't offered to the general public. This configuration is what we now refer to as a private cloud.

The structure of the model is essentially the same, but those extra resources, if you will, are not made available to anyone outside of the organization. And the services of the primary data center might be accessed by the branch office over a dedicated WAN connection as opposed to the Internet.

But in either case, the branch office is still using the infrastructure of a separate provider. It's just all implemented and maintained within the confines of the organization in a private cloud. Now, for some organizations, they may actually combine the best of both worlds, so to speak, in what's known as a hybrid cloud configuration.

To illustrate this, let's go back to the example of the private cloud just mentioned. We started with a single data center where all infrastructure was implemented, then we added in the branch office who made use of the existing infrastructure of the primary data center in an entirely private manner. So that's all well and good, but now let's imagine that the organization wants to expand even more and open several branch offices.

The existing infrastructure of the single primary data center simply may not have the means to support all of the new branch offices so their own infrastructure can be augmented by adding standard public cloud services. So these new branch offices still do not need any local infrastructure, but their services are supplied either directly by a public provider or the primary data center implements and manages the new services from the public provider in the primary data center, but then still offers them out to the branch offices in a private manner.

But that new infrastructure is still coming from a public provider, hence, you're now using both in a hybrid configuration. So while cloud services may have evolved from relatively simple principles of developing multi-user computing models, the eventual result is a model that has revolutionized the way by which technology can be used.

A new business just getting started can offer services that rival any major or well-established business without needing any local infrastructure at all.

Businesses that have implemented their own infrastructure can expand their service offerings without having to implement anything new, or decommissioning existing services to support the new solutions. And those new solutions for any organization can be created in a matter of hours instead of weeks or even months, because all of the necessary resources are already in place at the cloud provider, ready to be used at any time. And all of these new services are available to anyone, from anywhere, on any device, as long as there is Internet access. So clearly a fundamental shift in technology has been realized with the advent of cloud services.

Now, from the perspective of the customer, that infrastructure itself is built, hosted by and maintained by the cloud services provider, in almost all cases in the form of a website that allows customers to log into their subscription to access the services they need.

One of the more commonly used terms is portal, but no matter which term you prefer, once signed in, clients have the means to access all available applications and services of the provider, while requiring nothing more on the client side than a browser.

Now, depending on what type of solution is ultimately configured by the customer, those who actually access and use that solution may need more than just a browser on their local devices, but in terms of simply accessing the services and resources of the provider, the client need only use a browser to sign into the provider's site and begin creating the resources necessary to support their needs.

Now, the services of the provider are generally divided up into three categories, although newer and more specific versions of these services are appearing regularly, but they're known as Software as a Service or SaaS, Platform as a Service or PaaS, and Infrastructure as a Service or IaaS.

Now, we'll take a brief look at all of these in just a moment and a more detailed look at each one in some upcoming presentations, but what I'd like to also point out here is the nature of the graphic, whereby we see infrastructure at the bottom, platform in the middle and software at the top. And this is accurate because, although as a client, you can subscribe to any one or all of these types of services, each of the upper layers is built entirely on those below.

Now, that will become a little more clear in just a moment but in short, even though you can subscribe to services at, let's say, only the SaaS level, software needs a platform on which to run and platforms are built on top of infrastructure. So to hopefully clarify that a bit more, let's start with the lowest level of infrastructure.

Here is where you can begin to build solutions using actual hardware, operating systems and networking components. Now, recall that as a customer, all I have access to is a browser, so clearly I'm not directly working with actual physical hardware. But I can access and configure the services of that hardware.

Now again, we'll take a more detailed look at each of these levels in some upcoming presentations, but let's go with a quick example of needing a virtual machine to act as a web server.

Once signed into my subscription, I can use the interface to configure the desired specifications of that virtual machine in terms of how much memory it should have, what kind of storage and what kind of processing capabilities, the operating system I prefer to use and the web server component that I prefer. Now, you may not be able to do all of that in a single configuration pass, but that will depend on the provider.

For example, you may have to install the web server component after the virtual machine is up and running. But what matters at this point is that the resulting system would be no different than if you sat down in your own physical office, grabbed a nearby physical computer, reconfigured the actual hardware as needed, installed a fresh operating system, and added the web server component.

In both cases, you end up with a system on which you can now host websites. In other words, you have constructed the infrastructure necessary for the higher level service of the websites. The only difference is where they're located.

That said, however, I should point out that the process of assembling that infrastructure is significantly faster in the cloud. Physically constructing that server in your own local environment could take hours, possibly even days to complete if it's a complex configuration.

But in a cloud environment, you literally just choose those configuration options from an interface, and the provider creates that system as a virtual machine running on one of their physical servers, using preconfigured images of the operating system with all software likely already installed.

So the system can literally be up and running within minutes. Now, I'm going to skip over Platform as a Service for just a moment and talk about Software as a Service, which is at the opposite end from infrastructure. And I'm doing this because it's easier to envision the role of Platform as a Service once you understand the other two levels.

So Software as a Service refers to an overall application which can refer to a service or a piece of software or both. Now, what does it mean to say a service? Well, in this context, it's simply something that can be used by any consumer, including hardware devices, without needing any particular type of software.

For example, our mobile phones have access to cellular services. As a consumer, I don't need any particular type of mobile phone nor any specific application on that mobile phone to be able to get service. It's just there. Sometimes there is some level of software required, but it doesn't have to be anything specific to the service itself.

And the most common example of this is a browser. We can all use browsers to access a tremendous number of services, such as audio and video streaming, online banking, retail shopping, making reservations and many other services. But all of them can be done through any general internet browser.

Software, however, as compared to a service, tends to be a little more specific in that is usually designed for a specific purpose. For example, word processors are designed for creating and working with documents. E-mail clients are designed to send and receive messages and book appointments in meetings.

So again, either or both can be accessed and used in a Software as a Service subscription. But the distinguishing factor here is that there is no infrastructure, at least none that you have to deal with as a customer. So let's go back to the previous example where I was wanting to build a virtual machine to act as a web server.

Using Infrastructure as a Service I can absolutely do all of that and have a perfectly good web server on which to host my sites. But what if you don't want to deal with the server at all? That's where SaaS comes into play. I can create just the website if I want and leave it to the provider to manage the underlying infrastructure entirely.

So it really comes down to what you want or need. By configuring the virtual server yourself, you have as much control as you like and you can manage the server however you see fit, but you have to manage it. If you aren't concerned with any of that, then creating only the website in an SaaS configuration might be a better option.

But then you have almost no control over the server itself. So again, it's what's important to you and your needs. Platform as a Service, then, falls somewhere in between the other two layers, meaning that there is a little bit of both. Now, in short, PaaS is most commonly used as a development solution to ultimately provide a runtime environment for whatever application or service will be developed.

But again, there would be a need for some level of infrastructure and some level of software. Let's go back to my website that I want to host, but now let's also include a database so that the website is being used to accept retail orders from customers, and those orders are being placed into the database.

So let's imagine that if I'm a developer, and as the developer of this solution I already know that I need at least one database server and at least one web server.

But the key statement here is: as a developer, meaning that I know that I need those servers, but I really don't want to have to deal with configuring every aspect of those servers in terms of hardware, operating systems, security configuration, updates and everything else that goes along with managing those servers after the fact.

In other words, I'm not an administrator. I'm a developer. Every aspect of what I just listed out is what you might do if your subscription was entirely IaaS-based. So what I can do is to define the specifications of what is needed for the servers as part of the overall code being constructed.

And virtual machines will be assembled as per those specifications. But once assembled and running, again, it falls to the provider to maintain those servers. As the developer, I only need them for what they can do for my solution. But it's not up to me to manage those servers day in and day out.

With the infrastructure defined, I can then begin working on the website component to accept customer orders. So I've used the infrastructure to create a platform upon which I can build the service I'm providing to the customers. In other words, I've used some infrastructure to create some software or services, but the management of that infrastructure is left to the provider.

So with PaaS, the focus tends to be more on the end result of the software or services being created, but with the realization that there needs to be more control over the required infrastructure than what might be available through just an SaaS solution, which, again, is why I say that PaaS falls somewhere in between, and hopefully why understanding the two opposite ends first makes it easier to understand the middle ground.

Finally, the last component is, of course, the Internet, which facilitates all communication between the front-end client interfaces and the back-end components of the provider. Now, this might seem like a rather obvious component, but it is worth mentioning because it's important for all decision makers to realize that cloud solutions are 100% dependent on having Internet access.

Now, that's true of a lot of services these days, but before making any commitments to a cloud-based solution, an organization needs to understand what kind of an effect a disruption of Internet service could have on that solution. Now, that doesn't really refer to localized outages, such as power failures or issues at any given local Internet service provider.

For example, if your services are up and running, but a client can't reach you because their own Internet is failing, that certainly isn't your fault. But consider a disruption of service at the cloud provider. That would affect all customers. Or if you also consider a disruption of your service with your ISP, that would prevent you from getting to your own solutions.

In short, it needs to be determined how those types of disruptions would affect you and whether there are any means to address them such as using redundant connections or implementing service-level agreements with the cloud services provider, that will define what happens in the event that Internet connectivity is lost.

Ultimately, any given cloud solution will require at least the client infrastructure in the form of the front-end interface that you as a subscriber will need, a subscription that implements at least one of IaaS, PaaS or SaaS, or any combination thereof, and, of course, an Internet connection that is as reliable as possible.

Now, as is evident by the name of the service and the types of available resources, this type of service represents the foundational layer of just about any solution, hence the name infrastructure. Now to clarify, while these resources are built on actual physical hardware, as a customer, we still do not have any real access to that hardware.

Rather, we can subscribe to the services that hardware can provide. For instance, to say that a server can be created is entirely true, but it's in the form of a virtual machine running on some physical hardware at the provider that, we never see. We can absolutely specify the performance characteristics and the configuration, but we only ever have access to the virtual machine. But from the perspective of building solutions, that's all we need.

If it were an actual physical server in our own premises, then of course we would expect to have to perform physical maintenance from time to time, such as applying updates to the host system, changing out failed hard drives or any other hardware component, and maybe adding memory when needed. But with an IaaS subscription, none of that is our concern. It's all up to the provider to manage the actual hardware, so we only need the virtual machine.

Its desktop can be configured to be accessible over the Internet, just like any other that you might work with within your own environment. And it can perform the same tasks as any other server. So in terms of functionality, there really is no difference. Now, the same applies to networks.

If, for example, we need several virtual servers, we can configure the IP addresses so that they're all on the same virtual network or use different ones if necessary but we're just using software interfaces to configure those networks, and it's then up to the provider to ensure that our configuration is implemented on the underlying hardware.

In addition, most major vendors provide the ability to create virtual systems running the most common operating systems, including Windows, Mac and Linux, and of course, storage is available either as virtual hard drives on those servers, or just using general storage accounts that can be allocated separately but still accessible by those servers if needed.

So as an IaaS customer, you aren't required to be on site in any particular location to manage the cloud-based infrastructure, even if you already have an on-premises environment, because of course all resources are managed through the web interfaces of the provider, or perhaps custom built interfaces.

But as long as you have Internet access, you're able to manage your resources from anywhere, any time, on any device. IaaS solutions then, provide several benefits, including a pay-as-you-go structure whereby you only pay for what you actually use, which alone can sometimes represent a significant savings over purchasing infrastructure locally.

And IaaS solutions allow you to retain control over the infrastructure that you've implemented. In other words, if you do create several virtual servers, on virtual networks, with virtual storage and any other resources, it's entirely up to you what you do with those resources. If you discover that you either under or overestimated your resource needs, you can scale at any time in either direction.

For example, new resources can be allocated within minutes and deallocated at any time, and administration is eased because you only have to look after the virtual resources themselves, not the underlying hardware. However, there are of course some disadvantages in that you are still responsible for the security and the stability of whatever solution you build.

Now, just to quickly clarify that statement, the provider would still be responsible for ensuring the physical security of many components. For example, if you create a website that accepts orders, the data gathered has to reside on a physical device somewhere within the data center of the provider. So it would be up to them to ensure that no one working at the data center could just walk off with that device.

But of course, it's up to you to ensure that attackers cannot gain access to that data through the website you just built. The data itself that you gather is also your data.

So again, while the provider has to protect the physical devices, you have to ensure that data is secured through the applications and services that access it, and also to ensure that any compliance rules or even laws are observed, such as ensuring that customer records are retained for an appropriate amount of time and or possibly deleted after a certain amount of time.

And of course, all configuration of all resources still falls to you in terms of implementation. Now, this isn't necessarily a disadvantage. In fact, this may come back to the advantage of wanting to retain control in some cases. But it's important just to clarify that with an IaaS solution the provider is not responsible for configuring anything.

They provide you with the necessary resources, but it's entirely up to you to implement and configure those resources from the moment you create them, including applying updates and patches to your operating systems or applications, installing and configuring security software and anti-malware applications, and managing permissions and resource access.

Among the more common providers of IaaS solutions are Amazon Web Services, Microsoft Azure, Google Cloud, and IBM Cloud. Now, there would be a significant overlap in terms of many of the resources offered by each one, and of course each would have resources not offered by others, so it's important to simply shop around, so to speak, and most, if not all, will typically offer free trial periods of usually one month, so you can assess their services.

Some examples of scenarios when you might need an IaaS solution for your business might include migration of existing on-premises solutions to the cloud, building and deploying customized web apps, creating testing and development environments for bringing new applications and services to market much more rapidly, implementing data storage or business continuity measures such as cloud-based backups and recovery mechanisms, or possibly implementing high-performance computing options, including supercomputers, computer grids or computer clusters, all of which can be used to address highly complex problems involving millions of variables such as advanced climate predictions, natural disaster simulations, financial modeling, or big data analysis.

Most of these resources at this level are simply out of reach for many organizations, but they're readily available in the cloud. Ultimately, as mentioned, the solution you implement is entirely your call. The job of an IaaS subscription is to simply provide you with whatever resources are necessary to facilitate that solution. And with most major providers, from the perspective of any one customer, those resources are available in an almost unlimited manner.

So to help envision that, imagine that your business is to do nothing other than to develop software. In an on-premises environment there are a lot of resources required just to build the development environment itself, including servers, networks, storage and perhaps most notably the development suites used by your developers to manage code security, maintain versioning history, and to facilitate development teams that can all work on the same projects simultaneously.

All of that infrastructure needs to be in place before your developers can really do anything. So if you don't have any of those resources available to you locally, or perhaps your current development environment is simply becoming out of date, you can use a PaaS solution to build a complete development environment in the cloud. Virtual servers and storage can be allocated within minutes.

Virtual networks can be configured to host those resources, and even the software development suites can be made readily available whenever needed. You could literally build the entire development environment, likely within a matter of hours depending on its scale, without having to purchase, manage or maintain any of the physical infrastructure. Once implemented, your developers can use it to build anything and everything from simple cloud apps to enterprise-level applications, and like almost all cloud-based services, you simply pay as you go and only for what you actually use, with no upfront costs required.

And again, the actual physical resources upon which those solutions are built are up to the provider to maintain. Now, being able to offload the maintenance and management of the underlying physical resources to the provider is of course very similar to IaaS, but that's true of all cloud-based solutions, because, of course, as customers we never have to look after anything physical.

But what begins to distinguish PaaS from IaaS is the focus on middleware, business intelligence services, development suites and tools, data management systems and many other resources used to build new applications and services. So the focus with PaaS solutions is almost always on development, whereas with IaaS, the resources could be used for almost anything.

But PaaS separates itself from the physical resources by obscuring the hardware even further in some cases. For example, in an IaaS solution, I could absolutely create a virtual server, then use that server to install a software development suite, and my developers could then begin their projects.

But in that model, someone still has to manage the virtual server itself in terms of the operating system, its resource configuration, security configuration, and manage all updates and patches to both the operating system and the software on it.

But with a PaaS configuration, I can add just the development suite to my environment with no visible underlying server at all. The server is still there somewhere, of course, but its management is offloaded to the provider because I simply don't want to deal with server management. I just want my developers to have the means to start working. The developers themselves might configure their own servers on which to test and deploy their applications, but that would be their call.

They would not have to worry about managing the server on which the software development suite was installed. Similarly, if a developer creates a solution that requires systems such as web servers or database servers, they can define the specifications of those servers as part of their code, and they can be implemented as virtual machines automatically.

And again, the developer is not responsible for directly managing those servers themselves. It is once again up to the provider to ensure that those servers are managed and maintained accordingly. This type of implementation allows your developers to focus solely on development and not have to worry about administration and management of underlying resources.

So the primary characteristic of a PaaS solution is the development of new applications and new services with almost no concern for infrastructure, other than what the developers themselves might choose to create. In terms of advantages, PaaS environments are very simple to implement, and a wide variety of tools are available at a moment's notice.

Developers can use those tools to facilitate collaboration with other developers, they can customize their apps easily without concern for upkeep and management of the underlying resources, and scalability is almost limitless from the perspective of any given customer. On the downside, because infrastructure is more obscured with PaaS solutions, developers can only control what they build on the platform, not really the platform itself.

For example, your developers may require a specific type of storage that simply isn't available from the provider, or they may need a different development tool that just isn't available. In addition, like all cloud services, there are potential security risks because components such as data and sensitive information is ultimately being stored by a third party, which can raise some concerns.

And on a related note to the first point, customizations can only be made from the platform up, so to speak. The platform itself and underlying infrastructure can only be built upon the services offered by the provider. For example, your developers may need to build and test applications across many different operating systems, but some of them simply might not be available.

So the entire development environment itself that you're even able to construct may need to be carefully assessed before committing to a PaaS solution. Some common providers of PaaS solutions include the Google App Engine, Amazon Web Services, Oracle Cloud Platform and Microsoft Azure, again, with significant overlap likely happening among all providers, but each with its own specific service offerings.

Lastly, with respect to some common business scenarios, PaaS solutions are typically implemented by any organization that wants to focus on building and customizing new applications and services with the emphasis on development, so that developers can focus on their projects with little to no infrastructure concerns and not have to worry about managing and maintaining the development environment itself while still having easy access to a multitude of development tools that might otherwise require significant purchases and licensing to implement.

Now, the applications and services themselves are ultimately up to your developers to create, but with PaaS solutions the environment in which they create those solutions can be created and managed much more rapidly and easily, allowing your developers to focus solely on development, leading to solutions with a much faster time to market.

And as its name indicates, the primary focus of the SaaS model is software that is based in the cloud and available to be used on a subscription basis, and you only pay for what you use, just like the other service models.

But in this case, usage is generally determined by the number of users registered to use the application, as opposed to how much or how often it gets used. And that software can be accessed over the Internet, typically by using standard browsers or mobile device apps or in some cases, custom applications. But the distinguishing characteristic of an SaaS solution is that there is no infrastructure required at all, with the exception of the individual client devices.

So when you're looking to implement an SaaS solution, you never have to configure any kind of resource such as a virtual machine to host the application, Nor do you have to develop anything. You simply make use of software that is already available and in most cases you don't even need to install anything on the front-end devices.

Clients typically just use a browser to sign into the application and use it through the browser. So there's very little administration as well. Now, I won't go so far as to say that there's no administration because you still have to determine which users are able to use the application. So in some cases, licenses have to be configured through your directory service and there can still be variations in the features or the additions you want and different configurations for different sets of users.

But again, nothing has to be implemented or managed in terms of the underlying infrastructure, and nothing needs to be developed. SaaS solutions are becoming more and more popular with organizations, with a focus on building and growing their business without having to worry about making significant investments in infrastructure.

And they can be especially beneficial for organizations with very geographically dispersed teams, because all users simply sign into the same service and can communicate and collaborate from anywhere, at any time, on any device, as long as there is Internet access.

Common SaaS applications include email and calendaring applications, collaboration suites that include video conferencing and instant messaging applications, as well as document sharing and versioning, customer relationship management applications, enterprise resource planning applications, document management services, and many, many others.

The list of applications available through most major providers is exceptionally thorough and growing all the time. In some cases, there are literally thousands of applications available.

Among the major providers are Google Workspace, offering email and calendaring, storage and document creation and management,

Salesforce, who were among the first SaaS providers with their primary focus being on customer relationship management services, although they have branched out into newer applications, Adobe Creative Cloud focusing on desktop creativity software such as Photoshop, and Microsoft 365, formerly known as Office 365, which provides access to the full Office Suite of applications that many of us are familiar with, including Word, Excel and PowerPoint, but many other services are now available through Microsoft 365, including a full messaging solution, SharePoint online Dynamics Customer Relationship Management and Microsoft Teams for virtual meetings or live web feeds, instant messaging, collaboration, and many other features.

Now, another particularly useful feature of SaaS applications is the ability to quickly and easily mobilize your workforce because any user can access the app and its associated data from any type of device that can connect to the Internet, including standard desktop computers or laptops, or the now ubiquitous mobile devices such as smartphones and tablets. For example, salespeople who may have previously been very limited in terms of only being able to work in the office environment during standard business hours, can likely now work from home or while traveling at any time of the day, from anywhere, as long as they can connect to the Internet.

This may allow them to foster and build much better relationships with their customers, and since the data that is accessed through SaaS applications is all stored centrally within the cloud, there is little concern if any individual user device were to fail or if a traveling user happens to lose their mobile device.

Apart from the inconvenience, as soon as they were able to get to any other device and sign in, nothing in terms of data would be lost and they could resume their work exactly where they left off. Again, SaaS solutions can be a great option for any organization that needs to expand their software and possibly even the way they do business, all without any concern for making large investments in physical infrastructure or managing back-end resources.

You simply subscribe to the software, create user accounts and assign licenses if necessary, but with that complete, users can sign in and begin using the software immediately.

In most cases, any organization or even a single person can sign up with no upfront cost, no commitment, no contract, and no physical resources or infrastructure other than a front-end device with which to access the provider's management interface, at which point you can begin to create, configure and use whatever resources you require immediately.

The distinguishing characteristic of a public cloud implementation, however, is not really the ease with which you can get started. Rather, it's the fact that public cloud services are available to anyone, anywhere, with Internet access. No partnership is required, services do not have to be obtained through an authorized vendor, no licenses are required for the subscription itself, quite literally, anyone can make use of public cloud services.

Most providers require nothing more than a credit card to create your subscription. Such a model can potentially represent significant savings for many organizations or individuals, not just in terms of monetary savings due to not having to purchase any physical infrastructure, but also time savings with respect to managing and maintaining whatever it is you create, because there are no concerns for managing the underlying hardware of your resources.

So while you do still have to manage your own resources, such as virtual machines that you create or data that you place into a storage account, there is no management of the physical server that hosts your virtual machine, or the hard drive onto which your data is written. All actual hardware is entirely the responsibility of the provider and it is never exposed to you as a customer.

If any hard drive or any piece of hardware fails, the provider replaces it. If a server hosting a virtual machine fails, the provider migrates the virtual machine to another host server. If their Internet connection goes down, they switch to a redundant connection. So again, all concerns for hardware and infrastructure are entirely removed in the public cloud model.

Nearly all public cloud models are based on a pay-per-use or a pay-as-you-go basis, literally meaning that you only pay for that which you use. And even when you do use it, the price is based on the volume of usage, resulting in a very flexible and scalable model because unlike purchasing physical hardware, you don't have to worry about not getting enough or getting too much.

You can simply get started at any level, and if you discover that you need more, you can get it at any time. If you overestimated a bit, anything that wasn't actually used isn't billed. A good example of that is storage. You can create a storage account in most cases for free. This just allocates a place for your data to live at the provider. If you then upload 10 gigabytes of data, you'll be charged for that usage.

But if you estimated that you might have needed 20 gigabytes but you don't actually use any more than 10, you aren't charged for the extra 10 gigabytes that you didn't use. But should you need 50 more gigabytes in the near future, simply upload the data and you'll be charged accordingly. But that extra storage is available at any time.

Similarly, if you create a virtual machine just to test out some of the options but then shut it down entirely, you won't be charged anything for the time that it isn't running. If you need ten virtual machines within a few weeks, allocate them whenever you need them. Other benefits of public cloud services include availability and accessibility.

Cloud services are inherently available 24/7/365. The only limiting factor in terms of access is the ability to connect to the Internet. If connected, then all services can be accessed from anywhere at any time, from any device. Performance is almost unlimited in terms of any single customer. Now, be mindful that higher performing resources will cost more, but there is almost no limit to the resources that you can configure for any given solution.

And again, they can be scaled up or scaled back at any time. And in many cases, scaling can also happen automatically based on the current workload. Virtually every resource available to us as customers is also available in the latest edition or the newest revision, yet if necessary backward compatible resources are often available as well, often going back many years in some cases, to ensure that you can create solutions that are compatible with existing technologies.

And most major providers offer such a wide variety of options that you can create almost any type of solution that would be compatible with anything else that you might already have or that you're looking to create.

However, there can still be drawbacks when using public cloud services, including the potential cost. Even though no purchases of physical hardware are required some services can still be quite costly depending on what they do and the volume you require, although many providers offer calculators to assist with pricing estimates, but just be mindful that cloud services do not guarantee lower costs, especially if an organization has already made significant investments into their own infrastructure and it has yet to be paid off.

Adding cloud services in that event could just add costs that may not yield any actual benefits. Since the underlying infrastructure does belong entirely to the provider, it can result in a lack of control.

For example, providers decide entirely what to do with their hardware and when to do it, so it could end up being disruptive in some cases or such changes could result in compatibility issues if the solutions that you've implemented are no longer supported by the changes the provider has made. And there can also be concerns with compliance and security because public cloud services are inherently shared among multiple tenets.

So it's important to understand if your own business model might be affected by that, or if there are any privacy laws or other regulations that might be violated by using physical resources that are ultimately shared with other users. As long as you understand these and other considerations and are aware of the potential drawbacks, most organizations will likely find that public cloud services offer tremendous benefits, that can most certainly help an organization to grow, with much less concern for physical infrastructure and its management.

So who exactly would require any kind of cloud services? Well, a private cloud typically begins with an existing data center that is entirely owned by the organization, with all necessary infrastructure in place to support their technology needs. Now, the term data center might invoke images of a gigantic facility with nothing but technology from wall to wall, which it could be in some cases, but in this context, it could be of any size.

But the key idea is that not all of its capabilities are being used to their maximum capacity. In fact, in many cases, actual usage might only approach a small fraction of its capabilities. But the point is, there are resources left over, if you will. So this type of cloud can be thought of as an on-premises private cloud, which offers many benefits, most notably complete control over all aspects of your solution, including security, scalability and configuration.

In short, everything is up to you in terms of implementation and management. But we still don't seem to have anyone other than the existing data center making use of the available resources. So where does the cloud component come into play? Well, in most cases, the cloud consumer is simply another division, department, or branch office of your existing organization, that might operate somewhat autonomously from the primary data center, but without any infrastructure of their own.

For example, if your organization develops and sells products, the bulk of the IT infrastructure might be dedicated to managing customers, taking orders, managing inventory and shipping, and many other day-to-day aspects of your operations. But you might also have a research division dedicated solely to developing new products. So let's imagine that the research division has just expanded and they actually moved into their own facility.

Maybe it's an office on a separate floor, maybe it's a separate building on your own property, or maybe it's on the other side of the country. It doesn't really matter where they are. What matters is that they now need their own IT services as well.

So you could certainly purchase all the necessary infrastructure to support their needs, or you could simply take advantage of those leftover resources I just mentioned, and allocate them to the newly expanded division. Servers, storage, networks and other resources could be dedicated for their use, but remain entirely where they are. And interfaces could be built to allow the new branch to create their own resources as needed, just as if they were using public cloud services.

They can configure anything at any time and can access those resources over the Internet or a private intranet, if appropriate or required. But in either case, they're still using the resources of the primary data center, so there is no need for any local infrastructure in the newly established division.

Now, the available resources certainly may not be as robust or as varied, as a major public cloud provider, but as long as they can configure solutions that meet their needs, that's really all that matters. So this model doesn't really differ from the public cloud in terms of implementation. The difference is simply that all resources are contained within and consumed by users of the same internal organization.

There can be many advantages to a private cloud implementation, beginning with performance, which may seem somewhat counterintuitive to say since major public cloud providers seemingly have unlimited resources at their disposal. But bear in mind that public cloud providers have to divide those resources among all of their tenants.

In a private cloud, there is only one tenant so as long as you have the necessary resources to begin with, there is no competition for those resources. Perhaps the most notable benefit is control, which can sometimes be lacking in public cloud environments. Since you're still only using your own infrastructure, again, everything is up to you, so implementation, management, development, distributions, administration, allocation and deallocation of resources, it's all up to you.

Security is often an advantage as well, and once again, you might imagine that major public cloud providers can likely dedicate far more resources to security than any given organization. And that might be true overall, but recall that resources in public cloud environments are still shared.

So it's entirely possible that my virtual machine could end up on the very same physical host server as yours. And if I'm a little negligent in my security duties, I might forget to install an anti-malware application on my server, which could result in an intruder gaining access to the physical host server, which could consequently compromise your virtual machine and all others running on that host.

Since resources are not shared in a private cloud, security can be significantly higher in some cases. Some considerations, however, do include the potential costs. As your own provider, clearly you must have the physical infrastructure in place to support everyone who needs to consume those resources, particularly if your organization is growing and you're trying to keep up with increasing demands.

And similarly, it can be difficult to scale resources due to budget constraints or time considerations. Scaling any part of your solution may require significant additional purchases if you're already close to your maximum capacity.

And even if the funds are available, actually implementing and integrating those new components could take weeks or even months to complete. And since all infrastructure is yours, you are responsible for supporting and maintaining everything, which will only become more and more demanding the more your private cloud grows.

Now, on that note, I'd like to finish up by talking about another type of private cloud implementation known as a virtual private cloud, which can help to mitigate some of the concerns just mentioned by still offering the control you need, while maintaining the isolation of resources, despite the fact that in a virtual private cloud resources are actually supplied by a public cloud provider.

Now, this might sound similar to a hybrid cloud implementation, but that's a situation whereby an existing private cloud simply augments its infrastructure by adding in public cloud services. But the public cloud services themselves are standard cloud services, if you will, meaning that the resources are still shared with other tenants.

In a true virtual private cloud, for starters, the public provider supplies all resources and infrastructure. So it's not a matter of augmenting your existing resources, but an agreement is struck between the provider and the tenant whereby all resources that are allocated are not shared with other tenants. Hence the control you need and the isolation you need remain available to you.

And you now have access to likely much more infrastructure than you had to begin with. Now, as you might imagine, subscribing to dedicated resources, from a public cloud provider, is going to cost more, because the provider is obviously losing out on their ability to generate additional revenue on that same infrastructure from other tenants.

But that's the tradeoff. You pay more, but you no longer have to maintain your own infrastructure at all. In any case, that's just an option, of course, but in either configuration a private cloud uses the same architecture of a public cloud in terms of how resources are accessed by the customers. But all consumers of the resources in a private cloud operate within the same organization as opposed to being in the general public.

Now, community cloud implementations are likely less common than either of public clouds or private clouds, but a community cloud doesn't necessarily distinguish public from private in terms of where the actual infrastructure comes from. In other words, members of the community might decide to use fully public cloud services, but they might all share a single subscription.

Or perhaps a private cloud has already been implemented by one the community members, and other members subsequently become subscribers. So with a community cloud, there is less of a concern for who the provider is, rather, the focus is on being able to share the available resources among community members.

This type of resource sharing arrangement facilitates the ability for community members to work on joint projects that would benefit all members of the community, and it promotes collaboration among all members so that any given solution can be attained more rapidly and implemented as quickly as possible.

Now, as far as who these community members might be, it will certainly vary, but they tend to be organizations that operate in the same general field but aren't necessarily in competition with each other, although that's certainly not a requirement.

For example, government agencies working on a security solution that would benefit many different branches or departments, research teams that are developing new medical procedures or treatments, educational institutions that are looking to create a shared knowledge base, law enforcement agencies might want to create a more extensive shared database of known suspects or previous offenders, even financial institutions who may be in direct competition with each other, might need to work together to develop a more secure way to process transactions among each other.

Some benefits of the community cloud include flexibility and scalability, availability and reliability, security and compliance and improved service offerings for each member. But I would say that these benefits will be dependent on where and or how the infrastructure is supplied, and there would be advantages and disadvantages for both.

For example, if the infrastructure is a shared public cloud, then it's likely that aspects such as flexibility, scalability, availability and reliability would be higher due to the almost limitless resources of public cloud providers. But then security and compliance might be a concern because perhaps the project involves data that cannot be stored outside of the community. Improved services may not be guaranteed because the provider may not support all of the services you need and all public services are shared,

so there is still competition for resources. Conversely, a private cloud may give you much more control over security and compliance, and you may be able to implement very specific services that are unique to your industry. But you may not have nearly the volume of resources that a public provider would, but there would be virtually no competition for those resources other than among the existing community members.

But as long as the infrastructure can support the community as a whole, services should perform adequately. Like anything, it will simply come down to which model best suits the needs of the community, but again, the community cloud is not necessarily limited to one option or the other in terms of how the infrastructure is provided. The shared aspect is the distinguishing characteristic.

Considerations should certainly include access to data, and there could be data that is highly sensitive in a community cloud. And it's not always the case that every member should have the same level of access. For example, one of the members might only be present as a technical component to help build the solution, but they don't really belong to the community from an operational perspective.

So data access may need to be very tightly controlled. Similarly, compliance can be challenging, as there may be laws, rules or regulations in place that don't necessarily apply to all community members, or at least not to the same degree. So one member may find themselves having to operate under the confinements or restrictions of other members, and the lack of familiarity could certainly cause problems.

And in the case of organizations who may normally be in competition with each other, stringent agreements might need to be implemented to ensure that repercussions are in place should any given member attempt to seize control over the ultimate solution.

In short, if there is any situation whereby a new type of solution might benefit all members of the community, a shared cloud environment might help to bring that solution to fruition more quickly, and at a lower cost than any single member might otherwise have to pay.

But a hybrid cloud is officially a mix of any of the private, public or community cloud models. For example, an existing private cloud might be in place for an organization who later joins a community cloud. A public cloud might be in place for another organization who then determines that tighter security and compliance are needed, so they might construct a private cloud.

It really doesn't matter which models are part of the hybrid cloud, but for the purposes of this presentation we'll focus on what is usually the most common combination, an existing private cloud that is later combined with a public cloud.

So to give you a better idea as to the architecture of that type of hybrid cloud, in most implementations the public cloud provider is typically used as a platform to provide additional resources over and above that which is in place within the private cloud environment. For instance, if a private cloud has been implemented, but users are often unsatisfied with the level of performance due to inadequate resources, more resources could certainly be purchased and implemented locally, but that could incur a significant cost.

Instead, the organization can simply add services or resources from the public provider, to shore up their weaknesses, so to speak, which can be done almost immediately and with no upfront cost required. And it doesn't really matter what those new resources are. In other words, you don't necessarily have to choose a specific service model of Infrastructure as a Service, Platform as a Service, or Software as a Service.

It just depends on where you are currently lacking. But as an example, your users might feel as though there aren't enough physical resources because they notice it takes a considerable amount of time for them to create a new virtual machine to act as a database server, which suggests a weakness at the infrastructure level.

Well, there's certainly nothing stopping you from implementing more infrastructure in the public cloud, but if a database is all that's needed, with a public cloud provider you can allocate just a database with no visible server at all. So there are options in terms of how you augment your service offerings.

Other than those considerations, a fast and stable network connection is the only other component required. And if security is a concern in terms of not wanting to use the public Internet, many cloud providers have partnered with telecommunications providers to offer dedicated connections so that your organization is the only entity using that connection.

They're more expensive, of course, but they offer better security and performance because there's no competition on that line. With the hybrid configuration in place, there are some considerations with respect to determining exactly which resources are to be kept solely within the private cloud and which resources can be used in the public.

And in some cases, it might be an easy decision. If, for example, the main concern is protecting sensitive data, then any application or service that touches that data should be kept in the private cloud. If the public cloud was implemented largely to provide better communication and mobility for your sales team, for example, then those services can likely be implemented in the public cloud.

Clearly, the circumstances will vary, but determining the location of any given resource or service can be challenging with a hybrid cloud. On the plus side, a hybrid cloud does effectively offer the advantages of both private and public, because you gain the scalability and the flexibility that are almost limitless in a public cloud environment, while still maintaining the security and the control of a private cloud.

So in many cases, you get the best of both worlds. But of course there are always challenges as well, most notably, the fact that the hybrid cloud is the most complex model to implement and maintain due in large part to the separation of services and information that we just mentioned.

And ensuring appropriate communication between the users and possibly the services of each cloud model can also be particularly challenging, and the cost can quite easily grow beyond what might have been expected in some cases, because you're now paying to support two different types of clouds. So consolidating on one or the other at some point might prove to be a better option.

Lastly, common use cases for a hybrid cloud might include expanding your resources, again, particularly if your organization is growing beyond the means of what your current private cloud can handle, or you may just be looking for transformational services that can help to fundamentally redirect your business operations.

Or maybe you want to evaluate the public cloud environment first as a means to ultimately replace your private cloud with public cloud services, or perhaps the other way around. Ultimately, hybrid clouds can offer the advantages of both models, but maintaining both over the long term can be challenging, to say the least, so in many cases, hybrid clouds tend to be used as stepping stones in determining a better solution overall. But if it provides the solutions you need, there is certainly no harm in maintaining a hybrid cloud indefinitely.

So beginning with BaaS, this model is primarily implemented for environments who are focused on developing mobile applications or websites or web-based applications. And on that note, it's worth mentioning that, in fact, mobile applications are so prevalent now that there is a specific spinoff, if you will, of BaaS, known as Mobile Backend as a Service or MBaaS, which is specifically dedicated to the development of mobile apps.

But before getting into much more detail about any of those services, it's worth making the distinction here between the front end and the back end to ensure that decision makers understand how best to make use of these services.

So generally speaking, the front end is what you and I and everyone else use whenever we interact with an application on our computers or our mobile devices, for example, email is something that almost all of us use every day. So when we open up our email client software to send and receive messages, that's the front end interface.

The servers that initially receive messages, send them out and store all of the messages in user mailboxes represent the back end. Even if you're using a home email type of service such as the Post Office Protocol or POP3, email messages that are sent to you might ultimately reside on your own computer, but they have to pass through a server that hosts your mailbox account first.

And when you send a message out, although it appears to be sent straight from your computer, it goes back through a server of the entity that hosts your account before reaching the intended recipient. So the servers with their databases to store those messages and mailboxes for each user, are the back end components. So how do the services of BaaS and FaaS come into play?

Well, that front end email application has to be built by developers and that's their primary focus. The back end servers, databases and mailboxes, plus all of the physical infrastructure to support them, are typically implemented and managed by network administrators. So in short, developers want to be able to build applications without having to worry about the back end services.

If they had to develop and administer, it would clearly take much longer to complete their projects. But for organizations who are focused on building applications and websites, to be able to build those solutions, back end infrastructure needs to be in place for them to test functionality and deployment, but that's essentially all that it's used for.

So by using cloud services instead of local back end infrastructure, development environments can remove the back end components entirely and simply make use of the back end resources of a cloud provider so that their focus can be solely on development.

So other common BaaS services might include servers to handle user authentication or to send out notifications or alerts, manage database platforms, provide servers for hosting websites, or perhaps just for storing data. These and many other services are all required on the back end for developers to be able to build and test their applications, but by using BaaS solutions, none of it has to be implemented in their own environment.

So little to no administration is required if these services are implemented in the cloud. Advantages of using BaaS can include the ability to focus on the core business of application development, which immediately translates into less time to develop those applications, since the back end requirements are offloaded to the cloud provider.

It can help to standardize the development as well by ensuring that consistent and reliable back end configurations are always available. In an on-premises environment it's not uncommon for these types of resources to become out of date or to drift out of their desired configuration.

And ultimately, the time to market for completed applications can be significantly reduced. So the other option then is Function as a Service or FaaS, which still provides back end services but in a serverless manner, at least from the perspective of the front end. So what does that mean? Well, let's go with the example of a fairly standard database.

Without either of BaaS or FaaS, as mentioned, an organization would have to implement a physical server, install the database management platform, and create the database. That's all well and good but again, that server must now be implemented and managed most likely by your developers, taking time away from the development.

So a BaaS implementation would offload that back end to the cloud, but it would most likely take the form of something like a virtual machine running the database management platform with the database running on that virtual machine.

With no physical infrastructure in the local environment, there is certainly less administration involved, but there is still a server hosting that database. Now, maybe that's exactly what you need, but a serverless architecture means that even the virtual machine is not exposed to you. There is only the database.

This provides the function of the database with virtually no configuration or administration of the server at all. So this allows for developers to write and or update application code on the fly, with no concern for what might need to be done at the back end to implement that change, and allows code to be scaled easily and quickly regardless of the state of the back end server.

As a specific example, when working with a database applications almost always invoke pieces of code known as stored procedures. Using local infrastructure or even a BaaS solution, the code is often submitted to a database administrator to be implemented, because they're the only entities that have the ability to implement or create new objects in the database, often for security reasons.

But once implemented, the administrator might go back to the developer to inform them that it's ready to go.

But if for some reason the implementation didn't work correctly because the administrator did not set the object permissions correctly or the procedure itself didn't function as expected, the developer would have to go back to their code, examine what's happening, perhaps in a local copy, make whatever changes might be needed, and then resubmit, at which point the process starts all over again.

But FaaS implementations simply allow that developer to access live code and modify it on the fly, so that any errors would be realized immediately by the developer, eliminating all of that back and forth. This can help to facilitate even faster development of your solutions because there is often less back end to worry about.

And in most cases the code is entirely scalable along with that back end itself. In other words, the growth of the database or an increase in traffic does not require any kind of contingency code on behalf of the developer. The serverless architecture will handle all scaling requirements automatically, and ultimately, since you're using even less backend in an FaaS implementation, you could save even more on costs.

As always, it will depend on your needs. Some developers do want to have access to the servers for varying reasons, so in those cases BaaS might be a better option. Others may not need them at all, so FaaS might be the better choice. But as a decision maker, what's most important is understanding how each model works and how each can address the issues at hand so that an informed decision can be made.

Now, while many major providers attempt to offer a very wide variety of services, in some cases, no single provider has everything that an organization needs, or even if they do there may be certain areas of specialization within any given provider.

So ultimately, the one whose services best align with the needs of any given project or solution is used for just that specific service. For example, an organization might feel that Microsoft 365 is a better option for the day-to-day operational needs of their users but Google is a better option for developing machine learning applications. Such an implementation can help to reduce your overall operational risk, because over time the relationship with any single provider may become strained.

Perhaps they aren't meeting service-level agreements or their services are becoming outdated, so perhaps another provider can pick up the slack, so to speak. You may be able to leverage the pricing more effectively. For example, when negotiating contracts, a lower price for the same service could be cited if it's offered through a different provider.

And you may be able to avoid what's referred to as concentrated risk, which in simpler terms is not putting all of your eggs into one basket. Using multiple providers can promote better diversity and reduce the likelihood of becoming dependent on a single provider. Now, there is a distinction that should be made with respect to using multiple providers, which is the difference between a multi-cloud implementation and a poly cloud implementation.

Now, in general conversation, you may hear these terms used interchangeably, but in terms of strategies, they are different. A multi-cloud solution means that different cloud providers are used for different services, and those services don't interact with each other.

In a poly cloud implementation different services are still hosted by different providers, but those services do interact with each other. For example, you might choose one provider because they seem to have the best data storage options, but a different provider has the best options for building more powerful or flexible virtual machines. So the virtual machines hosted with one provider, will actively use the data from the other provider.

So if you're considering a poly cloud strategy, it would be important to verify that the services of one provider are able to access the resources in the other in an effective manner that still provides the required level of performance and security for your solution.

Now, big data is certainly a term that has been growing in popularity over the last several years, but it doesn't really refer to any specific type of cloud service. Rather, it refers to data that can be in either structured or unstructured form, but in extremely high volumes. To clarify that, an example of structured data would be a database or a spreadsheet where there are columns and rows, and each piece of data represents the information pertinent to the intersection of the column and the row.

For example, the column header might be an order number and the row might be a specific customer. The intersection then, is the particular order for that particular customer. Unstructured data, however, can be just about anything such as a document, where you can just start writing.

But to better visualize that and to relate it to the extremely high volume just mentioned, consider something like social media posts. There is no basic structure to any given post, but there are millions, sometimes even billions of posts every day. And even with structured data, there can still be just as many entries on any given day if you consider a service like a large online retailer.

So cloud computing and big data go together in terms of using that data to discover more useful information. Structured data such as retail orders might seem more likely to contain useful information because retailers can discover which items sell the most under which circumstances.

But unstructured data can also reveal very useful information by ascertaining which topics are trending, such as political opinions, healthcare or financial concerns, career opportunities, housing, recreational activities or popular travel destinations, all of which can help any organization to make more informed decisions. But the problem lies with processing that kind of volume of information.

Most organizations don't have the internal resources to tackle that kind of volume. So by using cloud services to analyze that data, there are many advantages, including reduced complexity, because there are many different services and data analysis engines that need to be integrated for most solutions.

Cloud providers offer pre-packaged solutions and automated tasks to simplify that integration. Increased agility, in that traditional means of storing data, such as relational databases and spreadsheets, just aren't equipped to handle the nature of unstructured data, nor the volume of big data solutions. Cost savings can be realized because, of course, no on-premises infrastructure is required to implement your solution.

And again, due to the nature and volume of the data, traditional methods of storage and analysis simply weren't designed to work effectively or efficiently with that kind of information, whereas big data engines were designed specifically for that purpose. So the process is much more efficient.

And greater elasticity can be achieved by either scaling up or down your requirements as the demand on the workload changes. With almost all cloud solutions, you still only pay for what you use, so once any given dataset has been analyzed, that data can be purged, making room for future data, which may require more or less space.

But almost any big data provider will be able to accommodate whatever amount you need at any given time. Again, neither poly cloud services nor big data implementations are as common as most traditional cloud services. But when they're needed, they can each provide an ideal solution for any organization that just doesn't have the means to implement those types of services on their own.

To help gain a better understanding of cloud services, it can sometimes help to compare them to what is effectively their opposite. So in this video, we'll examine legacy IT systems to gain better insight into their characteristics, which can, in turn, help a decision maker to make more effective comparisons and ultimately make a better decision if a move toward cloud services is being considered.

So to begin, a legacy IT system refers to any collection of self-managed and maintained systems that typically reside within the premises of that organization. All physical equipment for the organization is purchased or perhaps leased, installed and managed by the internal IT staff of that organization. Now, there could be outsourced staff, but let's not worry about that for the sake of this presentation.

Now, this model has been the standard for many years and continues to be very common for many organizations. But there are a lot of costs associated with this approach, including the data center itself, in terms of rent or ownership, all physical equipment, the salaries of the staff required to maintain it, and all licenses for the applications being used.

This type of approach is typically referred to as having high capital expenditures or CapEx for short, and of course, very little of it is in the form of a one-time cost. Once purchased, equipment and licenses may last for a fairly long time but continual advances in technology almost always render physical hardware obsolete, and software upgrades also require new licenses when new versions are released.

Staff will always need to be paid regardless, and if you are renting, rent will be due as long as you continue to do business in any location. But legacy IT systems do have their advantages, most notably when it comes to control and security. Since all infrastructure is owned entirely by the organization, it's entirely up to you in terms of what you do with it.

And while major cloud providers do offer very robust security, in some cases there may be sensitive data that simply cannot be placed in the cloud. So by keeping that data within the confines of your organization, you can at least ensure that if it is compromised, it wasn't because it was placed into the public cloud. In addition, many organizations may simply have developed a highly customized solution, that is very specific to the needs of their organization.

Such development may have taken years to fully implement and refine, and it may be very difficult and costly to recreate that solution in the cloud. Furthermore, existing resources such as code bases, custom processes and specially designed systems may have been patented or at least considered to be intellectual property of the organization.

So even if migrating them to the cloud is feasible, it may not be desirable because it would expose that property to an inherently shared environment, which could pose an unacceptable risk to the organization. Legacy IT systems may also have a high degree of interdependencies whereby one system relies on or at least interacts with another.

Therefore, moving all interdependent systems to the cloud represents a significant undertaking for the organization, and in some cases, it might not even be possible if the vendor simply does not offer compatible services.

But again, maintaining a legacy IT system presents its own challenges, including limited cashflow due to the significantly higher costs of its infrastructure, which often translates into difficulties with scaling and responding quickly to changes in demand and advances in technology. And of course, if any part of the system fails, backup and disaster recovery options can be limited, particularly if the entire system is contained within a single facility and the facility itself is lost due to a fire or a natural disaster.

You may have implemented the necessary steps to protect your data, but rebuilding the entire infrastructure could take years and could easily result in the loss of the business. So with that said, of course, the other primary option is the use of cloud services, but they don't necessarily provide solutions for everyone.

So making the call on a move to the cloud will certainly depend on having a good understanding of the merits and the drawbacks of your legacy system, and how or even if the cloud can provide a better solution.

In fact, the overall security of cloud environments can often be far more robust than what any given organization can implement in their on-premises environment, simply due to the lack of resources that might be available to them.

So in short, none of the points covered in this video are meant to suggest that cloud implementations aren't or can't be secure. Rather that there are certain factors and considerations that are inherently unavoidable. So as a decision maker, it's important to understand those considerations and to ensure that all factors are considered appropriately.

So that said, a primary consideration is the security of the data that is stored in the cloud with respect to possible data loss, and or data being leaked. Now, the term loss, in this case, does not refer to something like a failed hard drive, rather that the data was able to be removed from the data center through some means, such as intellectual property that was emailed to a competitor.

Leakage means the data did not leave the environment, but it was seen by an unauthorized entity. Now, clearly these are concerns in any environment, but one of the benefits of the cloud is the ability to share data easily with just about anyone. For example, publicly shared folders can be created and invitations can be sent to anyone via email, which of course is ideal for information that you want to share. But this can also make it easier for data that is meant to be kept secure, to be accessed in an unauthorized manner.

For example, there may be a situation where a mix of both are present. In other words, you have data that you want to share, but it is in fact still sensitive, and you should only be sharing that information with authorized entities. But if a shared folder is used and invitations are sent out to only the intended recipients, there really is nothing to prevent any given recipient from sharing that link with anyone else. So anyone with the knowledge of the link could access that information.

Now, there are ways to further protect that data, but that's just one example of how it can be accessed in an unauthorized manner, without any type of network intrusion required. Another concern is simply the location of data. When we as customers store data in the cloud, in most cases we don't know exactly where the data will physically reside. Now, most major providers have data centers in many countries and regions, and you can generally select which region you want to use, but it's up to you as a customer to ensure that you choose the correct region.

And even if you do, in some cases that data might still end up in a region that crosses a border, resulting in possible sovereignty issues. For example, the provider almost always makes copies of all data stored, to ensure recoverability. So it's possible that there are many copies in many locations, depending on the level of recoverability you choose. So data residence is often unknown in many cases, and if that data does cross a border that may, in fact, violate data privacy laws or other regulations that might govern the storage requirements of that data. So there is an inherent lack of control when it comes to storing data in the cloud, that just isn't present when storing data within your on-premises environment.

The exposure of credentials is another issue that is a concern for any organization, regardless of their technology solutions. But since all cloud solutions are accessed through the Internet, the security risks can be much greater. For example, if I'm an outside intruder and I use social engineering techniques to trick a user into revealing their corporate credentials for their internal network, in order for me to make use of those credentials, I either have to gain physical access to their network or I would have to know how to compromise their network from the outside, such as breaking through a firewall.

But if I obtain credentials for their cloud account, all I have to do is access the publicly available cloud portal and log in, and I would have full access to all resources accessible by those credentials, including any and all data that might be considered to be sensitive. Lastly, there are often concerns with maintaining legal and regulatory compliance, which typically dictate stringent requirements as to how sensitive data must be stored and how it is able to be accessed.

For example, information such as payment card data and health records are governed by regulations that require organizations to demonstrate that they limit access to that information through either physical or logical separation of their network, which is then only accessible to authorized personnel within your organization. This may not be achievable in a cloud environment due to an inherent lack of transparency with respect to the network configurations, and of course the data itself must ultimately reside on some physical storage device somewhere at the cloud provider, so there is no real way to know which employees of the provider would have access to that physical device.

So as mentioned, these and other concerns can, in some cases, represent significant obstacles to some organizations, possibly even complete barriers when it comes to using cloud services. But for the decision maker, the most important factor is awareness of these concerns to ensure that they have been fully considered before making the decision.