With all due respect this is a trivial and misleading point of view. Of course if you have the staff you could do all the things they do in the cloud, on-premises. If you had the staff. And the skills. And the money. And you wanted to spend your finite devops resources deploying and monitoring a data center.
Yes it’s possible to buy your own building, and your own DS3/OC3. And HVAC. And electrical. And backup generators for the HVAC. And the personnel to design and specify the racks and the hardware in them (all of the different configs you need). And to assemble and connect the equipment. And to maintain it when something breaks. And the network engineers to design your network and deploy and maintain it.
And do it again in a different place for geographic redundancy.
And, if you have any money and personnel left, then you can think about a virtualization infrastructure (because of course who would be stupid enough to buy VMware when you could build your own open source equivalent around HVM or whatever.
And now you’ve got like a tiny fraction of what the cloud can offer. And I guarantee you that the TCO is way higher than you expected and that your uptime is a 9 or two short of what a cloud provider would give you.
I’d you are running a single cloud-scale workload (Google Search or Dropbox or Outlook.com) then you probably can do better financially with your own optimized data center. But you almost certainly can’t beat cloud for heterogeneous workloads.
And the biggest benefit of all is savings in opportunity cost as your tech people can focus on your own unique business problems and leave the undifferentiated heavy lifting to others.
> Yes it’s possible to buy your own building, and your own DS3/OC3. And HVAC. And electrical.
> And do it again in a different place for geographic redundancy.
With all due respect this is a trivial and misleading point of view.
Most people who do cloud don't need or employ redundancy across machines; much less so in different regions. But they do have devops teams or programmers who are required to learn bespoke cloud dashboards and AWS products. Even though most of the time they could just ssh into a box and run nodejs in screen and be 99% of the way there. Cloud providers convinced everyone that it's really hard to run a computer program. And companies set money on fire because spending signals growth, especially to investors.
Literally everything you said is the opposite of how I've seen people use "cloud" in the real world. I don't know what universe you're living in where things are as wonderful as you proclaim but I wish I was in it because mine is a nightmare.
> Literally everything you said is the opposite of how I've seen people use "cloud" in the real world.
I’ve been working in SaaS since 2008 and in cloud providers since 2012. And the use case I see over and over is people who don’t think they need or want geographical redundancy, until they do, and then they want it yesterday. Typically they are running fine for months or years and then there is an outage - maybe an AZ or a network partition - and then all of a sudden they’re scrambling for failover. Cloud often (usually?) has higher availability than the infra they migrated off of, and they grow addicted to it while not wanting to pay the dev cost for true high availability.
> Cloud often (usually?) has higher availability than the infra they migrated off of
I've seen more region wide outages than just an AZ e.g. where AWS us-west-2 goes out and so it doesn't make a difference.
> and then they want it yesterday
Some great SaaS you've experienced. I've been at 1s that say they want it yesterday but then realize it's too much work (already in the cloud) and just let it go until the next outage and complain again but yet again nothing gets done.
If you actually need so many 9's in the availability that it makes sense to invest in well tested robust failovers and resulting distributed-system application complexity (which most people don't test, they end up just paying for redundancy but getting maybe even reduced availability), you are in a very small minority and you will be highly skeptical of outsourcing this to a cloud vendor since their HA also goes tits up regularly. Witness how often cloud vendors have unexpected outages and read the post mortems.
Build your application to run on a few boxes with a slow (say 5 second) failover. They can have a single power supply running somewhere in the back of an office. If the power goes, oh well - one of the other nodes will carry on.
Of course you’re right a VPC or a CoLo would be better. However that’s not what most people think of “cloud”
I don’t think you deserve a downvote but I can give you my take having worked at a lot of places that did their own infra as well as cloud.
You don’t need to physically rack servers, lots of systems integration vendors and remote hands will gladly put servers together for you. Most colos will gladly help you figure out connectivity. And there are lots of vendors, like Cisco, who will deliver a rack to your datacenter with virtualization software installed and everything, plug and play..
My point is there isn’t an either/or choice of using the cloud or building the universe from scratch, there are so many available options in-between. And while those options aren’t available conveniently behind an API and might require a few old school phone calls, you can save millions of dollars, get access to better performing hardware, have better control over data sovereignty, and 90%less lock-in if you choose to go down that road. It’s not for everyone but a /lot/ of workloads that people are running in the cloud can be done better elsewhere.
The person you're replying to is definitely overly flippant, but you've taken a sort of Gish gallop approach where you think if you list enough individual things that have to be done, that'll be overwhelming evidence that it's impossibly difficult. But the things you've listed aren't as hard as you want them to be on reasonable small business scales.
We are a company with 4 IT employees including myself, and two of us alone (both full-time programmers) handled our hybrid cloud migration. We rented a rack in a colocation facility. I learned how to design racks in a couple days and did the rack design myself. We bought servers from Dell and network equipment from Meraki. The colo facility found us an inexpensive contractor who racked and stacked everything to my design, and remote hands does any ongoing hardware maintenance. The other guy had an old, outdated CCNA and he designed the network. We got a fiber connection to AWS up and running for a hybrid cloud approach. All of this was very doable for a part-time two-man team with other job responsibilities and we're saving a ton of money for database and workstation hosting--big, expensive, totally static workloads. Perfect for on-prem. The ongoing savings vs. pure AWS exceeds my own salary.
It was clear from the outset that we could accomplish this. I wouldn't have signed us up for a boondoggle. Certainly, there are more demanding configurations where the complexity would be too high, but people act like on-prem is literally impossible without a team of dedicated staff in every case. It's not. It can be doable.
A recurring anti-pattern I have seen over and over is the app that is built and runs on a developer desktop, then becomes business critical and needs to scale and evolve, and eventually fails catastrophically. Maybe the SQL database design or storage system isn’t capable of handling the new I/O requirements. Maybe the creator quits and nobody else knows how it works. Whatever.
On-prem is like that. Yes, you have all the skills to originally stand it up. But you don’t know what you don’t know, and you make a bunch of resource trade-offs, usually by not implementing stuff that you’ll never need (until you do).
That was the point I was trying to make.
As I said though, the unique value of cloud is letting you focus on a business specific problem instead of reinventing wheels that have already been invented many times over.
As other a have pointed out, other benefits are scale-on-demand, pay only for what you use, and agility - if you have a great idea you don’t have to do a PO and wait months for a server.
How many more years do you suppose we need to run on-prem before you can accept that we understand our needs? It's been 10+. We've been running on-prem for a lot longer than we've been running in AWS. Again, there's this sort of paternalistic suggestion that people can't possibly understand how to run on-prem. But we've always been on-prem. We've always maintained a SQL Server cluster. AWS is the new thing.
AWS vs. on-prem is always a tradeoff. You have to look at the costs and benefits for your particular situation to decide which is best. We decided to go with both, because AWS has benefits for our dynamic workloads and on-prem has savings for our static workloads.
The cloud has the same problem but in a different color. One employee created and managed everything in AWS and then quits. You have the same problem that nobody really knows how to continue from that point. Why was it built that way? Why are the IAM rules like that? etc.
Yeah complexity doesn't go away, you just move it around. The trick is not standing up stuff, that's pretty straight forward with cloud or metal. The real talent lies in understanding that you need to pump the entropy somewhere so you should be aware of the trade-offs and make things that are well organized, explicit and have contingency plans for the future.
Exactly. It actually makes this problem worse bc cloud apis lower the skill level requirement to the point that people who don’t know what they’re doing can create a lot of unmanageable headache in very short time span
> On-prem is like that. Yes, you have all the skills to originally stand it up. But you don’t know what you don’t know, and you make a bunch of resource trade-offs, usually by not implementing stuff that you’ll never need (until you do).
But what you described sounds like a packaging / software distribution issue.
Like, someone writes a one off Python script or program to do a thing and a year later it doesn't work because the host machine is using a newer version of Python and the dependencies need to be reinstalled to the new site-packages and they didn't document if they used the package manager or a virtualenv and a pip requirements file or setup.py or whatever.
The "it works on my machine" thing isn't really a "cloud" thing? It doesn't really solve the issue of having a weird bespoke service that nobody understands. Even if it's so abstracted from a normal computer that it has some esoteric requirement like an OCI image to run software, if the Dockerfile/Containerfile or whatever that generates the image doesn't exist/work/make sense then you have the same problem.
> As I said though, the unique value of cloud is letting you focus on a business specific problem instead of reinventing wheels that have already been invented many times over.
Reinventing the wheel like with docker ansible terraform kubernetes nomad aws?
Recently I was asked to help a company receive out of office replies to their web service that sent mail from Amazon SES. The client was sending mail from app.foo.org (with MX SPF for amazon) and wanted to receive them to foo.org (MX and SPF for outlook). Setting Reply-To or some other headers to foo.org worked in testing but not in practice. I maneuvered the amazon product menagerie and set up SES to get notifications on out of office replies and that also worked in testing but not in fact. Even then it would not store a list or provide details in the dashboard about replies without further using lambda or SQS or something. Every deficiency in an amazon product is "solved" by another amazon product. You're swallowing a horse to swallow a fly. In the end I just added AWS to the foo.org SPF records along with outlook's and set the From header accordingly; way simpler, didn't need to any more AWS products, and knowledge of DNS is more portable than knowledge of AWS. AWS is in the business of inventing wheels and trying to get you stay in their wheel ecosystem.
Not to contradict everything you're saying like you're wrong or something. I wonder what the circus is like for those of you who run it. Everything you say reads like high-level manager/sales engineer marketing talk from someone who spends all day in meetings. Not to say I'm an authority and that your voice is illegitimate; I'm just a resentful out of touch NEET waiting for the world to change to the point that I have nothing left to offer it.
I work in one of those pesky HIPPO companies. For us, all of our AWS infrastructure up to including nifty shit like Cognito is HITRUST certified. For us, we get to offload an ass of compliance headache which is worth our 2-4x multiple as the server overhead is far less than a team of compliance and security wonks.
> The cloud is renting someone else's computer at a way higher price than it would cost you to use your own.
This is a simplistic view that doesn't discuss any of the trade-offs inherent in the choice between running your own hardware and using a cloud service.
Yes, it's a higher price, but it allows you to stop paying for it when you stop needing it. You can scale up rapidly. You don't have to deal with buying, maintaining, or replacing hardware.
That's basically just the definition of the word "renting". If the owner is doing their job right, it's always more expensive than owning, but it still makes financial sense to rent in many scenarios.
until you realize you have to build a datacenter yourself. Or order purestorage appliances for 3 datacenters you have your hardware in. And then realize dc 1 does not physically have enough space to add more storage servers. But you need that third site. There is no convenient 4th “spare” site. Let alone 100 across the world.
Or that your business has to replace a router on one of the dcs and then you have to do all the work to ensure nothing goes down yourself. You cant blame anyone if it goes bad.
Then you realize how much work that is. The cloud is really convenient.
Source:
Always worked “in the cloud”. Current client is on premise(s) for solid reasons. A very unusual case though. Fun. Inconvenient. Makes you respect the big clouds even more.
> until you realize you have to build a datacenter yourself
Have you never heard of a colo? Rent 1-2 racks in one of those. And you probably won't need more than 1-2 racks because that's what Stack Overflow runs on.
And guess how long it takes me to set up an entire data center with Terraform on any of the three major cloud providers? (disclaimer: I work for one of them)?
It’s much less maintenance than my days of maintaining servers myself.
And not to mention half the reason I went to cloud was not that I didn’t want to deal with administering servers, I didn’t want to deal with server administrators.
When I was at the 60 person company where I got my start in “cloud”, I could experiment with different types of databases, scaling, and other technologies just by throwing something together and deleting the entire stack.
I worked for a company that aggregated publicly available health care provider data (ie no PII) for major health care providers. They used our APIs for their own websites and mobile apps.
When we got a new customer (ie large health care provider), our systems automatically scaled.
When a little worldwide pandemic happened in 2020 and our traffic spiked by 100%+, guess how long it took us to provision new servers.
Hint: we didn’t, everything just scaled by itself.
I compare that to the old days when it took us weeks to provision an MySQL server.
Managing infrastructure is doesn’t provide a competitive advantage unless you’re something like Backblaze, DropBox or another company where your entire reason for existing is your infrastructure expertise.
> And guess how long it takes me to set up an entire data center with Terraform on any of the three major cloud providers? (disclaimer: I work for one of them)?
And the discussion is how much extra do you pay for it.
> Hint: we didn’t, everything just scaled by itself.
Again it's not free so what's the surprise? Are you surprised that you get water out of your tap? Hint: it just flows!
> I compare that to the old days when it took us weeks to provision an MySQL server.
Sounds like you've burnt in the past is all. So your on-prem is slow does not equal all on-prem is bad?
> Managing infrastructure is doesn’t provide a competitive advantage
How do you know it doesn't? You've only looked at it from your use case and based on it making you happy and saving you time. Nothing to do with the business needs at all.
> How do you know it doesn't? You've only looked at it from your use case
So you didn’t see the rest of the paragraph that you snipped?
“unless you’re something like Backblaze, DropBox or another company where your entire reason for existing is your infrastructure expertise.”
> So your on-prem is slow does not equal all on-prem is bad?
How fast can you spin up a dozen VMs? A message bus? A scalable database with read replicas? An entire redundant data center in another region? A few terabytes of storage? A redis cluster? An ElasticSearch cluster? A CDN? A few load balancers?
The procurement process to get an extra server provision in a colo will by definition be slower than my deploying a CloudFormation stack.
> How fast can you spin up a dozen VMs? A message bus? A scalable database with read replicas? An entire redundant data center in another region? A few terabytes of storage? A redis cluster? An ElasticSearch cluster? A CDN? A few load balancers? The procurement process to get an extra server provision in a colo will by definition be slower than my deploying a CloudFormation stack.
Your examples here are just examples of situations where you basically need a cloud solution by definition. If these are your requirements, then yes obviously you should use cloud for it. That said, your points are a bit confusing. It's not an either-or. For situations like you're describing, you use cloud. For situations where you don't need to use cloud, you can consider something else like on-prem or colo or ...
You seem to have a (literally) extremist position where it's all cloud or nothing. It's not.
Well then I'm a little confused. You wrote this earlier which contradicted my post:
> Managing infrastructure is doesn’t provide a competitive advantage unless you’re something like Backblaze, DropBox or another company where your entire reason for existing is your infrastructure expertise.
You don't need to be a company "where your entire reason for existing is your infrastructure expertise" in order for managing your own infrastructure to be a competitive advantage. Managing (some of) your own infrastructure can be a competitive advantage even managing infrastructure is not your core competency or even your goal. It is a competitive advantage of the TOC is lower. It sometimes is.
But if you're now saying you agree with my statement, then I guess well we're in agreement.
But, really how often do you need to do that and what % of users really need to?
Also, once on the cloud some business management take so long to "approve" new expenses that in reality it may not really be feasible to do things fast enough for it to be a benefit.
I've quite often seen the need for 5-10 meetings or 2-3 written documents to get approval for 10 new VMs for developers or new servers for backups.
> But, really how often do you need to do that and what % of users really need to?
When testing something or you want to spin up your own isolated environment for yourself or for your team? Very often.
> Also, once on the cloud some business management take so long to "approve" new expenses that in reality it may not really be feasible to do things fast enough for it to be a benefit.
And that’s get back to my other point that when you do a “lift and shift”. If you don’t change your processes both IT and technical, you won’t see any benefit from the cloud and you will end up spending more.
There are so many ways that you can both give developers freedom and still have the necessary guardrails. I’m speaking about AWS because that’s the one I know best (and where I work). But I’m sure there are equivalent services on other providers.
For instance you can have a vending machine type of setup where you allow department heads to set up non prod accounts with organization controlled service control policies. You can use a Service Catalog approach where you surface Terraform or CloudFormation defined products where the users can only provision infrastructure defined by their administrators. But they can do it themselves.
Depending on which level of the organization I’m working with, I try to convince the IT department to give individual departments their own organizational unit to monitor and to embed someone from IT into their team - ie a “DevOps” philosophy.
> And not to mention half the reason I went to cloud was not that I didn’t want to deal with administering servers, I didn’t want to deal with server administrators.
I bet it's true for many. I approximate it from what I see in backend/frontend teams - they don't even deal with eachother, not even system administrators.
Luckily [in the current project] devs don't have access to production and very limited to dev environment in terms of ssh/db endpoints.
At my n-2 job (2017-mid 2018), I was the dev lead when management decided to “move to the cloud”. They hired a bunch of “consultants” who were old school operations people who only knew how to do lift and shifts.
I didn’t know cloud from a whole in the wall. But the internal IT department treated AWS just like they did their Colo. I thought AWS was just a bunch of VMs and I treated it as such for a green field implementation.
I studied for the AWS Solution Architect certification just so I would know what I didn’t know and to be able to come up with some intelligent ideas for phase 2.
I ended up leaving that job and working for a startup. The CTO knew I had only theoretical knowledge of AWS. But I had good system design instincts and he liked my ideas. I was hired as a senior developer. But that rapidly morphed into a cloud architect role. I took advantage of AWS and all of its locked in goodness including moving everything to either Lambda and Fargate (serverless Docker).
I had admin rights to everything until I voluntarily gave myself the same constraints to production that everyone else had when we hired a couple of operation guys.
We scaled without any issues as the company grew and Covid happened - we worked in the healthcare industry.
Now I work for AWS. But I’ve done my share of managing servers since the mid 90s as part of my job. That’s a life I don’t ever want to go back to.
If it makes things difficult, you shouldn't be using it.
It is overhyped and it sucks for most use case.