My Blogs - Cloudhaven
Upcoming articles on Cloud.
The needs for auto-scaling - Why auto-scaling is the Cloud way for applications and huge workloads - Why auto-scaling by metrics and not any other way - Steps to work out before auto-scaling - What to auto-scale - How to avoid auto-scaling everything - How to set thresholds to auto-scaling
What is a disaster? - Define disasters in IT - Local IT, Network/Power outage, ISP/DNS Failure - What is disaster recovery - Steps to do for disaster recovery - Scales in terms of sites and infrastructure for disaster recovery - Diff between disaster recovery and backup recovery solutions - Maintenance of the DR setup
Cost effectiveness on the Cloud - Penny wise, Pound foolish - Cloud can eat you up, you wont know - Billing alerts - Rightsizing your Cloud - Use native Cloud features - Design cloud native apps for Cloud - Transition from Monolithic to Cloud native - Use microservices - Create apps that fail fast and fail gracefully - Automate your infrastructure to provision and de-com on the fly. - Adopt open source solutions and customize for needs.
If any one dare to me that Cloud is not a good step to go. Let him come to me for I would like to know his application, requirements and his implementation. Cloud can be used for multiple digital platforms for development, testing, engineering, R&D, Disaster Recovery or even sample proof of concepts.
Things you need to know before moving to the Cloud - Thought process change - Not anymore your On-Prem - Things work differently - Failures are non-reversible - Backups need to be redundant and often - Data Security requires encryption at rest and transit - Data is billed and any such data needs to be safely disposed in secure best data erasing practices - Network inflow/outflow during any data transfers could be charged for transit and system design should include this in process if you plan to backup to your local datacenter before pushing it to the Cloud. - Retrieve from archived storage could be charged and hence the data lifecycle needs to be planned for optimized use of ready data and to seldom use archived data. - Choose Cloud features wisely and try to remain Cloud native so you could move between the Vendors. - Plan ahead for such movement as movements incur costs for data export and import, ETLs and data conversions to the new Cloud vendor. - Try not to be vendor locked in Cloud and space out your solutions and DR setup between Clouds if possible. As of now, there is no single window for all Cloud vendors and data pipelines are manual and a error intensive process. Export and import tools are provided by popular Cloud vendors but are not cross compatible as it could have been. Changes in these lines should occur very soon for Cloud vendors to onboard a large number of clients to their respective Cloud infrastructure. - Try and move to faster and Cloud friendly technologies from huge mainframes and monolithic applications, from heavily relational databases to simple yet lightning speed document based result sets. - Adopt Open source solutions that provide similar or advanced features for your needs, reduce licensing costs and utilize Cloud optimized variants of these open source softwares for better performance. Failures are imminent even on Cloud because your data is stored not in the "Cloud" but in another man's computer. Prepare for failures and plan ahead for business continuity within the provided Cloud infrastructure or with your own Public Cloud datacenter.