8 ms·

Scalability itself isn't the selling point. It's freedom. It's the freedom to get things wrong, iterate and try again. It's the freedom to move resources aroun

Scalability itself isn't the selling point. It's freedom. It's the freedom to get things wrong, iterate and try again. It's the freedom to move resources around. It's the freedom of not having to wait for your procurement process and approval from a purchasing department. It's the freedom of not having to wait for your operations team to plug in and configure bare metal. And all of these freedoms have compounding interest. For most organizations, what I just talked about equates to man years of work wasted and I think a lot of people nitpicking about cloud being expensive have lost sight of this. Sure it costs more, but it's from money you've already saved. You'll have loads of saved money left to spend on more developers too.

Zelphyr 6y ago
It sounds to me like you're describing a corporate environment with all the bureaucracy that comes with such an environment. That scenario likely has the traffic and revenue to justify a full AWS build out. I'm talking about new projects at much smaller companies, or much smaller departments within the company that don't yet know if the product they're building is going to even work. Not to mention; I have the same freedoms to try things out with a $10/mo DigitalOcean droplet as I do EC2/Lambda/ELB/RDS/S3/etc... If something doesn't work, delete the droplet and start over. To that degree, it's even easier, cheaper, and more free to just test something out in Docker containers on my laptop. So, respectfully, I'm not buying the "freedom" argument. That's not even the selling point AWS is pitching.
- WrtCdEvrydy 6y ago
  Yeah, AWS isn't for a smaller company. When you have a real finance department that vets each third party or have some governmental requirement to get three quotes for each new service (part of requirements set out to minimize grift in sourcing), having a single bill that can be expanded to include new projects and services makes it a little simple. This causes a problem during cost cutting because unless it's a priority your bill will spiral out of control.
  - candiodari 6y ago
    And yet, AWS isn't for a really larger company either. At some point the bills become so huge that running your own IT and datacenters is cheaper. Usually a lot. Even when it means building some AWS services yourself. https://www.bmc.com/blogs/dropbox-aws/ https://www.bmc.com/blogs/dropbox-aws/
    - oblio 6y ago
      > These large companies rely on these established solutions, paying much bigger bills than Dropbox – surely, there must be a good reason for it. Maybe the answer is this: the cloud isn’t the answer for everyone, but it probably is for most companies.
    - ldng 6y ago
      Yes, it really is a curve bell but I get deride every time I say it ... the power of marketing.
      - apple4ever 6y ago
        A bell curve is a great way to describe it.
    - taylodl 6y ago
      Worker at Fortune 200 company here having multiple datacenters and the operations staff to go with that. So far, every single application we've ported over to AWS has resulted in reduced costs. I'm not even talking about total costs, i.e. datacenter power costs, real estate taxes, staffing costs - I'm only talking about server costs, networking costs, storage costs and software licensing costs. So far AWS has beat on-premise every single time. Is it cheap? Compared to running on-premise Hell Yeah! Our average savings has been 60% (and like I said we're not even looking at total cost, so the actual average savings is even higher). It's ridiculous.
