5 ms·

If you're not multi-cloud in 2021 and are expecting 5-9's, I feel bad for you.

by tgtweak 5y ago

ryuta 5y ago
How do you become multi-cloud if your root domain is in Route53? Have Backup domains on the client side?
- tgtweak 5y ago
  dns records should be synced to secondary provider, and that provider added to your secondary/tertiary domain dns. Multi-provider dns is a solved problem.
temuze 5y ago
If you're having SLA problems I feel bad for you son I got two 9 problems cuz of us-east-1
- ShroudedNight 5y ago
  > ~~I got two 9 problems cuz of us-east-1~~ I left my two nines problems in us-east-1
unethical_ban 5y ago
If you're not multi-region, I feel bad for you. If your company is shoehorning you into using multiple clouds and learning a dozen products, IAM and CICD dialects simultaneously because "being cloud dependent is bad", I feel bad for you. Doing one cloud correctly from a current DevSecOps perspective is a multi-year ask. I estimate it takes about 25 people working full time on managing and securing infrastructure per cloud, minimum. This does not include certain matrixed people from legacy network/IAM teams. If you have the people, go for it.
- tgtweak 5y ago
  There are so many things that can go wrong with a single provider, regardless of how many availability zones you are leveraging, that you cannot depend on 1 cloud provider for your uptime if you require that level of up. Example: Payment/Administrative issues, rogue employee with access, deprecated service, inter-region routing issues, root certificate compromises... the list goes on and it is certainly not limited to single AZ. A very good example, is that regardless of which of the 85 AZs you are in at aws, you are affected by this issue right now. Multi-cloud with the right tooling is trivial. Investing in learning cloud-proprietary stacks is a waste of your investment. You're a clown if you think you need 25 people internally per cloud is required to "do it right".
  - unethical_ban 5y ago
    All cloud tech is proprietary. There is no such thing as trivially setting up a secure, fully automated cloud stack, much less anything like a streamlined cloud agnostic toolset. Deprecated services are not the discussion here. We're talking tactical availability, not strategic tools etc. Rogue employees with access? You mean at the cloud provider or at your company? Still doesn't make sense. Cloud IAM is very difficult in large organizations, and each cloud does things differently. I worked at fortune 100 finance on cloud security. Some things were quite dysfunctional, but the struggles and technical challenges are real and complex at a large organization. Perhaps you're working on a 50 employee greenfield startup. I'll hesitate to call you a clown as you did me, because that would be rude and dismissive of your experience (if any) in the field.
    - tgtweak 5y ago
      I advise many fintechs with engineering orgs from 5 to 5000, 2 in top 100 - none are blindly single-cloud and none have 25 people dedicated to each of their public clouds. The largest is not on any public clouds due to regulation/compliance and have several colocation facilities for their mission critical - they have less than 25 dedicated in the entire netsec org. This is a company that maintians strict PCI-DSS1 on thousands of servers and thousands of services. If you're employing 25 people per cloud for netsec in a multi cloud environment you have some seriously deficient DevOps practices or your org is 5-figure deep and has been ignoring devops best practices while on cloud for a half decade. Hahsicorps entire business revolves around cloud agnostic toolkits. All clouds speak kubernetes at this point and unless you have un-cloudable components in your stack (like root cert key signing systems on a proprietary appliance) you really should never find yourself in such a scenario where you have that many people overseeing infra security on a public cloud. It's been proven time and time again that too many people managing security is inversely secure.
- throwmefar32 5y ago
  This.
- ricardobayes 5y ago
  Someone start devops as a service please
post-it 5y ago
I imagine there are very few businesses where the extra cost of going multi-cloud is smaller than the cost of being down during AWS outages.
- gtirloni 5y ago
  Also, going multi-cloud will introduce more complexity which leads to more errors and more downtime. I'd rather sit this outage out than deal with daily risk of downtime because I'm infrastructure is too smart for its own good.
  - shampster 5y ago
    Depends on the criticality of the service. I mean you're right about adding complexity. But sometimes you can just take your really critical services and make sure it can completely withstand any one cloud provider outage.

