15 ms·

For anyone who's not used these "managed" services before, I want to add that it's still a fuck ton of work. The work shifts from "keeping X server running" to

For anyone who's not used these "managed" services before, I want to add that it's still a fuck ton of work. The work shifts from "keeping X server running" to "how do I begin to configure and tune this service". You will run into performance issues, config gotchas, voodoo tuning, and maintenance concerns with any of AWS's managed databases or k8s. > I'll pay Amazon $N/month to do that for me Until you pay Amazon $N/month to provide the service, and then another $M/month to a human to manage it for you.

maxxxxx 8y ago
"For anyone who's not used these "managed" services before, I want to add that it's still a fuck ton of work. The work shifts from "keeping X server running" to "how do I begin to configure and tune this service"." I have noticed that too. With some managed services you are trading a set of generally understood problems with a lot of quirky behavior of the service that's very hard to debug.
- erikpukinskis 8y ago
  Yes, but I think very broadly speaking the quirky behavior is stuff you bump into, learn about, fix, and then can walk away from. The daily/monthly maintenance cycle on a self hosted SQL server is “generally understood” but you still have to wake up, check your security patches, and monitor your redeployments. You can do some of that in an automated fashion with public security updates for your containers and such. But if monitoring detects an anomaly, it’s YOU, not Heroku who gets paged. It’s a little like owning a house vs renting. Yes if you rent you have to work around the existing building, and getting small things fixed is a process. But if the pipes explode, you make a phone call and it’s someone else’s problem. You didn’t eliminate your workload, but you shrunk the domain you need to personally be on call for.
  - forty 8y ago
    It's someone else problem unless it prevents you from living here, in which case it's still your problem too. I think the analogy works quite well :)
  - deleted 8y ago
    [deleted]
  - maxxxxx 8y ago
    The problem is that if I run my own servers I can fix problems (maybe with a lot of effort but at least it can be done) but with managed services I may not be able to do so. There is a lot of value in managed services but you have to be careful not to allow them to eat up your project with their bugs/quirks.
    - diminoten 8y ago
      The point is with a managed service, none of your problems will be with the service. That's what the managed service is selling.
      - maxxxxx 8y ago
        That's the promise but in reality every software has bugs, including managed services.
        diminoten 8y ago
        Not really, not anything like what you're describing. 12 outages since 2011, and none of them are anything like what you're describing: https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Services https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
        bsagdiyev 8y ago
        We've moved from on-prem to AWS fully and we see random issues all the time while their status page shows all green, so I feel you probably have a small amount of resources in use with them or something, because what you're saying doesn't jive with what we see daily. I see you've also copy-pasted your response to other comments too, so I'll do the same with my response.
        diminoten 8y ago
        I don't feel like copy/pasting all of our comments to each other, so I'd appreciate it if you didn't do that, thanks.
- dfee 8y ago
  But you’re talking about a reduction in the number of types of specialized people to the number of specializations per type of person. That makes this more scalable.
- grigjd3 8y ago
  So I've worked with AWS and with our internal clusters as a dev. My experience has been that I have to make work-arounds for both, but at least with AWS, I don't have to spell out commands explicitly to the junior PEs. EDIT: I should be clear, our PEs are generally pretty good, but because their product isn't seen by upper management as the thing which makes money, they're perpetually understaffed.
  - Macha 8y ago
    Also Amazon documents their stuff in a nice public website, internal teams documented the n-2 iteration of the system and have change notes hidden in a Google drive somewhere that if you ask the right person on the other side of the world they might be able to share you a link to.
    - grigjd3 8y ago
      You were able to find documentation? Where do you work?
    - pm90 8y ago
      This. So. Much. I can't explain just how much developing on GCP has helped me simply by having such amazing documentation. I don't think I appreciated how little I knew: every company where we worked with on premise/ internal services, we would have to use custom services built by others. With GCP, you have complete freedom, not just to design your application architecture from scratch, but to understand how others (coworkers mostly) have designed _their_ applications too! And as a company, it allows the sharing of a common set of best practices, automatically, since its "recommended by Google". Its kinda like Google/Amazon are now the System/Operations engineers for our company. Which they're good at. And its awesome.
Animats 8y ago
When you buy a service from a big company, and it doesn't work, you get to debug the service.
- Scarbutt 8y ago
  I guess that's his point, you are not doing less work, all you did was moved your debugging from one place to another.
  - kingraoul3 8y ago
    And let's not forget! Got a support contract so we can all BLAME someone not in the room and feel good.
