Disclaimer: the content of this blog is not to prove or justify, if the move to the cloud is feasible, best decision or not, instead it is ONLY intended to highlight some common misconceptions vs. the facts that cloud and solutions architect must be aware of, when architecting a migration strategy to the cloud. As well as to stress on the importance of engaging the right people with the right expertise along with the cloud provider experts at the early stages of such projects.
First, let’s review what are the common major drivers for organizations to consider the adoption of a public or hybrid cloud model, which I am sure most of you are already aware of:
The most common one, is seeking reduction of CAPEX as well as OPEX overheads of ops. To support fast growing environments, dynamic organizations or startups in which can perform various experimentation without investing in high upfront costs, systems can scale out and down (elasticity) to handle any increased load, as well as fester time to market with applications’ development in addition to have the ability to utilize cutting-edge functions and services without major efforts e.g. simple API integration to introduce AI functionalities to their existing services etc.
That being said, still, there is a few misconceptions around cloud benefits or disadvantages:
Myth#1 “Public or Hybrid Cloud is insecure and cannot be a trusted environment to store data”
The Fact: With the right end to end security architecture, the public cloud can be as secure as on-premises data centers if not more in some cases. But because, not many people or companies are deep enough with the knowledge about necessary and foundational cloud security requirements to architect for it, as well as you won’t see a lot of highly skilled professionals today (specially from the enterprise side) who can architect and to build the appropriate level of security in depth in cloud environments (public or hybrid). This does not mean the cloud is more secure for all type of customers. There are some types of organizations even they do not allow Internet reachability for some services and applications.
In General, public cloud providers use the ‘shared responsibility model’, the below chart from aws.com illustrates the divided security responsibilities between the cloud provider and the customer.
Typically, the more you go up in the cloud delivery model (IaaS > PaaS > SaaS) the more the security responsibilities are offloaded to the cloud provider.
Therefore, before assuming, start with small steps, by making sure the enterprise architect or designers along with the security team, gain a good level of understanding of cloud security approach, regulatory controls, security response framework, compliances and then map it to the organization’s requirements and standards, to able to perform full security analysis that is based on actual facts and not assumptions.
The Fact is: Cloud Services are Secure – Are you?
There is more of focus on to the security of the cloud, and less focus on the security in the cloud >> adopt “Security by Design” mentality, and develop new expertise.
For example, the Forrester Wave™: Public Cloud Platform Native Security, Q2 2018 report names Google Cloud a Leader. The report evaluates the native security capabilities and features of public cloud providers, such as encryption, identity and access management (IAM) and workload security. Of the seven vendors, Google Cloud scored highest in the Strategy category.
Myth#2 “Enterprises can achieve more efficient applications’ performance with lower cost by migrating existing applications to the cloud”
This is a common misconception about migrating applications to the cloud
The Fact: By understanding some foundational applications and software architecture, you will find that not many legacy applications are good candidates to be migrated natively to the cloud. For instance, organizations’ home-grown applications or legacy software that were built several years ago, in some cases are probably designed in way that are dependent on the physical hardware it runs on and possibly limited to certain code type and version etc. that might be deprecated or not supported by a cloud provider. This what is commonly referred to as a ‘tightly coupled architecture’, in which the application or software may not function appropriately if its disjointed from its physical environment. Another aspect is the considerations whether the system designed to use stateful or stateless architecture etc.
In addition, you may find that some legacy applications’ architectures were not designed ‘with the ability to be scaled out’ in mind, in which the application or underlying infrastructure can automatically scales out in response to the increased volume of certain metrics such as CPU utilization. Instated, commonly you may find these legacy applications rely on traditional scaling approach which is vertical scaling that is based on adding more hardware resources to the same system (scaling up). With this approach such applications won’t take advantage of the cloud elasticity capabilities
This does not mean those organizations or applications shouldn’t consider moving applications to the cloud, but the point here, is that, not every application or software is a good candidate to be migrated ‘As-is’ instead there must be an extensive analysis and impact assessment to; first decide whether a certain application is a good candidate to be migrated “As-Is” to the cloud or it is more feasible to leave it on-premise or (re-platform it vs. refactor it) using a modern architecture in the cloud (like a statless, loosely coupled architecture) can be a better option, in which it can also support elasticity as well, as loosely coupled applications, key enabling factor to the horizontal scaling, because it’s can be done at different layers of the application architecture/tiers. Architects need to consider the following questions (as a minimum) before considering an application as a candidate to be migrated to the cloud as part of the technical assessment:
Myth#3 “Cloud initiatives always lead to cost reduction of doing business, and if Instagram and Netflix benefiting from being cloud-based, then, for sure everyone can”
Inflated expectations, is something common in IT in general, and about the cloud in specific.
For instance, although Instagram and Netflix are great examples about of global scale, elastic cloud based companies, both can be considered as outliers, because: Instagram had the opportunity to architect and build their infrastructure from the ground up for the cloud, which what can be referred to as a cloud native architecture. on the other hand, Netflix, based on its business decision, all their technology has been placed in the cloud, furthermore, as we know, today Netflix highly skilled engineers who can be considered pioneers in cloud computing, and this as result of business direction as well to hire and train their workforce. The same can be considered applicable on Snapchat case, “Snap entered into a $400 million-a-year deal with the Google Cloud Platform, to provide the infrastructure and services that keep the Snapchat app running”
That’s why, today most common companies who are using ‘cloud native architecture’ are the start-ups because they have the luxury of starting from scratch and architecting for the cloud out of the gate. When it comes to enterprises who wants to take advantage from the cloud, it is not as simple as a start-up, nor its going to be like Instagram, Netflix or Snapchat, as highlighted earlier there are several technical and non-technical considerations, and that’s why today we see the hybrid and multi-cloud models are becoming more popular for many enterprises. Again having the right assessment and evaluation to the current environment, applications and what the organization is trying to achieve, is key to enable the right architectural decision here rather than having ‘inflated expectations’.
Similarly, cost reduction is one of the top most common aspects of the cloud, that cloud be impacted by ‘inflated expectations’. Simply, if you mention the term cloud or public cloud in front of any IT professional, almost always what comes first at the top of his or her mind, is cost saving. Although this is true and key driver for many projects, but it’s not always the case.
Technically, with ‘pay- as-you-go’ model of the services offered by public cloud providers, you can think of it much like utilities model like, water or electricity used at homes. The pay- as-you-go model is without any doubt a cost saving model from CAPEX and OPEX point of views. Specially, if the application was architected and managed in a way that can be optimized with the use of cloud services such as; containerized applications.
However, because cloud services are all metered services, having solutions not architected, sized and monitored well, may lead to unexpected increase in cost. And as mention above, not every application is a good candidate to be migrated to the cloud, as some may lead to unnecessary added cost, or if migration of application that is part of a multi-tiered application stack, is another example of …. also, the cost of integration or migration of legacy applications should not be underestimated.
Therefore, without having a very good insight of the applications and targeted solution architecture along with the required services and functions to be used in the cloud the migration to the cloud may not lead to cost reduction.
On the other hand, having a very good knowledge and understanding of the cloud provider elasticity options like Auto Scaling Groups in AWS, Kubernetes POD and Cluster auto scaling in Google Cloud and may other options, are key to build cost effective solutions that scale down to the minimum when there is no traffic load. For example, horizontal autoscaler will watch certain predefined metrics and compared to the actual number of PODs in use for scale out and in, while vertical auto scaler will look at the load and utilization from the different point of view and will provide recommendation for manual or automated tweaking to meet workloads requirements at a POD level, such as amount of provisioned Memory.
This is a simple example of IaaS workload optimization, without going deep into the details.
As a result, typically will lead to a lot of cost saving. Besides, there are a few billing thresholds options that can be set. Still, all of these options and capabilities they don’t come out of the box, it requires previous awareness and design to be considered.
That’s why it is key to engage experienced cloud and application architects as well as the consultant/architect from the cloud provider at early stages (during the evaluation and assessment stage of the migration) to ensure the business will have achievable roadmap with true and not inflated expectations along with an efficient and cost effective design, that ultimately should map to measurable business benefits and to the key business objectives.