6 ms·

Disclosure: I work at AWS, and might surprise you that I disagree. Opinions my own. I see this line get touted a lot but it is almost never accompanied by any

Disclosure: I work at AWS, and might surprise you that I disagree. Opinions my own. I see this line get touted a lot but it is almost never accompanied by any depth. It sounds good, but what does it actually mean in practice? Do you have concrete examples of what using the best parts of AWS, GCP, and Azure are? From where I'm sitting, the best parts of the cloud were created 10-15 years ago: On-demand compute (without dealing with the joys of subnetting, DHCP, and configuring Linux interfaces), object and block storage, managed databases/DNS/load balancers. The newer features tend to lack the things you really need in a production ready service: monitoring, debugging, configuration, etc. The right answer to this multi-cloud question is to stop having so many different components in your stack. Be painstakingly deliberate about what you adopt and have someone who can articulate (ideally in writing for posterity) why you're adopting it. Pick a few foundational primitives and master them operationally. One relational database, one web server, one load balancer, one cache, zero message queues ;). (Spoiler alert: this is what all of the cloud vendors themselves do internally.)

dastbe 6y ago
(also work at aws) i think that spoiler alert is a little overgeneralized. first, there’s plenty of advances in those categories in the past 5 or so years (lambda, fargate, qldb, a bunch more) that move the needle significantly on the versions of things that existed 10-15 years ago. we didn’t collectively get everything right by 2012, and i heartily endorse customers using things that take away operational complexity but are less “complete” compared to the lower level counterparts. second, you missed mentioning that circular dependencies is a very real reason for why cloud vendor service teams can’t (not won’t) use services that would otherwise benefit them. this is a problem that is much less apparent to customers of clouds because, to them, the suite of services is provided as a single flat layer of options. i do agree that you want to make sure any service you use is “complete” for you, but that completeness can exist on a spectrum and sometimes getting onboard early and driving their roadmap can benefit you greatly. i also agree that you want to be conservative with how many services you do use, because each one without exception will become a learning experience.
tyingq 6y ago
"It sounds good, but what does it actually mean in practice?" I think what I was saying is pretty straightforward... "If you're going to the trouble of being agnostic" Meaning that if you're trying to build some sort of facade that makes AWS and GCP look the same, you might as well just make a facade that points at something cheaper than AWS/GCP. AWS/GCP markup for things like internet egress, storage, and compute are high, partially because of all that plumbing. Any facade puts you in a lowest common denominator situation where you're paying for lots of stuff then not using it. Or, in short, "cloud agnostic" running on cloud is a weird idea that throws out lots of the value add. Perhaps there are some exceptions for very simple architectures, as you hint.
- rubiquity 6y ago
  > I think what I was saying is pretty straightforward... I was asking you to give specific examples. > Perhaps there are some exceptions for very simple architectures, as you hint. Simplicity should be the goal and the starting point.
  - Terretta 6y ago
    S3 and DynamoDB would be the two I’d mention first (since know it or not, folks are relying on them anyway), then things like Fargate, QLDB, and PrivateLink. Agree on the simplicity point, though the key is not just simplicity for coding, or for communicating about the architecture, but emphasizing simplicity of operation and honesty at the skills, abilities, and criticality of operating and resolving things under stress. Several years as AWS CAB member show this topic is hotly debated. I think there’s this “third way”, to purposefully exploit the different DNA of the top CSPs. I choose that word “exploit” to appeal to the board room, to feel they get more than they have to pay for (which I think is true, thanks to CSPs’ focused spend). A more friendly way of putting it from CSP point of view is “leverage what we’re best at”. Rare case of genuine win-win.
Tehnix 6y ago
> From where I'm sitting, the best parts of the cloud were created 10-15 years ago I just moved from a startup that was running things on services that were either created or only really matured within the past three years, to a different startup running on tech from 10-15 years ago. The differences in Ops overhead and scalability is huuuuuuuge to say the least. Modern infrastructure on AWS for me would be: - Lambda - DynamoDB - S3 - Fargate - EKS to a certain extent - And extremely excited about Serverless Aurora V2 Older infrastructure with massive ops overhead: - EC2 - ElasticBeanstalk - RDS MySQL/PostgreSQL Every year at AWS re:Invent I see the needle moving into more serverless stuff, and for a very very good reason. To maybe take up some of your points: > On-demand compute EC2 and RDS are the absolute bare minimum you can do for on-demand compute and was the initial introduction to the elasticity of the cloud. It's slow and cumbersome to scale up and down, and also very costly to do so (RDS is basically a x2 of you instance size every time). That's skipping automatic scale - for RDS? Forget about it. > The newer features tend to lack the things you really need in a production ready service: monitoring, debugging, configuration, etc State of anything running on EC2: You are 100% responsible for getting your metrics and logs out of the instances, you get close to worthless OS metrics by default, that might tell you info about some scaling events, but no insights into you actual applciation. State of serverless: Built-in integrations with CloudWatch for monitoring and XRay for profiling. Out of the box you have error reporting on Lambdas along with DLQ and much more. > without dealing with the joys of subnetting, DHCP, and configuring Linux interfaces I honestly hold the opinion that if you deal with things at this level of the infrastructure stack, then the "modern cloud" is not relevant to you (AWS, Azure, and GCloud), but you would fit better or something like Hetzner or with dedicated servers.
- bsder 6y ago
  I always thought that "cloud" was overhyped and never understood why you would want to use stuff like EC2 over a dedicated server somewhere. Honestly, the idea that the new services have a "higher level of abstraction" and that old services are an insufficient extra level of abstraction is something I could never articulate properly. Thanks.
