5 ms·

That sort of crap is the reason we host all our stuff on root servers. Even trying to read the amazon pricing for their instances, hours and what not, drives m

That sort of crap is the reason we host all our stuff on root servers. Even trying to read the amazon pricing for their instances, hours and what not, drives me insane. Seems this is done on purpose. no wonder they make so much money with it. So i have never seen a reason to move any stuff to the cloud. Just grab a dedicated server for a few bucks and put a bunch of docker containers on those. Its way cheaper, usually not more complicated. Just use a CI with Gitlab runners or whatever and be done with it. Most apps don't need scaling anyway and if you do, just put that app on bare metal fitting your requirements.

scrollaway 6y ago
AWS pricing is not obscure, it's just not for you. So in that sense, you are correct to not see a reason to move to the cloud, but your advice does not apply to everyone. And I don't believe they make "more money" that way at all. AWS margins are either very low or very high, and the higher margins and prices tend to be the "simpler" ones: packaged, managed products such as Redshift that are billed on fewer tiers and flatter prices. When you design your application with AWS, pricing has to enter your design considerations. For example if you are designing something that will interact a lot with S3 you want to minimize PUTs. You want to minimize ram usage on lambda by streaming rather than buffering. Etc. AWS is not a suitable product for playground stuff. The only reason it gets used as such is because it's easier if you're already using AWS for other things (or it's you're already very familiar with it).
- nojito 6y ago
  AWS's margin is currently 30+% which is massive. >AWS pricing is not obscure There is a massive secondary consulting market because of AWS's price obscurities.
  - scrollaway 6y ago
    The margin is absolutely not the same across all products. > There is a massive secondary consulting market because of AWS's price obscurities. Its. Not. For. You. AWS pricing is a part of your design. With some exceptions (that you aren't talking about), they charge you more for using more resources. You are forced to design systems that use less resources if you want to optimize your bill. That consulting market is an optimization market. It's economics at its best. If you are too small to have to take these things into account regardless, AWS is not for you. You're welcome to use it, but don't be surprised if you end up having to deal with these kinds of things which simply don't exist in the world of flat-price underprovisioned droplets.
    - nojito 6y ago
      >AWS pricing is a part of your design. With some exceptions (that you aren't talking about), they charge you more for using more resources. You are forced to design systems that use less resources if you want to optimize your bill. This is marketing. It's like saying you want to build a house and the quote you got ends up blowing up 100x overnight. Great example is the 100k credit for startups. You can repeat it's not for you all you want, but their business is predicated on pricing ignorance and vendor lockin.
      - scrollaway 6y ago
        The $100K credit (which I've been granted multiple times) is there because if Amazon can get you to invest serious work into their infra, they'll make up for it in the long run. It's not "lock in", it's sales. The only amazon "lock in" really is their bandwidth-out pricing, which is a sleazy tactic for sure but I'm not hesitant to call it out when it's the case. You can get the $100/$300/$1000 tier if you are in "just checking it out" solo mode. $5k and up requires either connections, partnerships, or a serious application. Anyway I don't know what your point is, I'm not even sure if you have one. They're not "marketing" their pricing, nor the fact that you are "forced to design systems that use less resources".
        csharptwdec19 6y ago
        > Anyway I don't know what your point is, I'm not even sure if you have one. They're not "marketing" their pricing, nor the fact that you are "forced to design systems that use less resources". I think they are referring to this statement: > > AWS pricing is a part of your design. With some exceptions (that you aren't talking about), they charge you more for using more resources. You are forced to design systems that use less resources if you want to optimize your bill. It is a defense that I've heard in many AWS talks in the past. Where it turns into a 'marketing' blurb to me is my real world experience in these AWS talks in the places I work. As a real world example, we had a product that required -some- architectural work, but otherwise was solid, and could run on 3 live EC2 instances (2 web LB, 1 live backend) and 1 spare (spare backend) The Consultant that AWS partnered us with? Suggested a very overdone architectural revamp, moving everything possible into AWS Specific technologies. It's marketing in that in many of our experiences, we know there is often at least one person on a team who does -not- have the discipline and/or experience to -keep- a system using less resources as the field goes from green to brown.
  - klohto 6y ago
    > There is a massive secondary consulting market because of AWS's price obscurities. While that's true, there is consulting market for most things that are complicated. Doesn't mean they are shady. It's simply not for you. You are welcome either to dive in or get a consultant. I promise you though, that AWS pricing isn't difficult once you understand few concepts and know your way around the Cost Explorer. With proper tagging, it's easy to drill down which resource is consuming how much. I don't believe there is a way to have a simple billing for a complicated product(s).
    - deleted 6y ago
      [deleted]
    - Closi 6y ago
      > While that's true, there is consulting market for most things that are complicated. Doesn't mean they are shady. It does mean it's not simple though.
      - scrollaway 6y ago
        Obscure and complex are different concepts. I'm part of that "secondary consulting market" FWIW, so I'd like to think I know a thing or two about it. Does AWS have high-margin prices? In aggregate, somewhat, but this is mostly driven by the big ticket managed enterprise items: Aurora, Redshift, Quicksight, probably Fargate, etc. A lot of their more popular stuff (S3, Lambda, …) offer incredible value for very little money. EC2 is the exception I believe, because I understand it to be high margin for how popular it is. But EC2 pricing is one of their simplest ones. Could AWS simplify some of their pricing? Yes, probably. There's always room for optimization. Personally for example I'd like to see their pricing be global rather than different by region (with understandable exceptions for govcloud and china). Is AWS making its pricing complicated for nefarious purposes? No, there is no evidence to support that. AWS pricing absolutely is not simple. It's a part of the AWS stack. You need to study AWS's events/signals system to be able to write apps that make the best use of AWS's interconnected stack. You need to study their APIs / SDKs to really understand what you're able to implement. And you need to study their billing systems to understand how to implement apps that run cheaply, and be able to predict potential runaway costs. It has to be a part of the design. That's why you may want to hire consultants for it: People who understand it better than you do, and will be able to assist you in reducing your costs. It's just another kind of optimization. Maybe some software engineers don't like it because it hits them where it hurts (the wallet) when they don't do it right, rather than be able to brush it off as they usually do. It's much easier to ignore the waste produced by, say for example, the 3000 javascript dependencies shipped with the fat, unoptimized electron app they ship on their users' desktops, that do a ton of unnecessary expensive computing; when all that crap is client-side and it's the downstream user's electricity bills and CPU time that's being used.
  - dragonwriter 6y ago
    > There is a massive secondary consulting market because of AWS’s price obscurities. There is a massive secondary consulting market because the enterprise market is addicted to secondary consulting. This secondary consulting market includes AWS pricing because it includes pretty much any IT service the target market might be interested in. A rational need for decomplexification isn’t necessary to explain the existence or coverage of enterprise secondary consulting, IT or otherwise.
- akh 6y ago
  How do you take pricing into your design considerations? Does it come with experience from using an AWS service in production and understanding how it's priced, combined with the usage numbers the new system might get? I'm trying to learn more about how engineers currently do this.
  - scrollaway 6y ago
    Basically, yes. It's not that complicated, it's just not something engineers are usually used to do. If you use an AWS service, you look at its pricing. Take s3 for example: whenever you use it, you'll pay for outgoing bandwidth, PUTs, GETs, and storage. So you seek to minimize all of these: 1. Bandwidth: use cache layers. This also minimizes GETs. 2. PUTs: design your app in a way that doesn't do unnecessary inserts into s3. Consider alternatives such as redis, postgres or filesystem depending on the need. 3. Storage: compress your objects if they compress well. If they aren't often accessed, use storage classes and auto lifecycle management. Pricing in AWS generally reflects some kind of engineering limitations you will face at scale in the first place, so it makes sense to go through this whole exercise either way.
  - thanksforthe42 6y ago
    Calling programmers "Engineers" is a misnomer. I wish programmers had the prestige it deserved for combining Science, tradition, authority, and art. Engineers are not allowed to use tradition, authority or art. They are restricted to being modern day calculators. Nothing is wrong with either.
    - csharptwdec19 6y ago
      The shift from 'Developer/Programmer' to engineer has indeed been part of a push away from creativity towards cookie-cutter work. An interesting analogue would be the Automotive industry; As time progressed, Companies focused more and more on 'engineering' versus art/tradition/etc. But as the industry evolved, "Flashy" vehicles that took risks became moreso either a halo product for a brand, or relegated to Luxury/Boutique. And, of course, there was the dark side of this shift; A good example from the 70s, the level of 'engineering' driving the design of the vehicle and it's assembly didn't take into consideration the actual line worker; in Ohio the workers wound up getting overworked, burned out, and in some cases actively sabotaged the product, because they were being treated like automated machines.
that_guy_iain 6y ago
> That sort of crap is the reason we host all our stuff on root servers. Having just started my own journey into building products for myself, pretty much the first thing I realised with my tech was I need to get dedicated servers instead of cloud just because it costs 100x less. > Just grab a dedicated server for a few bucks and put a bunch of docker containers on those. Exactly, if you really want kubernetes coolness to act cloud like, install kubernetes it's free and is super easy to setup. And with the cost savings you can literally buy multiple spare servers and with kubernetes using them all while keeping the usage low allowing to scale up new nodes if needed.
- throwaway201103 6y ago
  > kubernetes ... is super easy to setup Can you point me to the super easy setup guide? Because I've tried a few and never gotten it working.
  - WrtCdEvrydy 6y ago
    I don't like use kubernetes raw but I am a fan of Caprover (which has kubernetes support)
  - AntiImperialist 6y ago
    Canonical has microk8s, which you can install as a snap package. Super simple and works great.
  - styren 6y ago
    Have a look at https://github.com/hobby-kube/guide https://github.com/hobby-kube/guide I set up a 3 node cluster using it in an afternoon and haven't had any problems since.
croh 6y ago
> Most apps don't need scaling anyway and if you do, just put that app on bare metal fitting your requirements. Most important !
Aperocky 6y ago
> Most apps don't need scaling anyway This is exactly right. I host stuff in buckets/cloudfront and uses a bit of lambda/route53. I end up paying $4 a month. now that will be very different if 10 million people suddenly decide to visit my site, but if that happens money probably won't be a problem after all.
vmception 6y ago
> Most apps don't need scaling anyway and if you do Man, exactly right. Many of guys here would love crypto once you stop asking why and start asking how. The most lucrative projects these days are completely frontend UI, they don't even their own backends they as just read state from the nearest node when the client connects their wallet. Some people forgot that the scalability game was to convert traffic into money. So ditch that, and remember you are in the money game.
joshmanders 6y ago
> Even trying to read the amazon pricing for their instances, hours and what not, drives me insane. I get your sentiment but the pricing is that way because they want to charge you exactly what you use, not for reserving stuff. For example if you deploy a EC2 instance that comes out to be $15/mo total, and you deploy it on say the 10th of the month, do you want to be charged the whole $15? No, you want pro-rated.. But what if you only need that instance for like 6 days? Then what? You gonna do the math to figure out what it would have cost you yourself, or just read it per hour billing?

scrollaway 6y ago

AWS pricing is not obscure, it's just not for you. So in that sense, you are correct to not see a reason to move to the cloud, but your advice does not apply to everyone. And I don't believe they make "more money" that way at all. AWS margins are either very low or very high, and the higher margins and prices tend to be the "simpler" ones: packaged, managed products such as Redshift that are billed on fewer tiers and flatter prices. When you design your application with AWS, pricing has to enter your design considerations. For example if you are designing something that will interact a lot with S3 you want to minimize PUTs. You want to minimize ram usage on lambda by streaming rather than buffering. Etc. AWS is not a suitable product for playground stuff. The only reason it gets used as such is because it's easier if you're already using AWS for other things (or it's you're already very familiar with it).

nojito 6y ago
AWS's margin is currently 30+% which is massive. >AWS pricing is not obscure There is a massive secondary consulting market because of AWS's price obscurities.
- scrollaway 6y ago
  The margin is absolutely not the same across all products. > There is a massive secondary consulting market because of AWS's price obscurities. Its. Not. For. You. AWS pricing is a part of your design. With some exceptions (that you aren't talking about), they charge you more for using more resources. You are forced to design systems that use less resources if you want to optimize your bill. That consulting market is an optimization market. It's economics at its best. If you are too small to have to take these things into account regardless, AWS is not for you. You're welcome to use it, but don't be surprised if you end up having to deal with these kinds of things which simply don't exist in the world of flat-price underprovisioned droplets.
  - nojito 6y ago
    >AWS pricing is a part of your design. With some exceptions (that you aren't talking about), they charge you more for using more resources. You are forced to design systems that use less resources if you want to optimize your bill. This is marketing. It's like saying you want to build a house and the quote you got ends up blowing up 100x overnight. Great example is the 100k credit for startups. You can repeat it's not for you all you want, but their business is predicated on pricing ignorance and vendor lockin.
    - scrollaway 6y ago
      The $100K credit (which I've been granted multiple times) is there because if Amazon can get you to invest serious work into their infra, they'll make up for it in the long run. It's not "lock in", it's sales. The only amazon "lock in" really is their bandwidth-out pricing, which is a sleazy tactic for sure but I'm not hesitant to call it out when it's the case. You can get the $100/$300/$1000 tier if you are in "just checking it out" solo mode. $5k and up requires either connections, partnerships, or a serious application. Anyway I don't know what your point is, I'm not even sure if you have one. They're not "marketing" their pricing, nor the fact that you are "forced to design systems that use less resources".
      - csharptwdec19 6y ago
        > Anyway I don't know what your point is, I'm not even sure if you have one. They're not "marketing" their pricing, nor the fact that you are "forced to design systems that use less resources". I think they are referring to this statement: > > AWS pricing is a part of your design. With some exceptions (that you aren't talking about), they charge you more for using more resources. You are forced to design systems that use less resources if you want to optimize your bill. It is a defense that I've heard in many AWS talks in the past. Where it turns into a 'marketing' blurb to me is my real world experience in these AWS talks in the places I work. As a real world example, we had a product that required -some- architectural work, but otherwise was solid, and could run on 3 live EC2 instances (2 web LB, 1 live backend) and 1 spare (spare backend) The Consultant that AWS partnered us with? Suggested a very overdone architectural revamp, moving everything possible into AWS Specific technologies. It's marketing in that in many of our experiences, we know there is often at least one person on a team who does -not- have the discipline and/or experience to -keep- a system using less resources as the field goes from green to brown.
- klohto 6y ago
  > There is a massive secondary consulting market because of AWS's price obscurities. While that's true, there is consulting market for most things that are complicated. Doesn't mean they are shady. It's simply not for you. You are welcome either to dive in or get a consultant. I promise you though, that AWS pricing isn't difficult once you understand few concepts and know your way around the Cost Explorer. With proper tagging, it's easy to drill down which resource is consuming how much. I don't believe there is a way to have a simple billing for a complicated product(s).
  - deleted 6y ago
    [deleted]
  - Closi 6y ago
    > While that's true, there is consulting market for most things that are complicated. Doesn't mean they are shady. It does mean it's not simple though.
    - scrollaway 6y ago
      Obscure and complex are different concepts. I'm part of that "secondary consulting market" FWIW, so I'd like to think I know a thing or two about it. Does AWS have high-margin prices? In aggregate, somewhat, but this is mostly driven by the big ticket managed enterprise items: Aurora, Redshift, Quicksight, probably Fargate, etc. A lot of their more popular stuff (S3, Lambda, …) offer incredible value for very little money. EC2 is the exception I believe, because I understand it to be high margin for how popular it is. But EC2 pricing is one of their simplest ones. Could AWS simplify some of their pricing? Yes, probably. There's always room for optimization. Personally for example I'd like to see their pricing be global rather than different by region (with understandable exceptions for govcloud and china). Is AWS making its pricing complicated for nefarious purposes? No, there is no evidence to support that. AWS pricing absolutely is not simple. It's a part of the AWS stack. You need to study AWS's events/signals system to be able to write apps that make the best use of AWS's interconnected stack. You need to study their APIs / SDKs to really understand what you're able to implement. And you need to study their billing systems to understand how to implement apps that run cheaply, and be able to predict potential runaway costs. It has to be a part of the design. That's why you may want to hire consultants for it: People who understand it better than you do, and will be able to assist you in reducing your costs. It's just another kind of optimization. Maybe some software engineers don't like it because it hits them where it hurts (the wallet) when they don't do it right, rather than be able to brush it off as they usually do. It's much easier to ignore the waste produced by, say for example, the 3000 javascript dependencies shipped with the fat, unoptimized electron app they ship on their users' desktops, that do a ton of unnecessary expensive computing; when all that crap is client-side and it's the downstream user's electricity bills and CPU time that's being used.
- dragonwriter 6y ago
  > There is a massive secondary consulting market because of AWS’s price obscurities. There is a massive secondary consulting market because the enterprise market is addicted to secondary consulting. This secondary consulting market includes AWS pricing because it includes pretty much any IT service the target market might be interested in. A rational need for decomplexification isn’t necessary to explain the existence or coverage of enterprise secondary consulting, IT or otherwise.
akh 6y ago
How do you take pricing into your design considerations? Does it come with experience from using an AWS service in production and understanding how it's priced, combined with the usage numbers the new system might get? I'm trying to learn more about how engineers currently do this.
- scrollaway 6y ago
  Basically, yes. It's not that complicated, it's just not something engineers are usually used to do. If you use an AWS service, you look at its pricing. Take s3 for example: whenever you use it, you'll pay for outgoing bandwidth, PUTs, GETs, and storage. So you seek to minimize all of these: 1. Bandwidth: use cache layers. This also minimizes GETs. 2. PUTs: design your app in a way that doesn't do unnecessary inserts into s3. Consider alternatives such as redis, postgres or filesystem depending on the need. 3. Storage: compress your objects if they compress well. If they aren't often accessed, use storage classes and auto lifecycle management. Pricing in AWS generally reflects some kind of engineering limitations you will face at scale in the first place, so it makes sense to go through this whole exercise either way.
- thanksforthe42 6y ago
  Calling programmers "Engineers" is a misnomer. I wish programmers had the prestige it deserved for combining Science, tradition, authority, and art. Engineers are not allowed to use tradition, authority or art. They are restricted to being modern day calculators. Nothing is wrong with either.
  - csharptwdec19 6y ago
    The shift from 'Developer/Programmer' to engineer has indeed been part of a push away from creativity towards cookie-cutter work. An interesting analogue would be the Automotive industry; As time progressed, Companies focused more and more on 'engineering' versus art/tradition/etc. But as the industry evolved, "Flashy" vehicles that took risks became moreso either a halo product for a brand, or relegated to Luxury/Boutique. And, of course, there was the dark side of this shift; A good example from the 70s, the level of 'engineering' driving the design of the vehicle and it's assembly didn't take into consideration the actual line worker; in Ohio the workers wound up getting overworked, burned out, and in some cases actively sabotaged the product, because they were being treated like automated machines.

that_guy_iain 6y ago

> That sort of crap is the reason we host all our stuff on root servers. Having just started my own journey into building products for myself, pretty much the first thing I realised with my tech was I need to get dedicated servers instead of cloud just because it costs 100x less. > Just grab a dedicated server for a few bucks and put a bunch of docker containers on those. Exactly, if you really want kubernetes coolness to act cloud like, install kubernetes it's free and is super easy to setup. And with the cost savings you can literally buy multiple spare servers and with kubernetes using them all while keeping the usage low allowing to scale up new nodes if needed.

throwaway201103 6y ago
> kubernetes ... is super easy to setup Can you point me to the super easy setup guide? Because I've tried a few and never gotten it working.
- WrtCdEvrydy 6y ago
  I don't like use kubernetes raw but I am a fan of Caprover (which has kubernetes support)
- AntiImperialist 6y ago
  Canonical has microk8s, which you can install as a snap package. Super simple and works great.
- styren 6y ago
  Have a look at https://github.com/hobby-kube/guide https://github.com/hobby-kube/guide I set up a 3 node cluster using it in an afternoon and haven't had any problems since.

croh 6y ago

> Most apps don't need scaling anyway and if you do, just put that app on bare metal fitting your requirements. Most important !

Aperocky 6y ago

> Most apps don't need scaling anyway This is exactly right. I host stuff in buckets/cloudfront and uses a bit of lambda/route53. I end up paying $4 a month. now that will be very different if 10 million people suddenly decide to visit my site, but if that happens money probably won't be a problem after all.

vmception 6y ago

> Most apps don't need scaling anyway and if you do Man, exactly right. Many of guys here would love crypto once you stop asking why and start asking how. The most lucrative projects these days are completely frontend UI, they don't even their own backends they as just read state from the nearest node when the client connects their wallet. Some people forgot that the scalability game was to convert traffic into money. So ditch that, and remember you are in the money game.

joshmanders 6y ago

> Even trying to read the amazon pricing for their instances, hours and what not, drives me insane. I get your sentiment but the pricing is that way because they want to charge you exactly what you use, not for reserving stuff. For example if you deploy a EC2 instance that comes out to be $15/mo total, and you deploy it on say the 10th of the month, do you want to be charged the whole $15? No, you want pro-rated.. But what if you only need that instance for like 6 days? Then what? You gonna do the math to figure out what it would have cost you yourself, or just read it per hour billing?