- kingraoul3 8y ago
  Which is exactly why everything runs Linux instead of Windows.
sokoloff 8y ago
Then you pay $O/month for AWS Enterprise Support (who are actually quite good and helpful) to help augment your $M/month employees and $N/month direct spend.
- milquetoastaf 8y ago
  Support - in the long run - is pretty cheap (I think I pay around 300) and 100 percent worth the tradeoff. The web chat offers the fastest resolution times in my experience once you are out of the queue
rlander 8y ago
Exactly. There's no silver bullet, only trade offs. In this case you're only shifting the complexity from "maintaining" to "orchestrating". "Maintaining" means you build (in a semi-automated way) once and most of your work is spent keeping the services running. In the latter, you spend most of your time building the "orchestration" and little time maintaining. If your product is still small, it makes sense to keep most of your infrastructure in "maintaining" since the number of services is small. As the product grows (and your company starts hiring ops people), you can slowly migrate to "orchestrating".
- diminoten 8y ago
  The costs associated with "maintaining" usually involve the possibility of a 3am call for whoever is in charge of maintaining. Orchestrating can be done ahead of time, during your 9-5, and that's super valuable. It's still a lot of work, but it's work that can be done on my time, at my pace.
  - throwaway2048 8y ago
    Managed services still have plenty of unexplained goings-on, and 3AM pages.
    - diminoten 8y ago
      Said like a person who hasn't actually ever converted. It's nothing like that at all. 12 outages since 2011, and none of them are anything like what you're describing: https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Services https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
      - bsagdiyev 8y ago
        We've moved from on-prem to AWS fully and we see random issues all the time while their status page shows all green, so I feel you probably have a small amount of resources in use with them or something, because what you're saying doesn't jive with what we see daily. I see you've also copy-pasted your response to other comments too.
brobdingnagians 8y ago
The general fact of reality is that if you are building anything technical, then knowing and managing the details, whatever the details are, will get you a lot more bang for your buck. Reality isn't just a garden variety one-size fits all kind of thing, so creating something usually isn't either. If you just want a blog like everyone else's, then that comes packaged, but if you want something special, you will always have to put in the expertise.
- luckylion 8y ago
  > will get you a lot more bang for your buck And it _really_ is a lot. A company I work with switched from running two servers with failover to AWS, bills went from ~€120/m to ~€2.2k/m for a similar work load. Granted, nobody has to manage those servers any more, but if that price tag continues to rise that way, it's going to be much cheaper to have somebody dedicated to manage those servers vs use AWS. Also, maybe that's just me, but I prefer to have the knowledge in my team. If everything runs on AWS, I'm at the mercy of Amazon.
  - dodobirdlord 8y ago
    Holy cow, that's nuts. A pair of perfectly webservers (m5.xlarge) comes in at ~€250/m. And cheaper if you get reserved instances. ~€2.2k/m for a pair of instances and maybe a load balancer is incredible!
    - luckylion 8y ago
      It is, especially when they are running a lot of base load, so it's not about firing up 20 nodes for an hour and then idling along on one node for the rest of the week. "We'd rather not manage the database ourselves" was the answer from the lead dev, and I do understand that: it's not the developers' job to manage servers. In this company, management has removed themselves from anything technical and the devs don't like managing servers, so they say "let's use AWS, we'll write some code once to create our environment and Amazon takes care of the rest" - and by this point they are committed, with months having been spent on getting things running on AWS, changing the code where necessary etc, so reversing it would be a hard thing to sell to investors and the team.
cik 8y ago
Bang on. Realistically the value of Amazon's managed side is in the early stages. At latter stages with people, it's significantly lower cost to tune real resources, and you get added performance benefits. We make a decent business out of doing just this, at scale for clients today.
- rashkov 8y ago
  Would love to hear more about that business — do you help people go from cloud back to on-prem?
  - cik 8y ago
    We're all about mixed mode. Let's never pretend that we ought focus on a specific one and only business. Clients like Amazon, clients like Azure - clients then get forced by (say the BC Health Authority) to run on physical machines in a British Columbia hosted datacenter. We help make that happen, and help folks manage the lifecycle associated with it.
  - user5994461 8y ago
    Companies just really suck at managing hardware or resources. The bigger and the more consultants they get, the more terrible they get, that's what you come after. Chances are you will find tens of instances without any naming or tagging, of the more expensive types, created by previous dudes who long left. Thanks to AWS tooling it's easy to identify them, see if they use any resource and either delete or scale down dramatically.
    - cik 8y ago
      It's not a size thing - it's all companies, and it's about significantly more than just 'finding instances'. The 'finding instances' side of AWS is something we just do for free (AWS, Azure, etc) for our existing customers. Our goal is to provide actual value and do real DevOps work, regardless of whether you're AWS, Azure, GCP, etc. This includes physical, mixed-mode, cloud bursting, and changing constantly. <----- That's what keeps it interesting.
