If you're going to the trouble of being agnostic, then you might as well deploy to a way cheaper bare metal datacenter and enjoy market rate storage, compute and egress.
Running cloud agnostic on AWS, GCP, etc, is the worst of both worlds.
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.)
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.
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.
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.
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.
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.
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.
There's a sweet spot where companies can use the lowest foundational building blocks, build their own stacks on top, and save resources (comparatively to running your own datacenter).
Things like EC2, EKS, S3, and RDS Aurora can be considered foundational but you don't really have to use Athena, CloudWatch, or RedShift (they are super expensive anyway).
Interesting. I wonder a which scale this becomes true. It's been a long time, so I'm not current on rates, but I've been involved with a couple migrations from datacenter to AWS and AWS was substantially cheaper for the same level of infra in both cases. These were smaller use cases, though.
"Oh they would NEVER do that"
And these gee-whiz heavy-binding services would NEVER steal your data.
The strange thing at work is people bend over backwards to use AWS stuff:
"I made this virtual network card that I can detach and attach to another VM when we want to keep the same address for a box!"
How about we use DNS.
AWS services are great for things like their Postgres as a service and other things that fundamentally have standards based access.
But the others like big data streams will be a bit more convenient in the beginning and then you're beholden to their supported features and the fact you are handing them visibility to your data.
> "Oh they would NEVER do that"
Interestingly, what you insinuate is exactly the opposite of actual reality when you look at what has happened over the years: things have gotten CHEAPER.
Off the top of my head:
- Lambdas are now billed per 1ms instead of per 100ms which will be a significant cost reduction for everyone using Lambda
- EKS started at $200 / month for the cluster and is now at ~$72 / month
- Each bump in EC2 instance generation is always cheaper for the same or more performance
- DynamoDB added on-demand capacity which is at face value more expensive, but allows you to scale to 0 and will usually result in an overall cost reduction
- This December they announced GP3 which can scale storage and IOPS independently allowing you to much cheaper scale up your needs for more IOPS without paying for TBs of unused storage
and probably many many more.
Right now, times are good. Money is good. Top spot. Discounts if you can negotiate it.
But eventually this will commodify more tightly (k8s is just a warning shot).
When you buy "binding" AWS services, it is the "nobody got fired for picking IBM" with a BIT more market pressure. AWS non-commodity services are the new IBM mainframe.
To borrow an AWS metaphor on “One way doors versus two way doors” decisions, do pre-think, but don’t pre-code. Just think as you design the house about whether you might someday want to go through that door another way. It’s inexpensive now to make design decisions that make that easier later.
At an enterprise, fully understand the BCP or business continuity plan. You will likely be stunned how long functions are considered OK to be offline for regulator-compliant BCP planning purposes, relative to the SLAs that I.T. gets yelled at about.
Your job before committing to vendor lock in is to write down a plausible plan to get out of the lock in that fits (when effort is doubled twice) inside the BCP plan window, and maintain that plan as part of the platform documentation for the capability in question.
When you study the economics of re-investment by Azure, Google, and AWS, it’s impossible for an enterprise to achieve the same capability-evolution curve without floating on that rising tide. The hard part is to figure out how to not get capsized by change waves or get swamped if the CSP pulls the plug in your boat. These are part engineering, part business/procurement/legal problems, but much less costly than holding yourself to either a lowest common denominator or fully abstracted principle.
There's definitely value in keeping options open by sticking to standard processes on Linux VMs so there is a painless migration path if and when the CFO freaks out.
- death by abstraction of cloud differences
- teams incompletely reimplementing features on each service
- giving up and going to bare metal
?
I agree with you: if you know your deployment is, and always shall be, on e.g. AWS, you essentially lose out on great integration if you try to be cloud agnostic.
However, as in the introduction:
"Whether motivated by the need for a multi-cloud strategy, expenditure minimization, legislative or regulatory demands, or simply to get closer to end users, many organizations find themselves migrating from one cloud to another."
I work with many customers that migrate away from the big US providers because GDPR and the "Schrems II" ruling makes it legally questionable to continue to use these services for certain data processing.
Or ones that have been bitten hard by cloud outages, causing them to fail to deliver service to their customers. Getting a tiny rebate on your cloud bill that month does not begin to cover the lost reputation due to downtime.