- busterarm 6y ago
  If you know how to build in AWS cost-effectively (and really to cost-effectively use compute in general), I would still pick cloud over buying any hardware. For my last gig I was hosting the web infrastructure for a 5B/yr enterprise with a low-5 digit Alexa Rank on roughly $100/mo in EC2 instances. That was after converting the property to a static site built with jekyll (you can do pretty amazing, magical-looking things with front end JS calling out to apis and nginx SSI while still serving static conntent) and a hosted wordpress ($25/mo) for the content editors (and CircleCI's free tier for builds -- woop woop). And we were insanely over-provisioned with those t2.smalls. Procurement sucks. Having to test out new systems when you need to buy new hardware 2 years later also sucks. Having to wait behind much larger customers when Intel has a Xeon supply shortage sucks (2018 sucked if you had to buy servers).
  - Zelphyr 6y ago
    I've mentioned this elsewhere but; I'm not arguing co-location over cloud. I'm arguing inexpensive cloud like DigitalOcean, Linode, or LightSail over a complex AWS configuration designed to scale with near infinite flexibility. Why does a product that gets 100 visitors a day need that? $5-10/month serves them just fine.
    - busterarm 6y ago
      LightSail isn't any cheaper than the EC2 instance types backing it. Everything else (VPCs, IAM roles, etc) doesn't have a cost associated. What you're missing is that cost/complexity-wise, LightSail and EC2 are equivalent. The only difference between them is your interface to it. LightSail doesn't give you some pretty necessary knobs to kick things into a working state when the EC2 instances are having a burger. In fact, the last time I used LightSail and had a problem with unavailable instances, I just ran the ec2 api commands against the lightsail instance IDs to solve my problem. DigitalOcean has some networking properties that make it extremely undesirable for some use cases and Linode is frequently the target of massive global DDOS. I remember well a few years ago the Christmas Eve Linode DDOS because I had to work 20 hours that day. Thankfully it was only 20 hours because we were already in the process of moving off of Linode and we just decided to flip all of the switches to serve out of AWS. Most of the time was spent waiting on DNS TTLs. Instance costs across all of the cloud providers are pretty competitive. Where AWS and Google Cloud and Azure are more expensive are in those "extra" services where you would be paying people to run infrastructure (elasticsearch, sql databases, etc). DO, Linode, etc, don't give you that option -- it's not an apples-to-apples comparison....and in most cases you shouldn't use some of these things. Definitely no service where you can't just pick up and go use some other hosting tomorrow. Cloud vendor lock-in is real.
- busterarm 6y ago
  I didn't even mention the best part about hosting projects in cloud providers. You can generalize the infrastructure to run 99% of businesses needs and write that Terraform code only once. You can bring that with you everywhere and take care of the basics in seconds and you can sleep at night easily without a pager going off.
  - calvinmorrison 6y ago
    We used this with Azure. We contracted a firm to write a stack for eCommerce sites we were spinning up left and right. It passed through ITIL and was approved all over the chain. After that - security was happy, ops was happy, everyone was happy. Everything was just deploying an application - be it an application making millions of dollars per instance across many brands. It enabled the branding/marketing teams to launch sites without waiting for months of tech backlog. it was beautiful
    - mattmanser 6y ago
      What on earth has this got to do with the scenario being discussed? You have a mature product, with a proven market and known scalability demands. The exact opposite of how this thread started and somehow this is a good anecdote refuting it!
      - calvinmorrison 6y ago
        > You can generalize the infrastructure to run 99% of businesses needs and write that Terraform code only once. You can bring that with you everywhere and take care of the basics in seconds and you can sleep at night easily without a pager going off. To quote my parent. That's what we did and it worked for us.
        busterarm 6y ago
        It was in an almost exactly similar situation to yours where I learned to do this and I've been able to scale it up to companies with 1000x more demanding infrastructure. The funnier thing in my case was that three years after I left, the infrastructure was humming along fine with nobody actively looking at it. They never hired anyone to look after it because it never gave them any problems and they would have been fine to keep paying me to be there and do little/nothing. I've staked my whole career on this way of doing things and I'm never looking back.
- cortesoft 6y ago
  I am confused how DigitalOcean is different than AWS? Why is a $10/mo DO droplet different than a small EC2 instance?
  - mlboss 6y ago
    Compute wise they may be same but configuration wise EC2 instance is a super complex.
- tracker1 6y ago
  I have to agree... I think DO is pretty good as a starter ground... found dokku because of the DO startup option, and it's pretty much my go to for spinning something up to play with and/or tear down. Create an app with a Dockerfile in the root of the project, and it's a git push away from deployed. The LE extension adds https, and it pretty much just works. Connecting to DO hosted databases and object storage is pretty smooth as well. It doesn't auto-scale like FaaS options, or offer a lot of the other bits one may want/need, but it does good for a lot of the one-off things I'll play with.
- User23 6y ago
  Amazon itself used to be that environment. Before AWS was adopted internally, which it wasn't for some time, to say nothing of the many years before it was created, getting capacity involved a weeks or even months long political game with the infrastructure team. Even infrastructure devs had to struggle to find resources. Hiring managers would literally horse trade their spare capacity.
  - rualca 6y ago
    > Amazon itself used to be that environment. Before AWS was adopted internally, which it wasn't for some time, to say nothing of the many years before it was created, getting capacity involved a weeks or even months long political game with the infrastructure team. It's my understanding that you're describing how Amazon worked in the 90s. It's my understanding that Amazon afterwards moved to an internal cloud provider, and afterwards spun off AWS which worked in parallel with Amazon's internal cloud provider.
    - busterarm 6y ago
      > It's my understanding that you're describing how Amazon worked in the 90s. It's my understanding that Amazon afterwards moved to an internal cloud provider, and afterwards spun off AWS which worked in parallel with Amazon's internal cloud provider. Not at all. Amazon's transformation took years. Up until last year, amazon.com was Oracle's biggest customer. AWS development far outpaced their actual use of it.
      - User23 6y ago
        The website platform itself started migrating to AWS, in a crude but reasonably effective way, in 2009. Various other service owners migrated sooner though. Also there had already long been a directive to build services as though they were going to be used by external customers since the early 2000s. It's not wrong to view AWS as just another step in Amazon's long services journey, although that elides many significant events.
deeviant 6y ago
This sounds like a Matthew McConaughey AWS commercial rather than a thought-out technical argument.
- busterarm 6y ago
  The whole point of my statement was that it's NOT a technical argument. Anyone with significant experience and maturity knows this already. Being technically correct doesn't matter if you've created more work for yourself than you can handle. "Scalability" is much more often a people management problem rather than a technical one. Please come back and tell me how you feel about this when you have 10^4+ servers in your care. The nice thing about well-orchestrated cloud is that you can run your infrastructure the same way whether you have 10^1 or 10^5.
amerkhalid 6y ago
I know corps and teams where they need approvals for each cloud resource they instantiate. That is a culture problem. On other hand, when we were using simple VPSes at various companies, at some companies, I could just send email saying I provisioned a new server and at the others, they wanted a ticket with justification for it. But we always had enough test servers to try out and experiment. Cloud is great in many ways but freedom has more to do with an organization.
- busterarm 6y ago
  Fair. I've seen shops like that and I feel bad for them, but that's an organizational limitation, not one imposed by the cloud provider. If you want to buy server hardware, there is always the spec, testing and sales process no matter what. Hardware buying eats so much time...but at least the fancy dinners are kinda nice. And there's a proper way to do the accounting for it as a depreciating asset vs buying cloud (and most public orgs actually prefer the former).
- jjav 6y ago
  > I know corps and teams where they need approvals for each cloud resource they instantiate. That is a culture problem. I'm on the software side so I want my compute resources in the next 30 seconds like anyone, but.. at a larger company there needs to be controls in place or things can go bad quick. At one company I'm aware of, finance really started banging on doors when the cloud bill went over $1M/month and nobody really knew very clearly what any of it was being spent on or what products or customers each expense was associated with.
- thu2111 6y ago
  It's not a culture problem, it's a reaction to what happens if there aren't any controls on spending other people's money: people just waste resources like there's no tomorrow. I've seen this at my current employer. Like so many, got hooked via first-hit-is-free Azure credits. It doesn't even run end user facing services, just does software development, yet somehow after a few years of being a startup the cloud bill was millions of dollars a year. Why: because engineers would create a fresh VM from scratch rather than just logging in and using their accounts on pre-existing VMs. They'd forget to delete resources. They'd use expensive services like managed Kubernetes because why not. There was also a more subtle cost harder to account for: Azure machines are dog slow so significant engineering time was wasted trying to work around that problem. There has to be some friction to push people into using pre-existing hardware instead of acquiring more. If there isn't you end up with an absurd IT footprint well beyond anything justifiable in engineering terms.
joana035 6y ago
Cloud is the opposite of Freedom. You can get things wrong, iterate and try again with basically anything. Assuming that everything else other than cloud is automatically bad and full of bureaucracy does not inspire anyone.
jjav 6y ago
> It's freedom. Being locked in to AWS (or GCP, or..) when costs are rising out of control is what I consider the opposite of freedom. I was with one startup that went full-in on AWS features, so it was very difficult to migrate. Sure, we got started real quick, that was nice. I argued early on that we need to be careful of not getting locked in to AWS in case we need to jump away once we have some customer growth, but everyone else thought that was silly. Fast forward two years and our AWS bill was about $2500 per year per customer. Revenue per customer, certainly nowhere near that. Burning VC money gets you far but only so far. Yes we ran out of money.
- busterarm 6y ago
  That's where maturity comes in to play. The reps from the major clouds constantly pester us to use their vendor-only features and we always politely have to say "no thanks". We're up front about our multi-cloud strategy and only use the basic resources that are roughly equivalent/consistent between providers. We have the expertise to run whatever managed application they have ourselves and the engineers to build our own platforms.
- fomine3 6y ago
  Just curious, what's the primary cost in the case? I suspect bandwidth.
collsni 6y ago
As a security architect, I hate you. I get the freedom but I don't want our corporate data floating on a insecure elastic search cluster. Thanks
- busterarm 6y ago
  Who says that there's no room for security here? It's very easy to implement strict controls for who and how infrastructure gets created. Public companies have to use this too and we have all of the compliance requirements I'm sure you're aware of. Automating this and automating the guardrails makes your job _easier_ not harder. I have a DefCon black badge. I'm not a barbarian.
dragonsh 6y ago
> It's freedom. AWS or any cloud service is anything but freedom. So please use the word freedom judiciously. If you are working with AWS your application and your whole organization is at the whims of Amazon. You will not even be able to migrate if you are tied into those API's and services because they are not same across cloud providers. You don't even own the data or compute resource hosted on such cloud services because just by a single notice from a government agency your account will be blocked without access to your own data or compute resources. It has happened and will continue to happen because for government approaching single cloud provider is much easier than going over the process of getting it for company or an individual (more costly and difficult given different jurisdiction across country and state lines). In terms of technical freedom you will have less of it and will be tied into proprietary extensions, API and services offered by those cloud providers. On the other hand for self-hosted infrastructure government notice will not block access to resources owned by you and data in those resources. You can respond to notice and continue using those resources until court rules. So it is more freedom than a cloud can offer. In our organization we need to go extra mile and put extra engineering efforts to make sure our apps can work on different clouds with different services (e.g. using apache libcloud, avoiding proprietary API's).
- busterarm 6y ago
  > If you are working with AWS your application and your whole organization is at the whims of Amazon. Part of freedom is the freedom to do stupid things. > You will not even be able to migrate if you are tied into those API's and services because they are not same across cloud providers. VPCs, Instances, Load Balancers and Storage are roughly-equivalent everywhere and the differences between are mostly-trivial. For the rest of the "shinies" they offer, well, see above. > You don't even own the data or compute resource hosted on such cloud services because just by a single notice from a government agency your account will be blocked without access to your own data or compute resources. If you think this doesn't also apply to your physical racks in datacenters, you've got another thing coming. Ask Lavabit. Design for this in your strategy. You can still "own" your data and have it hosted in the cloud too. There's no reason to have to be exclusive. > In terms of technical freedom you will have less of it and will be tied into proprietary extensions, API and services offered by those cloud providers. As mentioned before, stick to running in instances and you're no differently off than anywhere else you can operate. > On the other hand for self-hosted infrastructure government notice will not block access to resources owned by you and data in those resources. You can respond to notice and continue using those resources until court rules. Absolutely not. With a warrant, the authorities will come and take your shit. They have guns. You don't. Ask Lavabit. Ask The Pirate Bay. Ask any blockchain drug pusher.
