Transition to a cloud platform is a challenging task that needs a proper strategy and meticulous planning. Successful cloud migration implies considering important steps that include a detailed review of your current infrastructure, assessing different cloud platforms and your application cloud readiness, performing capacity planning, developing and testing infrastructure designs. Considering these factors up-front is a proven way to successfully adopt and benefit from a cloud computing model.

 

However, apart from migration milestones, there are things that also need consideration. Seemingly of less importance, they can overshadow the brightest cloud strategy if left neglected. In this blogpost we shall outline which things may come as unexpected obstacles on the way towards building an effective cloud strategy.

Complicated pricing

In theory, the pricing model of cloud services is fairly straightforward: you request the capacity, get it from a cloud vendor, and pay for it. You manage your cloud resources by spinning them up and down, and pay only for as much as you have used. Unfortunately, it’s not all that simple.

 

To begin with, you have to wade through the variety of options that your cloud provider offers. Operating systems, compute, network, memory, and disk space – all these factors are counted when defining the type and size of your instance and, subsequently, its pricing. And this is just the tip of an iceberg. For example, in AWS each of the instance types falls within a special category aimed to fit different use cases, such as general purpose, compute optimized, storage optimized, memory optimized, and accelerated computing. On top of that, each instance type comprises a family of virtual machines that vary in size, i.e. number of CPU cores and memory, and features. With so many details and nuances picking out the right combination of instances could be quite challenging.

 

There is also a problem with a cloud management console: you can’t get a clear idea of what you are spending unless you are familiar with the cloud UI. For example, to understand the whole picture of your spending in AWS you have to apply for each service in each region isolatedly due to the utmost independence of components in AWS. Needless to say, this takes a lot of time and effort. And don’t forget – each service is billed in a different way, which is really confusing as you start using more services from your cloud provider.

Default security

Most cloud vendors aim to create a secure solution for their customers. In order to achieve this they provide a centralized security policy that embraces base security issues: protection from external and insider cybersecurity threats, enhanced traffic analysis and web filtering, monitoring of network events, etc.

 

However, no matter how cloud vendors try to avoid security issues with the services they provide, they can’t control how customers use their services. Insecure application programming interfaces (APIs), poor configuration, sensitive data, and weak access policies – all these factors pose a potential threat to your system and data. In other words, the security of your own space within the cloud is your responsibility. First and foremost, this applies to protecting your data and controlling who can access that data.

 

It is a good practice to authenticate by private keys instead of passwords and close unused open ports. To prevent unauthorised access, use access control lists and IP filtering. Be sure to encrypt your data. Overall, cloud migration is a good occasion to revise your safety strategy and build security into every level of your system.

Right type of cloud architecture

Simply transitioning your application to the cloud doesn’t mean that it is going to deliver the value that enterprises expect. In order to successfully adopt a cloud computing model and reap all its benefits, you need the right type of application architecture. There is no “one size fits all” approach. Rather, it is your business and technology service requirements that define the type of cloud architecture for your project.

 

You don’t need to virtualize everything across the board. For example, you can keep main workloads on bare-metal servers and quickly scale them with cloud resources when needed.

 

From baseline to more complex ones, including multi-data center architecture, hybrid cloud site architectures, global server load balancing, etc., effective cloud architectures follow certain design principles. These fundamental rules include:

 

  • following best practices and software development concepts when designing cloud-ready applications;
  • implementing redundant design with duplication of critical components for failover and recovery purpose;
  • load balancing for controlling and distributing traffic according to certain patterns;
  • modelling and design for performance and scaling;
  • using redundant architecture types for production workloads, and non-redundant for development or testing environments only.

Less of administering overhead

Virtualization and absence of hardware level doesn’t mean that you can do without system administrators. This is by no means true. Cloud migration neither eliminates the necessity to administer your resources, nor could it replace the work of your admin staff. Moreover, when it comes to setup and maintenance, cloud infrastructures need no less attention than physical ones: think of configuring and managing virtual machines and networks, IpsecVPN setup, configuring VPC firewalls, performing cloud backups (other than snapshots), etc. Add here setup of CI/CD pipelines, capturing infrastructure in code, configuring logging and monitoring, and you will see that clouds have plenty of tasks for your admins to work over.

Conclusion

Clouds entice businesses with convenience of use and flexible usability model. However, its seeming plainness may turn out treacherous unless you consider all details before the migration. Among main challenges that could undermine cloud strategy are unexpected expenses, cloud complexity and security of cloud environments.