thewarrior 6y ago
Aren’t message queues a basic primitive in a highly available system ?

dastbe 6y ago

(also work at aws) i think that spoiler alert is a little overgeneralized. first, there’s plenty of advances in those categories in the past 5 or so years (lambda, fargate, qldb, a bunch more) that move the needle significantly on the versions of things that existed 10-15 years ago. we didn’t collectively get everything right by 2012, and i heartily endorse customers using things that take away operational complexity but are less “complete” compared to the lower level counterparts. second, you missed mentioning that circular dependencies is a very real reason for why cloud vendor service teams can’t (not won’t) use services that would otherwise benefit them. this is a problem that is much less apparent to customers of clouds because, to them, the suite of services is provided as a single flat layer of options. i do agree that you want to make sure any service you use is “complete” for you, but that completeness can exist on a spectrum and sometimes getting onboard early and driving their roadmap can benefit you greatly. i also agree that you want to be conservative with how many services you do use, because each one without exception will become a learning experience.

tyingq 6y ago

"It sounds good, but what does it actually mean in practice?" I think what I was saying is pretty straightforward... "If you're going to the trouble of being agnostic" Meaning that if you're trying to build some sort of facade that makes AWS and GCP look the same, you might as well just make a facade that points at something cheaper than AWS/GCP. AWS/GCP markup for things like internet egress, storage, and compute are high, partially because of all that plumbing. Any facade puts you in a lowest common denominator situation where you're paying for lots of stuff then not using it. Or, in short, "cloud agnostic" running on cloud is a weird idea that throws out lots of the value add. Perhaps there are some exceptions for very simple architectures, as you hint.

rubiquity 6y ago
> I think what I was saying is pretty straightforward... I was asking you to give specific examples. > Perhaps there are some exceptions for very simple architectures, as you hint. Simplicity should be the goal and the starting point.
- Terretta 6y ago
  S3 and DynamoDB would be the two I’d mention first (since know it or not, folks are relying on them anyway), then things like Fargate, QLDB, and PrivateLink. Agree on the simplicity point, though the key is not just simplicity for coding, or for communicating about the architecture, but emphasizing simplicity of operation and honesty at the skills, abilities, and criticality of operating and resolving things under stress. Several years as AWS CAB member show this topic is hotly debated. I think there’s this “third way”, to purposefully exploit the different DNA of the top CSPs. I choose that word “exploit” to appeal to the board room, to feel they get more than they have to pay for (which I think is true, thanks to CSPs’ focused spend). A more friendly way of putting it from CSP point of view is “leverage what we’re best at”. Rare case of genuine win-win.

Tehnix 6y ago

> From where I'm sitting, the best parts of the cloud were created 10-15 years ago I just moved from a startup that was running things on services that were either created or only really matured within the past three years, to a different startup running on tech from 10-15 years ago. The differences in Ops overhead and scalability is huuuuuuuge to say the least. Modern infrastructure on AWS for me would be: - Lambda - DynamoDB - S3 - Fargate - EKS to a certain extent - And extremely excited about Serverless Aurora V2 Older infrastructure with massive ops overhead: - EC2 - ElasticBeanstalk - RDS MySQL/PostgreSQL Every year at AWS re:Invent I see the needle moving into more serverless stuff, and for a very very good reason. To maybe take up some of your points: > On-demand compute EC2 and RDS are the absolute bare minimum you can do for on-demand compute and was the initial introduction to the elasticity of the cloud. It's slow and cumbersome to scale up and down, and also very costly to do so (RDS is basically a x2 of you instance size every time). That's skipping automatic scale - for RDS? Forget about it. > The newer features tend to lack the things you really need in a production ready service: monitoring, debugging, configuration, etc State of anything running on EC2: You are 100% responsible for getting your metrics and logs out of the instances, you get close to worthless OS metrics by default, that might tell you info about some scaling events, but no insights into you actual applciation. State of serverless: Built-in integrations with CloudWatch for monitoring and XRay for profiling. Out of the box you have error reporting on Lambdas along with DLQ and much more. > without dealing with the joys of subnetting, DHCP, and configuring Linux interfaces I honestly hold the opinion that if you deal with things at this level of the infrastructure stack, then the "modern cloud" is not relevant to you (AWS, Azure, and GCloud), but you would fit better or something like Hetzner or with dedicated servers.

bsder 6y ago
I always thought that "cloud" was overhyped and never understood why you would want to use stuff like EC2 over a dedicated server somewhere. Honestly, the idea that the new services have a "higher level of abstraction" and that old services are an insufficient extra level of abstraction is something I could never articulate properly. Thanks.

thewarrior 6y ago

Aren’t message queues a basic primitive in a highly available system ?