According to Gartner, the worldwide public cloud services market is forecast to grow 17% in 2020 to total $266.4 billion, up from $227.8 billion in 2019. While the benefits are too compelling to ignore, every mix of private, public, and hybrid cloud infrastructure comes with a new set of challenges and risks. The industry is learning that increased flexibility also means rethinking availability, security, and compliance procedures.
These challenges present themselves at the very outset, when IT managers evaluate the best cloud provider(s) for a given set of applications.
(Source: ChiefMartech 2019 SaaS landscape)
Without an in-depth understanding of the new mindset cloud technologies demand, it’s easy to build a new cloud application stack on a rocky foundation by making these common nine mistakes when choosing a cloud:
Simply making the decision to “move to the cloud” is just a first step. Beyond private, public, and hybrid cloud environments, every cloud setup and provider comes with a set of predefined services along with respective cost/performance levels. The right cloud mix depends on your specific requirements, in addition to the applications and infrastructure in which you’ve already invested. For example, a private cloud will deliver increased flexibility but will also be less scalable. On the public end of the spectrum, if you’re already invested in a vendor (for example, IBM or Microsoft), you are likely better off working with the public cloud offering of the same vendor for a smoother cloud migration ride.
(Source: Gartner)
Expect different cloud providers to produce different performance levels for a given application. Moreover, the same cloud provider will deliver different performance in different regions – depending on how you take advantage of the provider’s infrastructure and services. For any given setup, your application will behave differently. It’s up to you to plan for specific performance levels and prepare to tweak them until you reach your goals.
Cloud providers are not OS-agnostic. If your infrastructure is heavily dependent on Windows, Google is quite simply not an option. In fact, some legacy systems aren’t supported by any cloud provider. Do your homework before committing to a provider!
Every application stack will consume different levels of resources. A storage management system is a very different animal from a graphic processing engine. The more specialized your application, the more likely your cost is to vary considerably across different providers.
Similar to performance, every provider has its own SLA, and even specific SLAs per service. For example, while AWS commits to virtually no long-term data loss, you should expect 99.95% availability at best when it comes to compute resources.
If your application is based on specific virtual appliances (e.g. payment gateways or security firewalls), it’s unlikely every cloud provider will be able to provide the same level of support. Review your application components carefully to avoid missing that critical component at an advanced implementation stage.
Every cloud provider offers a different mix of services, supported 3rd party services, and data center architecture. If you ignore these unique characteristics, your setting yourself up for a project that is virtually impossible to predict in terms of cost, performance, and maintenance requirements.
Choosing a cloud doesn’t mean you need to move all your applications to a single environment. For each part of every application you run, you may choose a different approach.
Application downtime is a challenge in cloud environments at least as much as in bare metal infrastructure. It is up to you to ensure your applications remain available through cloud outages, and that it is easy to migrate to the cloud from your existing setups. While specific tools and 3rd-party services exist to help you manage this process, not every cloud provider will support these tools. It’s up to you to plan for RPO (Recovery Point Objective indicating acceptable data loss), RTO (Recovery Time Objective indicating maximum time limit until system is up and running with recent data), and automated migration requirements for the long term.
By Leonid Feinberg