- 8y ago
staticassertion 8y ago
That doesn't sound like a shift of work. It sounds like work I already would have done - performance tuning doesn't go away by bringing things in house. Now that person I pay to operate the service can focus on tuning, not backups and other work that's been automated away. Sounds like a massive win to me.
- opportune 8y ago
  It does make performance tuning harder since you likely don't have access to the codebase of the managed service, requiring more trial-and-error or just asking someone on the support team ($$)
ibejoeb 8y ago
Yes, but it's still pretty much a straight cost offset. If you hold your own metal, you have to do all of that and still administer the database. Sure, there could be a little overlap in storage design, nut most of the managed systems have typical operational concerns at a button click: backup, restore, HA... Unless your fleet is huge and your workload is special, you're going to win with managed services.
- Scarbutt 8y ago
  If you hold your own metal That's going too much to the other extreme, ec2, droplets, etc.. are fine.
- late2part 8y ago
  define huge?
  - dodobirdlord 8y ago
    Bigger than Netflix, assuming that you don't know something that Netflix doesn't.
Rapzid 8y ago
Yeah, I think it's a trade off. Certain services can be a no-brainer, but others will cause pain if your particular use case doesn't align precisely with the service's strengths and limitations. DynamoDB vs RDS is a perfect example. Most of that boils down to the typical document store and lack of transactions challenges. God forbid you start with DynamoDB and then discover you really need a transnational unit of work, or you got your indexes wrong the first time around. If you didn't need the benefits of DynamoDB in the first place, you will be wishing you just went with a traditional RDBMS vs RDS to start with. Lambda can be another mixed bag. It can be a PITA to troubleshoot, and their are a lot of gotchas like execution time limits, storage limits, cold start latency, and so on. But once you invested all the time getting everything setup, wired up... In for a penny, in for a pound.
- aaronblohowiak 8y ago
  This was announced in nov, i think: https://aws.amazon.com/blogs/aws/new-amazon-dynamodb-transactions/ https://aws.amazon.com/blogs/aws/new-amazon-dynamodb-transac...
thatoneuser 8y ago
That's no joke. I have a decent software background and it was far from trivial to get going with aws services. Their documentation doesn't always quite tel you everything you need to know and half thhe time there are conflicting docs both saying to do something that's wrong. Still has been less work than a production server at my last engineering job but then again that project had a lot of issues related to age and shitty code bases. Hard to say which would have been less work honestly.
taeric 8y ago
To be fair, this is only a valid shift for folks moving. If you are creating something, you have both "how do I configure" and "how do I keep it moving?" That is, the shift to managed services does largely remove a large portion, and just changes another.
scarface74 8y ago
He specifically mentioned Dynamo. There is nothing to configure except indexes, and read and write capacity units.
dsfyu404ed 8y ago
And a lot of the time keeping X running is simpler than configuring and tuning this service.
stickfigure 8y ago
If your "managed services" are a ton of work, then they're not really managed. I built a system selling and fulfilling 15k tshirts/day on Google App Engine using (what is now called) the Cloud Datastore. The programming limitations are annoying (it's useless for analytics) but it was rock solid reliable, autoscaled, and completely automated. Nobody wore a pager, and sometimes the entire team would go camping. You simply cannot get that kind of stress-free life out of a traditional RDBMS stack.
- mijamo 8y ago
  If anything I had much more troubles with the datastore than with any other DB ever. We are migrating away and the day it's over will be thz biggest profesional relief I've experienced. I guess you coule consider that you don't need to manage it, but the trade off is that you have to go around all the limitations through nasty software hacks instead of just a simple configuration.
  - ngrilly 8y ago
    Regarding Google Cloud Datastore, what kind of limitations have you met?
  - stickfigure 8y ago
    I also am curious to know what sorts of problems you've had. I have noticed that people tend to get into trouble when they force the datastore to be something it's not. For example, I mentioned that it's terrible for analytics - there are no aggregation queries. In the case of the tshirt retailer, I replicated a portion of our data into a database that was good for analytics (postgres, actually). We could afford to lose the analytics dashboard for a few hours due to a poorly tested migration (and did, a few times), but the sales flow never went down. The datastore is not appropriate for every project (which echoes the original article) but it's a good tool when used appropriately.
    - spyspy 8y ago
      It definitely sounds like they shouldn't have used datastore in the first place if it's giving them that much trouble. A common pattern we use is to replicate the data in bigquery, either by stream or batch job that flows over pubsub - perfectly scalable and resilient to failure.