If you're not multi-cloud in 2021 and are expecting 5-9's, I feel bad for you.

ryuta 5y ago

How do you become multi-cloud if your root domain is in Route53? Have Backup domains on the client side?

tgtweak 5y ago
dns records should be synced to secondary provider, and that provider added to your secondary/tertiary domain dns. Multi-provider dns is a solved problem.

temuze 5y ago

If you're having SLA problems I feel bad for you son I got two 9 problems cuz of us-east-1

ShroudedNight 5y ago
> ~~I got two 9 problems cuz of us-east-1~~ I left my two nines problems in us-east-1

unethical_ban 5y ago

If you're not multi-region, I feel bad for you. If your company is shoehorning you into using multiple clouds and learning a dozen products, IAM and CICD dialects simultaneously because "being cloud dependent is bad", I feel bad for you. Doing one cloud correctly from a current DevSecOps perspective is a multi-year ask. I estimate it takes about 25 people working full time on managing and securing infrastructure per cloud, minimum. This does not include certain matrixed people from legacy network/IAM teams. If you have the people, go for it.

tgtweak 5y ago
There are so many things that can go wrong with a single provider, regardless of how many availability zones you are leveraging, that you cannot depend on 1 cloud provider for your uptime if you require that level of up. Example: Payment/Administrative issues, rogue employee with access, deprecated service, inter-region routing issues, root certificate compromises... the list goes on and it is certainly not limited to single AZ. A very good example, is that regardless of which of the 85 AZs you are in at aws, you are affected by this issue right now. Multi-cloud with the right tooling is trivial. Investing in learning cloud-proprietary stacks is a waste of your investment. You're a clown if you think you need 25 people internally per cloud is required to "do it right".
- unethical_ban 5y ago
  All cloud tech is proprietary. There is no such thing as trivially setting up a secure, fully automated cloud stack, much less anything like a streamlined cloud agnostic toolset. Deprecated services are not the discussion here. We're talking tactical availability, not strategic tools etc. Rogue employees with access? You mean at the cloud provider or at your company? Still doesn't make sense. Cloud IAM is very difficult in large organizations, and each cloud does things differently. I worked at fortune 100 finance on cloud security. Some things were quite dysfunctional, but the struggles and technical challenges are real and complex at a large organization. Perhaps you're working on a 50 employee greenfield startup. I'll hesitate to call you a clown as you did me, because that would be rude and dismissive of your experience (if any) in the field.
  - tgtweak 5y ago
    I advise many fintechs with engineering orgs from 5 to 5000, 2 in top 100 - none are blindly single-cloud and none have 25 people dedicated to each of their public clouds. The largest is not on any public clouds due to regulation/compliance and have several colocation facilities for their mission critical - they have less than 25 dedicated in the entire netsec org. This is a company that maintians strict PCI-DSS1 on thousands of servers and thousands of services. If you're employing 25 people per cloud for netsec in a multi cloud environment you have some seriously deficient DevOps practices or your org is 5-figure deep and has been ignoring devops best practices while on cloud for a half decade. Hahsicorps entire business revolves around cloud agnostic toolkits. All clouds speak kubernetes at this point and unless you have un-cloudable components in your stack (like root cert key signing systems on a proprietary appliance) you really should never find yourself in such a scenario where you have that many people overseeing infra security on a public cloud. It's been proven time and time again that too many people managing security is inversely secure.
throwmefar32 5y ago
This.
ricardobayes 5y ago
Someone start devops as a service please

post-it 5y ago

I imagine there are very few businesses where the extra cost of going multi-cloud is smaller than the cost of being down during AWS outages.

gtirloni 5y ago
Also, going multi-cloud will introduce more complexity which leads to more errors and more downtime. I'd rather sit this outage out than deal with daily risk of downtime because I'm infrastructure is too smart for its own good.
- shampster 5y ago
  Depends on the criticality of the service. I mean you're right about adding complexity. But sometimes you can just take your really critical services and make sure it can completely withstand any one cloud provider outage.