The cloud is riddled with vendor lock-in
When using a PaaS service, be aware of vendor lock-in issues. If you do need to move cloud vendors someday, will you be able to? If this at all concerns you, be careful with PaaS. Perhaps containers are a better choice.
Understand security models
AWS has a wildly different security model than Azure. Understand your options for authentication and authorization for your candidate vendors. Understand the cost differences too.
- Will your cloud vendor backup/replicate your data outside of your political boundary?
- Many PaaS services are public endpoints (that’s how they get scale and profitability). Are you ok with that?
- Understand Separation of Responsibilities. What is your responsibility and what is your vendor’s?
- Who is responsible for your data integrity and how is that handled?
- If a service goes down and your vendor won’t fail over to another region, can you manually do it? How?
- Does your network traffic flow over the public internet when moving around your cloud vendor’s regions? Or does your vendor use “dark fiber”? Do you get charged for that? How reliable and stable is it?
Need to do a cloud migration? Need a second opinion? I actually do this stuff everyday. Engage with me for your next assignment ›
Smartly Leverage the Cloud
Not every workload needs to go to the cloud. And you don’t need to begin by “lifting-and-shifting” individual workloads to the cloud. Consider, instead, these alternatives to begin your cloud journey:
- use the cloud for elasticity on-demand. Have your applications, especially front-end servers, leverage the cloud for scaling.
- advanced DR workloads. Why pay for a second DR data center? This is also a great way to get started on your cloud journey. Your staff gets training on cloud paradigms on their schedule. If done correctly you can simply “failover” to your cloud provider and your initial lift-and-shift is complete.
- CDNs are also a great way to dip your toe in the water.
- Pre-baked AI (Azure calls them Cognitive Services) as well as Big Data and Data Science tools are wildly expensive to deploy in your data center, but frankly are cheap in the cloud. The ancillary benefit is that if (when) these projects fail you didn’t have a huge capital project to continue to amortize.
The point is: you don’t need to lift-and-shift existing applications to begin leveraging cloud economics.
Application Optimization is the Key to Cost Containment and Performance
Here are the general phases most companies use to move workloads to the cloud. You can definitely tactically combine features of multiple phases together:
- Phase 1: lift-and-shift (Rehost)
- VMs are wholesale moved to the cloud
- the cloud tends to be more expensive for VM hosting, leading to buyer’s remorse. You can never just stop at lift-and-shift
- this is a good place to start, just note that it’s the beginning, not the destination
- Phase 2: leveraging PaaS (Refactor)
- move workloads to PaaS where you are no longer managing “Operations”. This allows you to focus on solving business use cases. You want to get out of the HADR and backups business. Let your cloud vendor worry about that.
- PaaS is generally a bit more expensive (see the “PaaS Tax” above) but ultimately you can lower costs using smarter scaling
- Phase 3: Rebuild for the Cloud
- rebuild your application so it is cloud-native.
- use microservices
- Utilize caching, serverless compute, containers
Moving to the Cloud - Anti-Patterns
Regardless of which phase you ultimately want to get to, there are some anti-patterns that will need to be refactored or your cloud migration will likely fail.
- Chatty applications need to be made less chatty
- webpages and processes that pull a hundred rows from a database in RBAR (row by agonizing row) fashion will never perform on the cloud
- IO is the slowest part of any system and this is exacerbated in the cloud. This is why cloud vendors insist you always consider a judicious use of caching.
- underestimating bandwidth requirements is common. It’s also quite difficult to properly estimate your real on-prem bandwidth requirements.
- polyglot persistence
- not everything needs to be stored in a SQL Server. Database-as-a-Service is the highest-priced PaaS. Think about what you store in your SQL database today. Does that data really lend itself to a SQL database? Could it work better in a key store? Or an object store? The only data, IMHO, that truly needs to be in a relational database manager is data that ultimately needs to be reported on. Any other data can be persisted more cheaply elsewhere.
- Use microservices
- When your application is decomposed you can then scale individual components vs entire systems. It’s that simple
- Most webapps have a handful of functions that require 80% of the processing. Imagine if you could find just one of those functions that could be refactored as a serverless Azure Function or AWS Lambda Function, which could then be scaled independently from remainder of your application. That could save you some serious bucks.
- Containerization (in general) will help you think in a decomposed manner.
Being contructed in the cloud is like being constructed of pipes.
- Have a DevOps strategy and insist on scripting everything with automated build/deploy
- Gone are the days of having runbooks/manuals with page-after-page of instructions to rebuild a VM.
- The more you can script and automate your application the more you will understand it and be able to make smarter decisions in the future.
- Always think in terms of being “ephemeral”. If I accidentally delete some service or VM I should be able to click a button or run a script and have a replacement available within minutes.
- The side benefit of this is: you don’t need HADR for the compute services any more. Only your data. So…
- Whenever possible, separate “compute” from “storage”
- In the past your data was locked up in your database server. Don’t do that in the cloud.
- Try to persist your data to an object store (S3, blob) where individual applications and users can choose the compute engine to match their needs.
- If my data is in a blob store I may choose to use Databricks to query it and you may choose to use a data warehouse. What I don’t want to do is make a copy of data whenever I want to use a different compute engine. Avoid ETL.
- Gone are the days where you couldn’t do analytics queries on an OLTP system for fear of performance degradation or lock escalations. Think in terms of the “logical data warehouse” or “semantic query tier”.
Are you convinced your data or cloud project will be a success?
Most companies aren’t. I have lots of experience with these projects. I speak at conferences, host hackathon events, and am a prolific open source contributor. I love helping companies with Data problems. If that sounds like someone you can trust, contact me.
Thanks for reading. If you found this interesting please subscribe to my blog.