zaarn 8y ago
>You will run into performance issues, config gotchas, voodoo tuning, and maintenance concerns with any of AWS's managed databases or k8s. The default config for a LAMP stack will easily handle 100 requests per second. 10 if you app isn't optimized. Run apt upgrade once a month and enable automatic security updates on ubuntu. That is neither hard nor "vodoo". I've used managed services and I don't see the point until you hit massive scale, at which point you can afford to hire your engineers to do it.
kokey 8y ago
What really bugs me about this is that it reminds me of the dotcom days. Microsoft ASP stacks made it easier to find less experienced developers to quickly develope sites, no one having an awareness of optimisation and instead would throw hardware at it. Large clusters of DEC Alpha servers would handle the same amount of traffic as a single FreeBSD on a PC, but this cost difference wasn't a problem when investor cash flowed easily and shifting Microsoft and Cisco products fed into the revenues of the system integrators which was fine since revenue growth mattered more than profits. I've seen this with many AWS deployments, which on a pure hardware cost is 3-5 times more, but with the way it makes it 'easy' to scale instead of optimise instead costs 10-20 times more. When the investor cash starts drying up and the focus is going to be on competing for profits in a market that is much smaller in general, many organisations are going to find themselves locked into AWS and for them it's going to feel like IE6 and asp.net all over again.
- jtdev 8y ago
  Same goes for J2EE, Flash, and a bunch of other technologies. Your focus on ASP.NET seems rather biased.
  - int_19h 8y ago
    I don't think you could describe J2EE as "made it easier to find less experienced developers to quickly develop sites". If anything, it's diametrically opposed to that goal. And back in dotcom days, it was ASP, not ASP.NET. Which is to say, much like PHP, except with VBScript as a language, and COM as a library API/ABI.

maxxxxx 8y ago

"For anyone who's not used these "managed" services before, I want to add that it's still a fuck ton of work. The work shifts from "keeping X server running" to "how do I begin to configure and tune this service"." I have noticed that too. With some managed services you are trading a set of generally understood problems with a lot of quirky behavior of the service that's very hard to debug.

erikpukinskis 8y ago
Yes, but I think very broadly speaking the quirky behavior is stuff you bump into, learn about, fix, and then can walk away from. The daily/monthly maintenance cycle on a self hosted SQL server is “generally understood” but you still have to wake up, check your security patches, and monitor your redeployments. You can do some of that in an automated fashion with public security updates for your containers and such. But if monitoring detects an anomaly, it’s YOU, not Heroku who gets paged. It’s a little like owning a house vs renting. Yes if you rent you have to work around the existing building, and getting small things fixed is a process. But if the pipes explode, you make a phone call and it’s someone else’s problem. You didn’t eliminate your workload, but you shrunk the domain you need to personally be on call for.
- forty 8y ago
  It's someone else problem unless it prevents you from living here, in which case it's still your problem too. I think the analogy works quite well :)
- deleted 8y ago
  [deleted]
- maxxxxx 8y ago
  The problem is that if I run my own servers I can fix problems (maybe with a lot of effort but at least it can be done) but with managed services I may not be able to do so. There is a lot of value in managed services but you have to be careful not to allow them to eat up your project with their bugs/quirks.
  - diminoten 8y ago
    The point is with a managed service, none of your problems will be with the service. That's what the managed service is selling.
    - maxxxxx 8y ago
      That's the promise but in reality every software has bugs, including managed services.
      - diminoten 8y ago
        Not really, not anything like what you're describing. 12 outages since 2011, and none of them are anything like what you're describing: https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Services https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
        bsagdiyev 8y ago
        We've moved from on-prem to AWS fully and we see random issues all the time while their status page shows all green, so I feel you probably have a small amount of resources in use with them or something, because what you're saying doesn't jive with what we see daily. I see you've also copy-pasted your response to other comments too, so I'll do the same with my response.
        diminoten 8y ago
        I don't feel like copy/pasting all of our comments to each other, so I'd appreciate it if you didn't do that, thanks.