rualca 6y ago
> It's the freedom to get things wrong, iterate and try again. It's the freedom to move resources around. It's the freedom of not having to wait for your procurement process and approval from a purchasing department. It's the freedom of not having to wait for your operations team to plug in and configure bare metal. I don't understand your point. How is any random cloud provider, or even hosting company, a blocker to moving resources around or wait for procurement or to iterate? I'm looking at the Hetzner cloud dashboard and I'm free to launch how many instances I need at the drop of a hat. In the end there's an itemized bill, which unlike AWS you pay only for what you ordered up front and you can reason about without having to endure advance courses or freaking machine learning tools. Where exactly are you seeing any freedom at all on AWS?
dvfjsdhgfv 6y ago
Yeah, the freedom to spend corporate money is nice, but for a smaller org, the experience is exactly the opposite. We have ca. 30 servers and I can move things around without any problem. Most of them are already configured and ready for operation; reconfiguring is easy. With AWS, first of all you need to learn all their ecosystem, and then we had constant problems with cost allocation. Yes, you can book all these charges under "IT", but it's too broad, you need to assign them to projects. And then they constantly grow. With bare metal it's 100% predictable. Where to book the sudden spike in costs in April? Why did it happen? We had €3000 booked for this project in April, why do we have to pay €5000? And so on. Sure, if you have too much money to burn and the financial department is lax with controlling the costs, AWS feels great, but not everybody has this luxury.
geon 6y ago
At work, we have our own “cloud”. It is a cluster running kubernetes, so if I need a bunch of vms I can just spin them up in house.

