Please note that this post, first published over a year ago, may now be out of date.
The global cloud computing market is growing rapidly. According to Grand View Research, its size was estimated at USD 483.98 billion in 2022 and is expected to reach USD 619.01 billion in 2023. This is attributed to the variety of economic factors, such as reduction of transactional costs, as well as taking advantage of economies of scale of biggest cloud providers. Transactional costs is an economic term denoting total costs associated with a specific transaction, such as barriers of entry and operation. This includes hiring a skilled team, which became easier with cloud concepts gaining popularity. Economies of scale in turn are describing cost advantages obtained by a business due to the scale of its operation - in this case, big cloud providers. It does not mean that the business benefit gain contributes only to them - on the contrary, the phenomenon allows for reduction in cloud services price. As per the so-called “Bezos’ law”, the cost of Cloud Computing is cut in half every 18 months.
That being said, every choice should always be driven by informed decisions, and making an action just because everybody is doing something is never a good idea (let us introduce another economic term here: herd behaviour). Every decision should be preceded with cost-benefit analysis. There are plenty of sources in the literature regarding benefits stemming from cloud adoption. On the contrary, this article will be focused on difficulties around cloud adoption, and how to respond to them, for the sake of your more informed decisions - especially if you are running a SaaS business.
Know your barriers. Photo by Markus Spiske
Lack of knowledge
According to Statista, one of the major business challenges restraining companies from switching to cloud-native is lack of staff resources or expertise. As IT is one of the most evolving and changing industries, learning was always implicitly encoded in it. Every year is abundant in new technologies, a significant majority of them being adopted as standard. An example may be how the recent ChatGPT solution revolutionised (or has only just started to revolutionise) the industry. Even though “adapt or die” might be at least a slight exaggeration to state, adaptation is still one of the major factors of companies’ success in an ever-changing business environment. You can achieve it either by building a cloud team, hiring external experts, or upskilling your own team. The latter may be especially noteworthy, as exposing a team to new technologies and supporting them in the process of learning is a big motivational factor in the workplace.
Vendor lock-in
Vendor lock-in, meaning being overly dependent on the cloud provider, is another major concern regarding cloud adoption. The above mentioned situation may mean that the cost of changing infrastructure provider may be high. For that purpose, some companies adopt multi-cloud architecture (read here why it is not the best idea). In fact, the solution is far more simpler, and involves state of the art tools, such as containerisation and Terraform to help in building cloud agnostic applications. Of course you still need cloud provider specific knowledge to deploy the solution, but the same may be stated regarding on-premise architecture.
Regulatory compliance
If data sovereignty is a concern, make sure to choose data centers in an appropriate geographical location. The expansion of cloud services made it easier to deploy your solution in the desired location. On the other hand, if you are worried whether your cloud provider meets industry leading best practices regarding information security, make sure to choose one with appropriate certifications, such as ISO 27001, performed by independent third-party auditors. For example, AWS has as much as 99 Availability Zones within 31 Regions (basic units of data centers) at the time of writing and has proven compliance with ISO/IEC 27001:2013, 27017:2015, and 27018:2019.
Lack of reliability
You may also be worried about lots of risks connected to reliability of the cloud services. In fact, that may be attributed to the first bullet point, as all it takes is just a reasonable amount of cloud experience and good architectural patterns. For example, your concern may be what will happen with your application if one of the availability zones goes down. We nearly always recommend deploying SaaS workloads with an architecture running across several availability zones. If zone-level resilience is still not enough, you can replicate your infrastructure in different regions. Then, all is needed to do, is to implement automated monitoring, failure detection and failover mechanisms. Also, you may be interested in different disaster recovery strategies to gain even more control over your architecture.
Security, loss and leakage risks
Contrary to what you may think, security risks may be easier to mitigate when having your workload deployed to the cloud. It is because of separation of concerns: cloud provider is taking care of security of the cloud, and you have to handle security in the cloud. In order to do that, you have a variety of services at your disposal to help you manage this - for example, on AWS you could use security managed services like WAF, GuardDuty, Detective, and Security Hub. These will help you to secure your network properly, as well as automate threat detection and explore findings with minimal engineering overhead. Furthermore, in the cloud it is extremely easy to set up encryption, both at rest or in transit, or logging and monitoring of your workload. If you’re still feeling a little bit lost in these services, you can always hire external cloud experts or invest in team upskilling - for example, AWS has a specific AWS Security Specialty certification.
Integration with existing IT environment
In case your application has a specific requirements which need more custom-tailored solution you may think cloud adoption may be too complicated. In fact, cloud services became even more flexible these days to accommodate number of such cases. For example, if you need to bring your own IP, you can use BYOIP service on AWS. If your application has very specific architecture, you may use emulator with bare metal machine. If you need to deploy your solution across multiple device types, you may be interested in AWS Device Farm.
Loss of control
Another factor indicated by businesses is loss of control. This may be tackled twofold: if your concerns are referring to control over hardware per se, and you don’t want to share hardware with anybody, you may have a look into bare metal instances or dedicated hosts on AWS. The reasons behind such a decision may be security or licensing purposes, or wanting to avoid noisy neighbours (check out our blog article to find out more about this topic). On the other hand, you may also be worried with losing control over what resources are deployed to the cloud. Solutions proposed to overcome this barrier are not cloud-specific, but more general best practices, which shouldn’t be procrastinated to implement under any circumstances: good documentation, Infrastructure as Code, knowledge sharing across your company, team upskilling. Having a knowledge repository and skilled people on the board will ensure you as much control over cloud resources, as you would have over your on-premise environment.
Summary
You are probably familiar with benefits you may gain thanks to going cloud-native due to the abundance of resources in that matter. Nevertheless, every decision regarding change requires an in-depth understanding of risks that can arise, and how to overcome them. It is worth remembering that failing to plan, especially around challenges, often means planning to fail - so hopefully this article will help you to make a better informed decision, as well as understand barriers and risks associated with going cloud-native.
Keeping on top of all the latest features can feel like an impossible task. Is practical infrastructure-modernisation an area you are interested in hearing more about? Book a free chat with us to discuss this further.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