dfee 8y ago
But you’re talking about a reduction in the number of types of specialized people to the number of specializations per type of person. That makes this more scalable.
grigjd3 8y ago
So I've worked with AWS and with our internal clusters as a dev. My experience has been that I have to make work-arounds for both, but at least with AWS, I don't have to spell out commands explicitly to the junior PEs. EDIT: I should be clear, our PEs are generally pretty good, but because their product isn't seen by upper management as the thing which makes money, they're perpetually understaffed.
- Macha 8y ago
  Also Amazon documents their stuff in a nice public website, internal teams documented the n-2 iteration of the system and have change notes hidden in a Google drive somewhere that if you ask the right person on the other side of the world they might be able to share you a link to.
  - grigjd3 8y ago
    You were able to find documentation? Where do you work?
  - pm90 8y ago
    This. So. Much. I can't explain just how much developing on GCP has helped me simply by having such amazing documentation. I don't think I appreciated how little I knew: every company where we worked with on premise/ internal services, we would have to use custom services built by others. With GCP, you have complete freedom, not just to design your application architecture from scratch, but to understand how others (coworkers mostly) have designed _their_ applications too! And as a company, it allows the sharing of a common set of best practices, automatically, since its "recommended by Google". Its kinda like Google/Amazon are now the System/Operations engineers for our company. Which they're good at. And its awesome.

Animats 8y ago

When you buy a service from a big company, and it doesn't work, you get to debug the service.

Scarbutt 8y ago
I guess that's his point, you are not doing less work, all you did was moved your debugging from one place to another.
- kingraoul3 8y ago
  And let's not forget! Got a support contract so we can all BLAME someone not in the room and feel good.
kingraoul3 8y ago
Which is exactly why everything runs Linux instead of Windows.

sokoloff 8y ago

Then you pay $O/month for AWS Enterprise Support (who are actually quite good and helpful) to help augment your $M/month employees and $N/month direct spend.

milquetoastaf 8y ago
Support - in the long run - is pretty cheap (I think I pay around 300) and 100 percent worth the tradeoff. The web chat offers the fastest resolution times in my experience once you are out of the queue

rlander 8y ago

Exactly. There's no silver bullet, only trade offs. In this case you're only shifting the complexity from "maintaining" to "orchestrating". "Maintaining" means you build (in a semi-automated way) once and most of your work is spent keeping the services running. In the latter, you spend most of your time building the "orchestration" and little time maintaining. If your product is still small, it makes sense to keep most of your infrastructure in "maintaining" since the number of services is small. As the product grows (and your company starts hiring ops people), you can slowly migrate to "orchestrating".

diminoten 8y ago
The costs associated with "maintaining" usually involve the possibility of a 3am call for whoever is in charge of maintaining. Orchestrating can be done ahead of time, during your 9-5, and that's super valuable. It's still a lot of work, but it's work that can be done on my time, at my pace.
- throwaway2048 8y ago
  Managed services still have plenty of unexplained goings-on, and 3AM pages.
  - diminoten 8y ago
    Said like a person who hasn't actually ever converted. It's nothing like that at all. 12 outages since 2011, and none of them are anything like what you're describing: https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Services https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
    - bsagdiyev 8y ago
      We've moved from on-prem to AWS fully and we see random issues all the time while their status page shows all green, so I feel you probably have a small amount of resources in use with them or something, because what you're saying doesn't jive with what we see daily. I see you've also copy-pasted your response to other comments too.

brobdingnagians 8y ago

The general fact of reality is that if you are building anything technical, then knowing and managing the details, whatever the details are, will get you a lot more bang for your buck. Reality isn't just a garden variety one-size fits all kind of thing, so creating something usually isn't either. If you just want a blog like everyone else's, then that comes packaged, but if you want something special, you will always have to put in the expertise.