Zelphyr 6y ago

It sounds to me like you're describing a corporate environment with all the bureaucracy that comes with such an environment. That scenario likely has the traffic and revenue to justify a full AWS build out. I'm talking about new projects at much smaller companies, or much smaller departments within the company that don't yet know if the product they're building is going to even work. Not to mention; I have the same freedoms to try things out with a $10/mo DigitalOcean droplet as I do EC2/Lambda/ELB/RDS/S3/etc... If something doesn't work, delete the droplet and start over. To that degree, it's even easier, cheaper, and more free to just test something out in Docker containers on my laptop. So, respectfully, I'm not buying the "freedom" argument. That's not even the selling point AWS is pitching.

WrtCdEvrydy 6y ago
Yeah, AWS isn't for a smaller company. When you have a real finance department that vets each third party or have some governmental requirement to get three quotes for each new service (part of requirements set out to minimize grift in sourcing), having a single bill that can be expanded to include new projects and services makes it a little simple. This causes a problem during cost cutting because unless it's a priority your bill will spiral out of control.
- candiodari 6y ago
  And yet, AWS isn't for a really larger company either. At some point the bills become so huge that running your own IT and datacenters is cheaper. Usually a lot. Even when it means building some AWS services yourself. https://www.bmc.com/blogs/dropbox-aws/ https://www.bmc.com/blogs/dropbox-aws/
  - oblio 6y ago
    > These large companies rely on these established solutions, paying much bigger bills than Dropbox – surely, there must be a good reason for it. Maybe the answer is this: the cloud isn’t the answer for everyone, but it probably is for most companies.
  - ldng 6y ago
    Yes, it really is a curve bell but I get deride every time I say it ... the power of marketing.
    - apple4ever 6y ago
      A bell curve is a great way to describe it.
  - taylodl 6y ago
    Worker at Fortune 200 company here having multiple datacenters and the operations staff to go with that. So far, every single application we've ported over to AWS has resulted in reduced costs. I'm not even talking about total costs, i.e. datacenter power costs, real estate taxes, staffing costs - I'm only talking about server costs, networking costs, storage costs and software licensing costs. So far AWS has beat on-premise every single time. Is it cheap? Compared to running on-premise Hell Yeah! Our average savings has been 60% (and like I said we're not even looking at total cost, so the actual average savings is even higher). It's ridiculous.
