AWS hearts multi-cloud? It's gonna happen(cloudirregular.substack.com)
cloudirregular.substack.com
AWS hearts multi-cloud? It's gonna happen
https://cloudirregular.substack.com/p/aws-hearts-multi-cloud-its-gonna
39 comments
> - AWS UI toolkit has aged by this point and each day it feels more dated
They're rewriting the console: https://abduzeedo.com/amazon-web-services-design-system
At least a few of their services have already been updated.
They're rewriting the console: https://abduzeedo.com/amazon-web-services-design-system
At least a few of their services have already been updated.
I agree with you on Terraform and Pulumi (I'm especially excited about the latter, due to extra benefits over Terraform). However, I think that you are missing the main point / theme of the post - it is not specifically about AWS' approach to multi-cloud, but rather about general dynamics of the multi-cloud trend.
Check out Terraform CDK for a thing that is native to TF, allows real code, and is progressing real fast
Thank you, will keep it in mind. However, Terraform CDK is far from being production-ready at the present time. Moreover, I would venture to guess that it will trail Pulumi in terms of both features and maturity (due to Pulumi team's first mover advantage as well as singular focus on their product, unlike HashiCorp's broad portfolio of products).
I’m a bit confused here. Isn’t Pulumis big claim that it’s compatible with Terraform providers?? Why would Terraform trail that?
Yes, Pulumi is compatible with Terraform providers. However, it is a declarative backend compatibility. In terms of imperative frontend, as I said, Pulumi team has both first mover advantage as well as singular focus on their product, unlike HashiCorp with its broad portfolio of products, where Terraform CDK is just one of them (hence, lack of the laser focus).
Do you have practical experience with Pulumi in large deploymenets? Is it bug free and dependable?
I would like to try it out as a Terraform replacement, but but the popularity and corresponding module availability and maturity is hard to match.
I would like to try it out as a Terraform replacement, but but the popularity and corresponding module availability and maturity is hard to match.
I ran into bugs with Pulumi. But I’ve really been enjoying CDK for Terraform - check it out:
https://github.com/hashicorp/terraform-cdk
For those that don’t follow this space very closely - this allows yiu to model infrastructure in your favorite programming language, such as Python.
https://github.com/hashicorp/terraform-cdk
For those that don’t follow this space very closely - this allows yiu to model infrastructure in your favorite programming language, such as Python.
My team has a lot of practical experience with Pulumi, after using custom bash scripts, manually-managing AWS config, some Terraform and CloudFormation in the past. We use it for dozens of services on Kubernetes and AWS.
While we did have to write some of our own tooling to reduce the boilerplate over different services, Pulumi has been by far the best tool we've found to do the deployments. Being able to automatically provision a resource in AWS, then use results from that in a Kubernetes service (env var) in the same deployment, is not something I ever expected to be able to automate.
We haven't had any issues with module availability (I think it uses/adapts Terraform modules to a large extent). The config as code feels way more approachable and reusable than any other tool I've seen.
I've never had any production issues because of Pulumi. It also allows you to preview changes before applying them, giving a nice confidence boost in the changes.
While we did have to write some of our own tooling to reduce the boilerplate over different services, Pulumi has been by far the best tool we've found to do the deployments. Being able to automatically provision a resource in AWS, then use results from that in a Kubernetes service (env var) in the same deployment, is not something I ever expected to be able to automate.
We haven't had any issues with module availability (I think it uses/adapts Terraform modules to a large extent). The config as code feels way more approachable and reusable than any other tool I've seen.
I've never had any production issues because of Pulumi. It also allows you to preview changes before applying them, giving a nice confidence boost in the changes.
> Being able to automatically provision a resource in AWS, then use results from that in a Kubernetes service (env var) in the same deployment, is not something I ever expected to be able to automate.
Terraform does this very well too, using either the Kubernetes provider or the Helm provider.
Terraform does this very well too, using either the Kubernetes provider or the Helm provider.
> Being able to automatically provision a resource in AWS, then use results from that in a Kubernetes service (env var) in the same deployment, is not something I ever expected to be able to automate.
FWIW we do that with a small amount of glue code in our deployment tool that takes terraform outputs and passes then as values into helm.
FWIW we do that with a small amount of glue code in our deployment tool that takes terraform outputs and passes then as values into helm.
Sounds about right. We have 95% of our infra on AWS but then early this year one team needed something specific from GCP and started using that. A few months ago, a client insisted on having their services delivered from Azure as they have a lot of other related services already tied into Azure. 95% on AWS and the other two add up to just 5% - but, hey, multi-cloud!
This sort of feels like Microsoft embracing Linux. First they fought it, but the market forces were too strong. Eventually MS figured out how to coexist with Linux, and leverage it for their business.
Ultimately, lock-in in the cloud is a real issue for companies, and the open source community will figure out how to address this issue. AWS and other platforms will fight this a bit, but ultimately they'll adopt whatever approach emerges.
This isn't too say all cloud-services will be commoditized, but the interop between similar services will be.
Ultimately, lock-in in the cloud is a real issue for companies, and the open source community will figure out how to address this issue. AWS and other platforms will fight this a bit, but ultimately they'll adopt whatever approach emerges.
This isn't too say all cloud-services will be commoditized, but the interop between similar services will be.
This article is not far off in its prediction that AWS would support multi-cloud natively eventually if that's what the market demands (See also: AWS Marketplace). We are very early in our journey and are multi-cloud already and because we're bootstrapped, cost ultimately decides what we use. And no, I don't mean multi-cloud in a way Netflix does it, but in a way where different parts of our system are hosted wholly by different cloud providers. So, in a sense, everything supports multi-cloud already anyways?
> QLDB is a recent entry to the canon. It’s easy to spot these "AWS-native" services because they’re often dogfooded by Amazon retail.
Well, in some cases, it is dog-fooded by AWS themselves. In QLDB's case, the underlying tech was built for EC2 [0] whilst Kinesis Data Streams was built by the Billing team at AWS [1].
[0] https://twitter.com/colmmacc/status/1067832198059970561
[1] https://gigaom.com/2014/03/20/why-amazon-built-its-data-stre...
> QLDB is a recent entry to the canon. It’s easy to spot these "AWS-native" services because they’re often dogfooded by Amazon retail.
Well, in some cases, it is dog-fooded by AWS themselves. In QLDB's case, the underlying tech was built for EC2 [0] whilst Kinesis Data Streams was built by the Billing team at AWS [1].
[0] https://twitter.com/colmmacc/status/1067832198059970561
[1] https://gigaom.com/2014/03/20/why-amazon-built-its-data-stre...
How do you keep the costs down with egress pricing? If the parts of your applications are distributed through cloud providers you all the time are exporting data to egress. Thats not a cheap concept or did you build your software with this in mind?
> How do you keep the costs down with egress pricing?
The AWS components we use are mostly ingress heavy. Egress heavy components are on Cloudflare, Scaleway, and Digital Ocean.
> ...did you build your software with this in mind?
Yep, we designed the system keeping egress costs in-mind, and that meant some of things were a bit more time-consuming (build vs buy) than they normally would have been.
That said, we aren't what you'd call an uber sophisticated upstart using cutting edge tech. Right now, whatever systems we have are all mostly boringly simple and probably won't scale.
The AWS components we use are mostly ingress heavy. Egress heavy components are on Cloudflare, Scaleway, and Digital Ocean.
> ...did you build your software with this in mind?
Yep, we designed the system keeping egress costs in-mind, and that meant some of things were a bit more time-consuming (build vs buy) than they normally would have been.
That said, we aren't what you'd call an uber sophisticated upstart using cutting edge tech. Right now, whatever systems we have are all mostly boringly simple and probably won't scale.
> That said, we aren't what you'd call an uber sophisticated upstart using cutting edge tech. Right now, whatever systems we have are all mostly boringly simple and probably won't scale.
You acknowledge here that the systems you have may not scale. I assume you're still trying to find market fit, and may end up heavily augmenting or redesigning these systems when you do. With that said, why did you prioritize spending your limited resources solving for multi-cloud?
I'm curious if the cost savings of optimizing cross clouds was worthwhile vs. the engineering effort / constraints you introduced into your systems at your scale.
You acknowledge here that the systems you have may not scale. I assume you're still trying to find market fit, and may end up heavily augmenting or redesigning these systems when you do. With that said, why did you prioritize spending your limited resources solving for multi-cloud?
I'm curious if the cost savings of optimizing cross clouds was worthwhile vs. the engineering effort / constraints you introduced into your systems at your scale.
> With that said, why did you prioritize spending your limited resources solving for multi-cloud?
We keep asking ourselves the same too. We initially wandered down the "mutli-cloud" path because it made a lot of sense in terms of cost (like somewhere in the region of 10x lower costs)... but as we chipped away at code, it became quite obvious that the inherent complexities could have been avoided especially since we're so early and barely have a user-base.
> I'm curious if the cost savings of optimizing cross clouds was worthwhile vs. the engineering effort / constraints you introduced into your systems at your scale.
The uber low-cost setup allowed us to offer our services for free to gauge overall interest (given we're a consumer product). My assumption is that free customers are free publicity (in that they help spread the word) and that around 1% would convert to paying customers eventually.
We also biased towards "serverless" offerings to avoid DevOps and SRE, and that has worked quite well: In the three months our alpha has been been live taking ~30M requests a month (ignoring the occasional DDoS), we haven't had a single outage or even bothered to look at the error logs (there aren't any errors).
So to answer your question, yes I believe it was worthwhile since the cost difference is 10x and we were able to offer a free-tier because of that (we're not an enterprise business). Obviously, it sucks that engineering time had to be sacrificed for it, but hey, no pain no gain.
We keep asking ourselves the same too. We initially wandered down the "mutli-cloud" path because it made a lot of sense in terms of cost (like somewhere in the region of 10x lower costs)... but as we chipped away at code, it became quite obvious that the inherent complexities could have been avoided especially since we're so early and barely have a user-base.
> I'm curious if the cost savings of optimizing cross clouds was worthwhile vs. the engineering effort / constraints you introduced into your systems at your scale.
The uber low-cost setup allowed us to offer our services for free to gauge overall interest (given we're a consumer product). My assumption is that free customers are free publicity (in that they help spread the word) and that around 1% would convert to paying customers eventually.
We also biased towards "serverless" offerings to avoid DevOps and SRE, and that has worked quite well: In the three months our alpha has been been live taking ~30M requests a month (ignoring the occasional DDoS), we haven't had a single outage or even bothered to look at the error logs (there aren't any errors).
So to answer your question, yes I believe it was worthwhile since the cost difference is 10x and we were able to offer a free-tier because of that (we're not an enterprise business). Obviously, it sucks that engineering time had to be sacrificed for it, but hey, no pain no gain.
Run the database in multiple regions and pay the egress for replication.
egress cost is really not as bad as people expect. if you're willing to pay for double the instances and storage, as required to run in multiple regions/clouds, the bandwidth costs are really not that outstanding in the grand scheme of things.
The usual problem is poor architecture and non-distributed systems. You're not going multi region when everything relies on a single MySQL instance somewhere.
egress cost is really not as bad as people expect. if you're willing to pay for double the instances and storage, as required to run in multiple regions/clouds, the bandwidth costs are really not that outstanding in the grand scheme of things.
The usual problem is poor architecture and non-distributed systems. You're not going multi region when everything relies on a single MySQL instance somewhere.
If you have enough volume you can pay for partner interconnect that lower price per GB to 2c so that’s not great but not terrible either.
Edit: You probably would want it for performance first though
Edit: You probably would want it for performance first though
IIRC, CloudEndure offered migration between different clouds before Amazon bought them - though now they seem to support migration into Amazon only (not surprising).
This never supported a "multi cloud" solution in the sense that things are running on two clouds simultaneously, but it did let you fail-over to a different cloud. Now it only lets you fail-over to Amazon if I read the docs correctly.
This never supported a "multi cloud" solution in the sense that things are running on two clouds simultaneously, but it did let you fail-over to a different cloud. Now it only lets you fail-over to Amazon if I read the docs correctly.
...And 8 hours after I wrote this piece, AWS announces their public container registry. [0]
Is that the "multi-cloud management tool" The Information heard about? Not exactly how I would have characterized it...
[0] https://aws.amazon.com/blogs/containers/advice-for-customers...
Is that the "multi-cloud management tool" The Information heard about? Not exactly how I would have characterized it...
[0] https://aws.amazon.com/blogs/containers/advice-for-customers...
Almost certainly not. They do many things in parallel
AWS has been very chummy with HashiCorp and Terraform in the last few years, going so far as to announce a Landing Zone collaboration with them
https://www.hashicorp.com/resources/aws-terraform-landing-zo...
and of course the https://github.com/hashicorp/terraform-cdk
I am not sure what I would think of an offering from one cloud provider to support another cloud provider, just seems shady as hell. I could see AWS spinning out an MSP that would handle multi-cloud stuff, because AWS MSP would be "cloud experts", but that might be a stretch too, TBH.
I really see them taking Terraform, and the CDK, and pushing that as their multi-cloud if they were to really lean into that, but there is little to no reward (as I see it) for them doing such a thing. It would just be another tool that will gather dust in a few months while they venture off to exploit another Open Source project in their MSP Cloud providings
https://www.hashicorp.com/resources/aws-terraform-landing-zo...
and of course the https://github.com/hashicorp/terraform-cdk
I am not sure what I would think of an offering from one cloud provider to support another cloud provider, just seems shady as hell. I could see AWS spinning out an MSP that would handle multi-cloud stuff, because AWS MSP would be "cloud experts", but that might be a stretch too, TBH.
I really see them taking Terraform, and the CDK, and pushing that as their multi-cloud if they were to really lean into that, but there is little to no reward (as I see it) for them doing such a thing. It would just be another tool that will gather dust in a few months while they venture off to exploit another Open Source project in their MSP Cloud providings
Response to Anthos I suppose.
Speaking of which, has anyone ever seen a company use Anthos? (Software so seems a lower lift)
Anyone seen a company use AWS Outposts? (Hardware so seems hard to imagine anyone actually using but I'd love to be proved wrong).
I'm thinking AWS may realize the hardware model of Outposts is prohibitive so may target a software solution.
Speaking of which, has anyone ever seen a company use Anthos? (Software so seems a lower lift)
Anyone seen a company use AWS Outposts? (Hardware so seems hard to imagine anyone actually using but I'd love to be proved wrong).
I'm thinking AWS may realize the hardware model of Outposts is prohibitive so may target a software solution.
lots of public sector customer is using outpost for data sovereignty
Until the various clouds stop charging outrageous amounts for bandwidth egress multi-cloud will remain a niche.
I believe theres still a whole bunch of useful "multicloud" products out there. For instance if you have services in different clouds that talk to each other, having a performance monitoring software that gets data from both and stitches it together is useful.
This feels like trading one set of single-vendor lock-in concerns for another.
What do yall think about VMware on AWS? Looks like a neat solution to “polycloud”.
On the UI front:
- AWS UI toolkit has aged by this point and each day it feels more dated
- CloudFormation, as their main cloud management UI is particularly bad (e.g. limited info on what caused a problem, not displaying ARNs of resources belonging to a stack systematically etc.)
On the provisioning front:
- Terraform and Pulumi are so much better than anything AWS offers, and that says something because even these tools are not great.