luckylion 8y ago
> will get you a lot more bang for your buck And it _really_ is a lot. A company I work with switched from running two servers with failover to AWS, bills went from ~€120/m to ~€2.2k/m for a similar work load. Granted, nobody has to manage those servers any more, but if that price tag continues to rise that way, it's going to be much cheaper to have somebody dedicated to manage those servers vs use AWS. Also, maybe that's just me, but I prefer to have the knowledge in my team. If everything runs on AWS, I'm at the mercy of Amazon.
- dodobirdlord 8y ago
  Holy cow, that's nuts. A pair of perfectly webservers (m5.xlarge) comes in at ~€250/m. And cheaper if you get reserved instances. ~€2.2k/m for a pair of instances and maybe a load balancer is incredible!
  - luckylion 8y ago
    It is, especially when they are running a lot of base load, so it's not about firing up 20 nodes for an hour and then idling along on one node for the rest of the week. "We'd rather not manage the database ourselves" was the answer from the lead dev, and I do understand that: it's not the developers' job to manage servers. In this company, management has removed themselves from anything technical and the devs don't like managing servers, so they say "let's use AWS, we'll write some code once to create our environment and Amazon takes care of the rest" - and by this point they are committed, with months having been spent on getting things running on AWS, changing the code where necessary etc, so reversing it would be a hard thing to sell to investors and the team.

cik 8y ago

Bang on. Realistically the value of Amazon's managed side is in the early stages. At latter stages with people, it's significantly lower cost to tune real resources, and you get added performance benefits. We make a decent business out of doing just this, at scale for clients today.

rashkov 8y ago
Would love to hear more about that business — do you help people go from cloud back to on-prem?
- cik 8y ago
  We're all about mixed mode. Let's never pretend that we ought focus on a specific one and only business. Clients like Amazon, clients like Azure - clients then get forced by (say the BC Health Authority) to run on physical machines in a British Columbia hosted datacenter. We help make that happen, and help folks manage the lifecycle associated with it.
- user5994461 8y ago
  Companies just really suck at managing hardware or resources. The bigger and the more consultants they get, the more terrible they get, that's what you come after. Chances are you will find tens of instances without any naming or tagging, of the more expensive types, created by previous dudes who long left. Thanks to AWS tooling it's easy to identify them, see if they use any resource and either delete or scale down dramatically.
  - cik 8y ago
    It's not a size thing - it's all companies, and it's about significantly more than just 'finding instances'. The 'finding instances' side of AWS is something we just do for free (AWS, Azure, etc) for our existing customers. Our goal is to provide actual value and do real DevOps work, regardless of whether you're AWS, Azure, GCP, etc. This includes physical, mixed-mode, cloud bursting, and changing constantly. <----- That's what keeps it interesting.
8y ago

staticassertion 8y ago

That doesn't sound like a shift of work. It sounds like work I already would have done - performance tuning doesn't go away by bringing things in house. Now that person I pay to operate the service can focus on tuning, not backups and other work that's been automated away. Sounds like a massive win to me.

opportune 8y ago
It does make performance tuning harder since you likely don't have access to the codebase of the managed service, requiring more trial-and-error or just asking someone on the support team ($$)

ibejoeb 8y ago

Yes, but it's still pretty much a straight cost offset. If you hold your own metal, you have to do all of that and still administer the database. Sure, there could be a little overlap in storage design, nut most of the managed systems have typical operational concerns at a button click: backup, restore, HA... Unless your fleet is huge and your workload is special, you're going to win with managed services.

Scarbutt 8y ago
If you hold your own metal That's going too much to the other extreme, ec2, droplets, etc.. are fine.
late2part 8y ago
define huge?
- dodobirdlord 8y ago
  Bigger than Netflix, assuming that you don't know something that Netflix doesn't.

Rapzid 8y ago

Yeah, I think it's a trade off. Certain services can be a no-brainer, but others will cause pain if your particular use case doesn't align precisely with the service's strengths and limitations. DynamoDB vs RDS is a perfect example. Most of that boils down to the typical document store and lack of transactions challenges. God forbid you start with DynamoDB and then discover you really need a transnational unit of work, or you got your indexes wrong the first time around. If you didn't need the benefits of DynamoDB in the first place, you will be wishing you just went with a traditional RDBMS vs RDS to start with. Lambda can be another mixed bag. It can be a PITA to troubleshoot, and their are a lot of gotchas like execution time limits, storage limits, cold start latency, and so on. But once you invested all the time getting everything setup, wired up... In for a penny, in for a pound.

