Myth #1: The cloud is less secure than on-premise or The cloud is more secure than the on-premise
The truth is that they are both right and both wrong. The real answer lies somewhere in the middle.
When comparing managed services (SaaS) such as SAP SuccessFactors, Oracle CRM, Office 365, SalesForce, etc., to similar services provided on-premise, they cannot be compared to on-premise models.
On the one hand, the customer shifts the burden of security and maintenance to the cloud provider, and on the other, mature cloud providers (such as those mentioned above), invest huge amounts of money (when compared to most organizations) in information security, penetration testing, audit trails and constant training to their support and information security teams.
The comparison of IaaS solutions and on-premise models is different. According to the shared responsibility model, customers get access from the operating system and above, and they are solely responsible for everything that happens inside the operating system. This includes backups, hardening, updates, authorization, access control and defense against attacks.
The IaaS model is similar to traditional virtualization from the local data center. But top IaaS providers enable access to various managed services in order to ease the burden on server maintenance (from managed databases, through backup services, patch management, vulnerability management, etc.)
Bottom line – It is possible to reach the “sweet spot” where using the cloud makes an organization more secure than using on-premise, as long as we are familiar with the cloud providers services and capabilities and as long as we learn how to make the most out of these services on-going basis.
Myth #2: The cloud is more expensive than on-premise or The cloud is less expensive than on-premise
Again, the truth can be found somewhere in the middle.
In order to make an accurate comparison of on-premise and cloud solutions, we need to take into consideration several factors. These include the cost of hardware, several years of maintenance, licenses, backup and archive storage, system availability and most important – manpower costs for system maintenance, including training of IT, development and security teams.
When comparing managed services, such as managed databases vs. manual maintenance of on-premise databases, the calculation would look something like this. The cloud saves maintenance cost, hardening, patching/updating, and even backups, if they are part of the managed service. That translates into significant savings on maintenance costs, compared to on-premise environments, and allows organizations to consume services without the burden of maintaining the systems.
When comparing IaaS environments, the picture changes. The costs of the cloud servers, in a pay-as-you-go model, in most cases are higher than comparable on-premises models (when comparing the same amount of vCPU and memory). In order to cut costs in IaaS model, we need to understand if we are dealing with a high-performance workload and changing run time, or are we are dealing with servers operating 24×7 for a long period of time. And if we are dealing with the long-term, it is highly recommended to purchase reserved instances for 1 or 3 years in advance.
Another alternative for saving server costs in an IaaS model is to choose Spot model and save up to 90% of the price, assuming the service itself is not fault-sensitive and can be recovered automatically, such as batch processing, image processing, etc.
The best alternative for saving server costs will require re-architecting our systems (as much as possible) and migrating to building systems based on micro-service architecture, or use Serverless services and cut the cost on resources and monthly costs to the minimum required.
Myth #3: The cloud is complex or Cloud migration is always complex
Migrating existing services from on-premise to managed services in a SaaS model varies from one cloud provider to another, which makes it hard to generalize.
When migrating to PaaS services, there are many guidelines and tools to assist organizations with the migration process. Some examples include AWS Database Migration Service, Azure Database Migration Service, Google BigQuery Data Transfer Service, etc.
Migrating systems to IaaS model requires training IT personnel on how cloud providers implement infrastructure services, such as VM deployment, setting network access rules, connecting to storage, settings permissions, etc.
Organizations who train their IT, networking and information security teams on working with IaaS and PaaS environments will be able to make the migration process easier. There are many low cost online courses to assist closing the required knowledge gap.
If you want to migrate really easily (“fast and dirty”), you can always choose to migrate systems using “lift & shift” method, at least during the first phase, although it is not considered a cost-effective solution. Sometimes similar hardware in on-premise environments is cheaper than similar hardware in an IaaS environment. But this method will allow the organization access to migrated environments and later on, to adapt the required resources to allow the system to function, change the system architecture, such as replacing servers with managed services, etc.
Bottom line – It all begins with organizations willing to adapt to working in cloud environments and, of course, management support for cloud migration.
Myth #4: Multi-cloud will prevent vendor lock-in
When organizations take their first steps toward working with public cloud solutions, it makes sense to choose a single IaaS provider in-order to allow the organization to train employees, plan cloud migration strategy and begin the actual cloud migration phase and deployment of the new environments.
The fear of vendor lock-in, or from the cloud provider going bankrupt, is not unreasonable. However, the most likely complementary control mechanism is to choose one of the hyper-scale cloud providers and mitigate the risk of the cloud provider going bankrupt.
Theoretically, selecting multiple IaaS providers might allow migration between providers, but in reality, moving to multi-cloud environments creates many challenges. These include the requirement to enforce central authentication, requirements to understand how each cloud provider implements services differently (such as storage, network, compute, etc.), understanding how to deploy new environments over multiple cloud providers’ infrastructure, understanding how to enforce logging/auditing and how to centrally handle incident response processes over multiple providers, etc.
When you want to mitigate the risk of vendor lock-in and allow organizations to move environments between cloud providers, we need to plan our infrastructure architecture ahead of time – from the very beginning phases and based architecture on Containers or Kubernetes. As long as services are wrapped in containers, you will be able to deploy and run them over multiple cloud providers. Also take into consideration the integration with each cloud providers’ ecosystem, such as storage, monitoring, message queuing services, etc.
Bottom line – deploying production environments over multiple cloud providers requires a deep understanding of the cloud ecosystem. Instead of resolving vendor lock-in risks, it can create high overhead for the organization, which may not be justified relative to the risk of vendor lock-in. Moving to container-based architectures might ease the organization’s ability to work with multiple cloud providers.
Myth #5: Auditing cloud environments is hard
Correct. But only partially.
Cloud migration requires customers to understand that they may not be able to conduct on-premise audits of the cloud providers’ data centers, as we used to conduct with hosting providers in the past. But on the other hand, mature cloud vendors provide us with complimentary audit controls, such as:
- Audit access on SaaS solutions: Office 365, SalesForce, Oracle HCM, etc.
- Audit access of cloud providers’ employees on SaaS solutions: Office 365 Customer LockBox, Oracle Break Glass, etc.
- Audit access on IaaS/PaaS solutions: Amazon CloudTrail, Google Cloud Audit Logs, etc.
- Access to external audit reports such as ISO27001, SOC 2 Type 2 (assuming we signed NDA with the cloud provider): AWS Compliance Programs, Microsoft Trust Center, GCP Compliance resource center, etc.
- Conducting penetration tests on cloud environments (usually in IaaS environments): Azure, AWS, GCP, etc.
Bottom line – It is possible and highly recommended to constantly audit cloud environments. Choosing one of the mature cloud providers will allow various complimentary controls in order to assure that cloud environments are secure and comply with standards and regulations.
Myth #6: Migration to the cloud will cut manpower and cause employee job security issues
This perhaps one of the most common myths. But inaccurate.
It is true that IT and information security teams will need to undergo training to work with various services and adapt existing knowledge from the on-premise environments to cloud environments. But here lies the great potential.
If in the past we used to have deep knowledge in a specific field, such as operating systems, networking, storage, databases, information security, etc., today organizations migrating to the cloud are looking for employees with multidisciplinary knowledge.
The migration from on-premise models to the cloud will require organizations to streamline. Although migration to SaaS or managed services requires less IT personnel, the migration to IaaS/PaaS environments requires a shift in the mindset of IT teams. They will need to adapt existing knowledge from manual work, like server maintenance, databases, environment deployments, etc., to automation, like writing code (but no need for professional developers), switching to environment deployment based on Infrastructure as a Code, etc.
This ability to adapt will be in high demand by organizations. They will seek professional IT personnel and will make existing IT teams, who adapt to the changing world, even a more valuable asset to their organizations.