busterarm 6y ago
If you know how to build in AWS cost-effectively (and really to cost-effectively use compute in general), I would still pick cloud over buying any hardware. For my last gig I was hosting the web infrastructure for a 5B/yr enterprise with a low-5 digit Alexa Rank on roughly $100/mo in EC2 instances. That was after converting the property to a static site built with jekyll (you can do pretty amazing, magical-looking things with front end JS calling out to apis and nginx SSI while still serving static conntent) and a hosted wordpress ($25/mo) for the content editors (and CircleCI's free tier for builds -- woop woop). And we were insanely over-provisioned with those t2.smalls. Procurement sucks. Having to test out new systems when you need to buy new hardware 2 years later also sucks. Having to wait behind much larger customers when Intel has a Xeon supply shortage sucks (2018 sucked if you had to buy servers).
- Zelphyr 6y ago
  I've mentioned this elsewhere but; I'm not arguing co-location over cloud. I'm arguing inexpensive cloud like DigitalOcean, Linode, or LightSail over a complex AWS configuration designed to scale with near infinite flexibility. Why does a product that gets 100 visitors a day need that? $5-10/month serves them just fine.
  - busterarm 6y ago
    LightSail isn't any cheaper than the EC2 instance types backing it. Everything else (VPCs, IAM roles, etc) doesn't have a cost associated. What you're missing is that cost/complexity-wise, LightSail and EC2 are equivalent. The only difference between them is your interface to it. LightSail doesn't give you some pretty necessary knobs to kick things into a working state when the EC2 instances are having a burger. In fact, the last time I used LightSail and had a problem with unavailable instances, I just ran the ec2 api commands against the lightsail instance IDs to solve my problem. DigitalOcean has some networking properties that make it extremely undesirable for some use cases and Linode is frequently the target of massive global DDOS. I remember well a few years ago the Christmas Eve Linode DDOS because I had to work 20 hours that day. Thankfully it was only 20 hours because we were already in the process of moving off of Linode and we just decided to flip all of the switches to serve out of AWS. Most of the time was spent waiting on DNS TTLs. Instance costs across all of the cloud providers are pretty competitive. Where AWS and Google Cloud and Azure are more expensive are in those "extra" services where you would be paying people to run infrastructure (elasticsearch, sql databases, etc). DO, Linode, etc, don't give you that option -- it's not an apples-to-apples comparison....and in most cases you shouldn't use some of these things. Definitely no service where you can't just pick up and go use some other hosting tomorrow. Cloud vendor lock-in is real.
busterarm 6y ago
I didn't even mention the best part about hosting projects in cloud providers. You can generalize the infrastructure to run 99% of businesses needs and write that Terraform code only once. You can bring that with you everywhere and take care of the basics in seconds and you can sleep at night easily without a pager going off.
- calvinmorrison 6y ago
  We used this with Azure. We contracted a firm to write a stack for eCommerce sites we were spinning up left and right. It passed through ITIL and was approved all over the chain. After that - security was happy, ops was happy, everyone was happy. Everything was just deploying an application - be it an application making millions of dollars per instance across many brands. It enabled the branding/marketing teams to launch sites without waiting for months of tech backlog. it was beautiful
  - mattmanser 6y ago
    What on earth has this got to do with the scenario being discussed? You have a mature product, with a proven market and known scalability demands. The exact opposite of how this thread started and somehow this is a good anecdote refuting it!
    - calvinmorrison 6y ago
      > You can generalize the infrastructure to run 99% of businesses needs and write that Terraform code only once. You can bring that with you everywhere and take care of the basics in seconds and you can sleep at night easily without a pager going off. To quote my parent. That's what we did and it worked for us.
      - busterarm 6y ago
        It was in an almost exactly similar situation to yours where I learned to do this and I've been able to scale it up to companies with 1000x more demanding infrastructure. The funnier thing in my case was that three years after I left, the infrastructure was humming along fine with nobody actively looking at it. They never hired anyone to look after it because it never gave them any problems and they would have been fine to keep paying me to be there and do little/nothing. I've staked my whole career on this way of doing things and I'm never looking back.
cortesoft 6y ago
I am confused how DigitalOcean is different than AWS? Why is a $10/mo DO droplet different than a small EC2 instance?
- mlboss 6y ago
  Compute wise they may be same but configuration wise EC2 instance is a super complex.
tracker1 6y ago
I have to agree... I think DO is pretty good as a starter ground... found dokku because of the DO startup option, and it's pretty much my go to for spinning something up to play with and/or tear down. Create an app with a Dockerfile in the root of the project, and it's a git push away from deployed. The LE extension adds https, and it pretty much just works. Connecting to DO hosted databases and object storage is pretty smooth as well. It doesn't auto-scale like FaaS options, or offer a lot of the other bits one may want/need, but it does good for a lot of the one-off things I'll play with.
User23 6y ago
Amazon itself used to be that environment. Before AWS was adopted internally, which it wasn't for some time, to say nothing of the many years before it was created, getting capacity involved a weeks or even months long political game with the infrastructure team. Even infrastructure devs had to struggle to find resources. Hiring managers would literally horse trade their spare capacity.
- rualca 6y ago
  > Amazon itself used to be that environment. Before AWS was adopted internally, which it wasn't for some time, to say nothing of the many years before it was created, getting capacity involved a weeks or even months long political game with the infrastructure team. It's my understanding that you're describing how Amazon worked in the 90s. It's my understanding that Amazon afterwards moved to an internal cloud provider, and afterwards spun off AWS which worked in parallel with Amazon's internal cloud provider.
  - busterarm 6y ago
    > It's my understanding that you're describing how Amazon worked in the 90s. It's my understanding that Amazon afterwards moved to an internal cloud provider, and afterwards spun off AWS which worked in parallel with Amazon's internal cloud provider. Not at all. Amazon's transformation took years. Up until last year, amazon.com was Oracle's biggest customer. AWS development far outpaced their actual use of it.
    - User23 6y ago
      The website platform itself started migrating to AWS, in a crude but reasonably effective way, in 2009. Various other service owners migrated sooner though. Also there had already long been a directive to build services as though they were going to be used by external customers since the early 2000s. It's not wrong to view AWS as just another step in Amazon's long services journey, although that elides many significant events.

deeviant 6y ago

This sounds like a Matthew McConaughey AWS commercial rather than a thought-out technical argument.

busterarm 6y ago
The whole point of my statement was that it's NOT a technical argument. Anyone with significant experience and maturity knows this already. Being technically correct doesn't matter if you've created more work for yourself than you can handle. "Scalability" is much more often a people management problem rather than a technical one. Please come back and tell me how you feel about this when you have 10^4+ servers in your care. The nice thing about well-orchestrated cloud is that you can run your infrastructure the same way whether you have 10^1 or 10^5.

amerkhalid 6y ago

I know corps and teams where they need approvals for each cloud resource they instantiate. That is a culture problem. On other hand, when we were using simple VPSes at various companies, at some companies, I could just send email saying I provisioned a new server and at the others, they wanted a ticket with justification for it. But we always had enough test servers to try out and experiment. Cloud is great in many ways but freedom has more to do with an organization.

busterarm 6y ago
Fair. I've seen shops like that and I feel bad for them, but that's an organizational limitation, not one imposed by the cloud provider. If you want to buy server hardware, there is always the spec, testing and sales process no matter what. Hardware buying eats so much time...but at least the fancy dinners are kinda nice. And there's a proper way to do the accounting for it as a depreciating asset vs buying cloud (and most public orgs actually prefer the former).
jjav 6y ago
> I know corps and teams where they need approvals for each cloud resource they instantiate. That is a culture problem. I'm on the software side so I want my compute resources in the next 30 seconds like anyone, but.. at a larger company there needs to be controls in place or things can go bad quick. At one company I'm aware of, finance really started banging on doors when the cloud bill went over $1M/month and nobody really knew very clearly what any of it was being spent on or what products or customers each expense was associated with.
thu2111 6y ago
It's not a culture problem, it's a reaction to what happens if there aren't any controls on spending other people's money: people just waste resources like there's no tomorrow. I've seen this at my current employer. Like so many, got hooked via first-hit-is-free Azure credits. It doesn't even run end user facing services, just does software development, yet somehow after a few years of being a startup the cloud bill was millions of dollars a year. Why: because engineers would create a fresh VM from scratch rather than just logging in and using their accounts on pre-existing VMs. They'd forget to delete resources. They'd use expensive services like managed Kubernetes because why not. There was also a more subtle cost harder to account for: Azure machines are dog slow so significant engineering time was wasted trying to work around that problem. There has to be some friction to push people into using pre-existing hardware instead of acquiring more. If there isn't you end up with an absurd IT footprint well beyond anything justifiable in engineering terms.

joana035 6y ago

Cloud is the opposite of Freedom. You can get things wrong, iterate and try again with basically anything. Assuming that everything else other than cloud is automatically bad and full of bureaucracy does not inspire anyone.

jjav 6y ago

> It's freedom. Being locked in to AWS (or GCP, or..) when costs are rising out of control is what I consider the opposite of freedom. I was with one startup that went full-in on AWS features, so it was very difficult to migrate. Sure, we got started real quick, that was nice. I argued early on that we need to be careful of not getting locked in to AWS in case we need to jump away once we have some customer growth, but everyone else thought that was silly. Fast forward two years and our AWS bill was about $2500 per year per customer. Revenue per customer, certainly nowhere near that. Burning VC money gets you far but only so far. Yes we ran out of money.

busterarm 6y ago
That's where maturity comes in to play. The reps from the major clouds constantly pester us to use their vendor-only features and we always politely have to say "no thanks". We're up front about our multi-cloud strategy and only use the basic resources that are roughly equivalent/consistent between providers. We have the expertise to run whatever managed application they have ourselves and the engineers to build our own platforms.
fomine3 6y ago
Just curious, what's the primary cost in the case? I suspect bandwidth.

collsni 6y ago

As a security architect, I hate you. I get the freedom but I don't want our corporate data floating on a insecure elastic search cluster. Thanks

busterarm 6y ago
Who says that there's no room for security here? It's very easy to implement strict controls for who and how infrastructure gets created. Public companies have to use this too and we have all of the compliance requirements I'm sure you're aware of. Automating this and automating the guardrails makes your job _easier_ not harder. I have a DefCon black badge. I'm not a barbarian.

dragonsh 6y ago

> It's freedom. AWS or any cloud service is anything but freedom. So please use the word freedom judiciously. If you are working with AWS your application and your whole organization is at the whims of Amazon. You will not even be able to migrate if you are tied into those API's and services because they are not same across cloud providers. You don't even own the data or compute resource hosted on such cloud services because just by a single notice from a government agency your account will be blocked without access to your own data or compute resources. It has happened and will continue to happen because for government approaching single cloud provider is much easier than going over the process of getting it for company or an individual (more costly and difficult given different jurisdiction across country and state lines). In terms of technical freedom you will have less of it and will be tied into proprietary extensions, API and services offered by those cloud providers. On the other hand for self-hosted infrastructure government notice will not block access to resources owned by you and data in those resources. You can respond to notice and continue using those resources until court rules. So it is more freedom than a cloud can offer. In our organization we need to go extra mile and put extra engineering efforts to make sure our apps can work on different clouds with different services (e.g. using apache libcloud, avoiding proprietary API's).