aaronblohowiak 8y ago
This was announced in nov, i think: https://aws.amazon.com/blogs/aws/new-amazon-dynamodb-transactions/ https://aws.amazon.com/blogs/aws/new-amazon-dynamodb-transac...

thatoneuser 8y ago

That's no joke. I have a decent software background and it was far from trivial to get going with aws services. Their documentation doesn't always quite tel you everything you need to know and half thhe time there are conflicting docs both saying to do something that's wrong. Still has been less work than a production server at my last engineering job but then again that project had a lot of issues related to age and shitty code bases. Hard to say which would have been less work honestly.

taeric 8y ago

To be fair, this is only a valid shift for folks moving. If you are creating something, you have both "how do I configure" and "how do I keep it moving?" That is, the shift to managed services does largely remove a large portion, and just changes another.

scarface74 8y ago

He specifically mentioned Dynamo. There is nothing to configure except indexes, and read and write capacity units.

dsfyu404ed 8y ago

And a lot of the time keeping X running is simpler than configuring and tuning this service.

stickfigure 8y ago

If your "managed services" are a ton of work, then they're not really managed. I built a system selling and fulfilling 15k tshirts/day on Google App Engine using (what is now called) the Cloud Datastore. The programming limitations are annoying (it's useless for analytics) but it was rock solid reliable, autoscaled, and completely automated. Nobody wore a pager, and sometimes the entire team would go camping. You simply cannot get that kind of stress-free life out of a traditional RDBMS stack.

mijamo 8y ago
If anything I had much more troubles with the datastore than with any other DB ever. We are migrating away and the day it's over will be thz biggest profesional relief I've experienced. I guess you coule consider that you don't need to manage it, but the trade off is that you have to go around all the limitations through nasty software hacks instead of just a simple configuration.
- ngrilly 8y ago
  Regarding Google Cloud Datastore, what kind of limitations have you met?
- stickfigure 8y ago
  I also am curious to know what sorts of problems you've had. I have noticed that people tend to get into trouble when they force the datastore to be something it's not. For example, I mentioned that it's terrible for analytics - there are no aggregation queries. In the case of the tshirt retailer, I replicated a portion of our data into a database that was good for analytics (postgres, actually). We could afford to lose the analytics dashboard for a few hours due to a poorly tested migration (and did, a few times), but the sales flow never went down. The datastore is not appropriate for every project (which echoes the original article) but it's a good tool when used appropriately.
  - spyspy 8y ago
    It definitely sounds like they shouldn't have used datastore in the first place if it's giving them that much trouble. A common pattern we use is to replicate the data in bigquery, either by stream or batch job that flows over pubsub - perfectly scalable and resilient to failure.

zaarn 8y ago

>You will run into performance issues, config gotchas, voodoo tuning, and maintenance concerns with any of AWS's managed databases or k8s. The default config for a LAMP stack will easily handle 100 requests per second. 10 if you app isn't optimized. Run apt upgrade once a month and enable automatic security updates on ubuntu. That is neither hard nor "vodoo". I've used managed services and I don't see the point until you hit massive scale, at which point you can afford to hire your engineers to do it.

kokey 8y ago

What really bugs me about this is that it reminds me of the dotcom days. Microsoft ASP stacks made it easier to find less experienced developers to quickly develope sites, no one having an awareness of optimisation and instead would throw hardware at it. Large clusters of DEC Alpha servers would handle the same amount of traffic as a single FreeBSD on a PC, but this cost difference wasn't a problem when investor cash flowed easily and shifting Microsoft and Cisco products fed into the revenues of the system integrators which was fine since revenue growth mattered more than profits. I've seen this with many AWS deployments, which on a pure hardware cost is 3-5 times more, but with the way it makes it 'easy' to scale instead of optimise instead costs 10-20 times more. When the investor cash starts drying up and the focus is going to be on competing for profits in a market that is much smaller in general, many organisations are going to find themselves locked into AWS and for them it's going to feel like IE6 and asp.net all over again.

jtdev 8y ago
Same goes for J2EE, Flash, and a bunch of other technologies. Your focus on ASP.NET seems rather biased.
- int_19h 8y ago
  I don't think you could describe J2EE as "made it easier to find less experienced developers to quickly develop sites". If anything, it's diametrically opposed to that goal. And back in dotcom days, it was ASP, not ASP.NET. Which is to say, much like PHP, except with VBScript as a language, and COM as a library API/ABI.