busterarm 6y ago
> If you are working with AWS your application and your whole organization is at the whims of Amazon. Part of freedom is the freedom to do stupid things. > You will not even be able to migrate if you are tied into those API's and services because they are not same across cloud providers. VPCs, Instances, Load Balancers and Storage are roughly-equivalent everywhere and the differences between are mostly-trivial. For the rest of the "shinies" they offer, well, see above. > You don't even own the data or compute resource hosted on such cloud services because just by a single notice from a government agency your account will be blocked without access to your own data or compute resources. If you think this doesn't also apply to your physical racks in datacenters, you've got another thing coming. Ask Lavabit. Design for this in your strategy. You can still "own" your data and have it hosted in the cloud too. There's no reason to have to be exclusive. > In terms of technical freedom you will have less of it and will be tied into proprietary extensions, API and services offered by those cloud providers. As mentioned before, stick to running in instances and you're no differently off than anywhere else you can operate. > On the other hand for self-hosted infrastructure government notice will not block access to resources owned by you and data in those resources. You can respond to notice and continue using those resources until court rules. Absolutely not. With a warrant, the authorities will come and take your shit. They have guns. You don't. Ask Lavabit. Ask The Pirate Bay. Ask any blockchain drug pusher.

rualca 6y ago

> It's the freedom to get things wrong, iterate and try again. It's the freedom to move resources around. It's the freedom of not having to wait for your procurement process and approval from a purchasing department. It's the freedom of not having to wait for your operations team to plug in and configure bare metal. I don't understand your point. How is any random cloud provider, or even hosting company, a blocker to moving resources around or wait for procurement or to iterate? I'm looking at the Hetzner cloud dashboard and I'm free to launch how many instances I need at the drop of a hat. In the end there's an itemized bill, which unlike AWS you pay only for what you ordered up front and you can reason about without having to endure advance courses or freaking machine learning tools. Where exactly are you seeing any freedom at all on AWS?

dvfjsdhgfv 6y ago

Yeah, the freedom to spend corporate money is nice, but for a smaller org, the experience is exactly the opposite. We have ca. 30 servers and I can move things around without any problem. Most of them are already configured and ready for operation; reconfiguring is easy. With AWS, first of all you need to learn all their ecosystem, and then we had constant problems with cost allocation. Yes, you can book all these charges under "IT", but it's too broad, you need to assign them to projects. And then they constantly grow. With bare metal it's 100% predictable. Where to book the sudden spike in costs in April? Why did it happen? We had €3000 booked for this project in April, why do we have to pay €5000? And so on. Sure, if you have too much money to burn and the financial department is lax with controlling the costs, AWS feels great, but not everybody has this luxury.

geon 6y ago

At work, we have our own “cloud”. It is a cluster running kubernetes, so if I need a bunch of vms I can just spin them up in house.