17 ms·

AWS staff spending ‘much of their time ’optimizing customers' clouds'

254 points by MISTERJerk2U 3y ago

echelon 3y ago
Use vanilla products (K8S, "RDS", ...) so you can always dangle the threat of going on-prem or to another cloud provider. Once you use Lambdas and other deep AWS product, you're locked in.
- master_crab 3y ago
  You could use containerized lambdas. Your application logic would be mostly safe to migrate around as need be. But then again, migrating from one cloud to another is always a heavy lift no matter how it’s constructed.
  - vidarh 3y ago
    Having done zero downtime migration from AWS to Google to managed servers (chasing credits, and then moving to Hetzner when the credits ran out): it's not much heavy lifting if you treat each cloud provider as just providing raw compute and storage resources.
    - jamsauceismad 3y ago
      It's because you did the heavy lifting up front with how your application is designed and how your infra is provisioned (I'm guessing everything is terraformed or something?).
      - sleepybrett 3y ago
        Also a great unlock if you do the bulk of your work in kubernetes. Amazon is certainly doing some things in their kube implementation that will make moving suck more (karpenter, some of their other integrations) in an effort to be better and thus sticky... But it's still pretty easy to go from one kube cluster to another.
      - vidarh 3y ago
        Everything in Docker containers + a service discovery layer (Consul on that particular case) will get you most of the way there as long as you don't get seduced into relying on cloud specific services.
        scarface74 3y ago
        And then you’re managing Consul clusters (been there done that).
        vidarh 3y ago
        I never found that a problem. Consul was robust when I used it.
  - croddin 3y ago
    With the lambda web adapter[1], you shouldn't need to make any code changes for web projects, just some dockerfile changes which are only used if it is running as a lambda, so the same image should still work on ecs or another cloud. [1]https://github.com/awslabs/aws-lambda-web-adapter https://github.com/awslabs/aws-lambda-web-adapter
- deleted 3y ago
  [deleted]
- sarathyweb 3y ago
  If possible can you suggest me a lof vanilla products. My team is building a platform that allows anyone to spinup instances on any cloud platform. We’re planning to add support for DNS management ( Route53, Google cloud DNS& Azure DNS) and storage buckets
  - potta_coffee 3y ago
    Just what we need, another platform.
- tyingq 3y ago
  I don't personally feel like Lambdas themselves are the hard lock-in. It's the stuff around them that really gets into your code or forces specific patterns. SQS, SNS, Dynamo, Kinesis, EventBridge, etc.
  - preommr 3y ago
    Which frankly are the essential parts of a robust cloud architecture. Deploying a server is trivial - just dump it on any kind of compute resource. Managing fault-tolerance and monitoring, etc. between those services is the tricky part.
    - mschuster91 3y ago
      IME, not if you're using Terraform with proper modularization and can stick to the commonly available feature set. Have one layer of modules that describe what you want (e.g. a virtual server, database, monitoring) and behind that a separate layer that implements it (e.g. creates an EC2 instance, an RDS database or a CloudWatch alert).
      - scarface74 3y ago
        Terraform is not “cloud agnostic” anymore than using Python with the various cloud providers SDKs. Each provider within TF is tied tightly with the cloud provider. Standard Disclaimer: yes I work at AWS and I do IAC with the CloudFormation or TF depends on what the customer wants
      - Karunamon 3y ago
        That's a nonstarter just because of how you describe the various services at each cloud provider. For instance, Google cloud is big into using "projects" as organizers for resources, where the closest analogue in AWS land is an entirely separate account.
  - throwawayx35fw 3y ago
    In my opinion, SQS shouldn't be on that list. You save a lot of time and resources just using SQS instead of setting up your own servers. And the lock-in is not as problematic as Lambdas etc. It doesn't require much code change to move to an alternative message queue (RabbitMQ etc.), so the lock-in is minimal. In my projects, I just need to change a few lines of configuration code and the actual message processing code should remain the same.
- roncesvalles 3y ago
  I don't see much difference in vendor lock-in between EKS and Lambda. The abstraction between your Kubernetes application and the underlying platform isn't airtight.
- deleted 3y ago
  [deleted]
- hnlmorg 3y ago
  In my experience writing cloud agnostic infra usually ends up more costlier. Not just in monetary terms running the infrastructure, but also in terms of time spent maintaining the infrastructure. There’s generally very little point using the cloud if you’re not going to use cloud services.
  - aeyes 3y ago
    If all you need is machines then there is still a massive benefit in using the cloud. You can spin up 1000 machines tomorrow without having to buy them, wait for getting them (2 months later), rack them, cable them, .... Especially if you need a couple of racks things get complicated quickly. If you have never racked machines for a week you probably underestimate the amount of time it takes before you can actually run workloads on them. And if you need a 1000 machines for x years which otherwise you'd put in your own data center you can absolutely go to AWS, GCP, OCI and bid them down against each other.
    - hnlmorg 3y ago
      > If all you need is machines then there is still a massive benefit in using the cloud. “massive” is an overstatement. “some” would be more accurate. And your example is correct, which is why I said “generally” in my post rather than “always” or “never”. In fact my current project is using AWS in exactly the way you described. > If you have never racked machines I have done. Many times. :) And there are ways you can get machines at short notice without going down the AWS route. In fact it’s actually pretty easy and used to be really common. I used to use all sorts of different VPS and dedicated hosting for personal projects (while managing on prem stuff professionally). These days a lot of those bigger companies are now just wrapped up as part of “cloud services” but there are still some smaller providers out there doing things old school. In fact I have a few GFX cards for machine learning in a London data centre managed by one such independent provider. > And if you need a 1000 machines for x years which otherwise you'd put in your own data center you can absolutely go to AWS, GCP, OCI and bid them down against each other. You’re now talking about cost optimisation and commitment-based discounts, which is a whole other tangent. Anyways, my point wasn’t that the cloud is more or less expensive than on prem. it was that designing your cloud architecture to be cloud agnostic is more expensive and rarely worthwhile compared with making use of the services offered by whichever cloud provider you’re using.
mooreds 3y ago
Not just their "clouds" but their "cloud spend". From the article: > Amazon Web Services sales and support teams are currently “spending much of their time helping customers optimize their AWS spend so they can better weather this uncertain economy.”
- deleted 3y ago
  [deleted]
- gatvol 3y ago
  No doubt by pushing the clients to use inappropriate vendor-locky-in serverless tech stacks that are inappropriate for the workloads.
samstave 3y ago
Personally, this is what I expect of them, specifically for smaller orgs that don't have CISO, SRE or other ops folks needed. Now, I'm not saying this should be the expected behavior for everyone or every situation, but "aws staff spends majority of time doing what aws staff is hired and skilled to do" Seems pretty "cost of doing business" to me
- neves 3y ago
  I think that this consumer oriented facet of Amazon is impressive. No other provider will dedicate this time to clients.
  - hanselot 3y ago
    I can make a similar argument regarding Jehova's witnesses.
    - samstave 3y ago
      Guys! We have another ~~Linux~~ Zealot over here!
  - mschuster91 3y ago
    Oh, I have had good experiences with German providers Manitu and Corpex. Very good service, although the latter almost exclusively deals in managed hosting.
boesboes 3y ago
They still have plenty of time to cripple their UI though
- sebazzz 3y ago
  What? The AWS UI is much better than that slow ever-slowing-progress-bars RandomError throwing Azure portal.
  - edgyquant 3y ago
    Just because there are worse things doesn’t mean the current interface doesn’t suck
    - hot_gril 3y ago
      It does kinda mean that if everything else is worse.
  - SketchySeaBeast 3y ago
    That's funny - I primarily have used Azure but whenever I drop into AWS I feel like it's actively punishing me for trying to use the UI.
    - mardifoufs 3y ago
      Azure UI is awful for stuff like hitting the back button and reliably going back, or even for a structured view of a resource. Try using AKS, and select any given pod or node and the little "path" disappears and you can't reliably go back to the main cluster without hitting the back button that usually does not work. This is also true for most Azure resources, though azureml is oddly very nice to use, UI wise. For some weird reasons, searching in some lists only works with exact prefixes, meaning that you better have the full, correct name of the thing you're looking for. Azure is fine to display surface level information, but it is atrocious when it comes to actually doing stuff or finding details. AWS, and the new UI in particular imo, is a breeze in comparison. But then again, my favorite cloud UI is GCP so maybe I'm just weird like that :)
coredog64 3y ago
We’ll see if it stays this way, but the goal of ProServe and Enterprise Support is to ensure business outcomes rather than directly drive cloud spend.
- Macha 3y ago
  Ehh, at some point the automatic suggestions for lambda, athena, sagemaker, whatever is at least a little interested in getting customer lockin/stickiness.
  - scarface74 3y ago
    I work in ProServe. But even when I was in doing regular old enterprise architecture on prem, with Azure, etc. You’re always locked into your infrastructure and the cost to migrate any large infrastructure no matter how “agnostic” you try to stay comes with major cost both real and opportunity and risk of bugs and down time. Show me your “agnostic” solution and I can show you plenty of ways that you tied yourself to your choices. Not to mention all of the organizational constraints and coordination - architecture review boards, planning committees, project management organizations, etc.
silisili 3y ago
This sounds like a good thing. I work for a <1000 employee firm, and AFAIK we're spending in 6 figures monthly with AWS. I cannot even imagine what huge places spend there. All it takes is bad support, severe price undercutting, or degrading service and we're off to another, or a split. By having people at least feign caring, giving support, and giving suggestions, they're locking us in and getting way more back in revenue than what it's costing them, at least from us.
- gowld 3y ago
  > All it takes is [bad things] and we're off to another > By [avoiding those bad things] they're locking us in Providing a good product at a good price is "locking in" ?
  - silisili 3y ago
    Well sure. We're happy with the service and support, so keep deploying more and more. It's not locking in like a gym membership sure, more of a trust relationship. And the more we deploy and use, the harder it would be to jump ship.
    - paulmd 3y ago
      Egress costs alone make leaving pretty much a non-starter once you're entrenched. Leaving really involves running two systems in parallel for a bit and gradually doing a changeover - blue-green in production between two different clouds. Which is not cheap/free either, you are actually going to increase your costs significantly as you leave.
      - robocat 3y ago
        Appropriately sneaky: https://aws.amazon.com/snowmobile/ https://aws.amazon.com/snowmobile/ appears[1] to allow export of petabytes of data but then the FAQ reneges “Snowmobile does not support data export”[2]. [1] tagline: “Migrate or transport exabyte-scale datasets into and out of AWS”. [2] “Q: Can I export data from AWS with Snowmobile?” A: No. in https://aws.amazon.com/snowmobile/faqs/#Using_Snowmobile https://aws.amazon.com/snowmobile/faqs/#Using_Snowmobile
alex_lav 3y ago
If AWS wants to stop doing this, AWS can prioritize making optimizations easier for the customer to do...
Anduia 3y ago
This is more of a side effect of providing self-support solutions, and a trend in Customer Support departments. Amazon Support has been on top of the lists and awards for best support because they have proper KPIs that incentive customer retention/satisfaction over just number of contacts resolved. So when you have good support/sales staff and most contacts are solved with self-service, what remains are contacts about complicated cases and inquiries. I imagine that they always had a lot of contacts about optimizing spending, and policies to help and retain those customers accordingly, and now the percentage of time spent in those is higher, probably because the other types of contacts are now self-service.
- crabbone 3y ago
  AWS doesn't even have a way to report a bug... what "on top of the list" are you talking about? Who else is on that list? AWS support is atrocious, unless you cozy up to them somehow to get special treatment. If you are a "regular" customer, you get zilch. AWS offers best performance for the best price, that and they are the largest service provider is what makes them succeed. They don't need to spend anything on support -- it's not cost effective. My personal experience: we provided a service through AWS marketplace related to storage. So, we are not your "regular" customer, had to pay them some for accreditation... and here's the thing: it's probably something about how we create EBS snapshots, but about every thousand or so snapshots creation stalls. Doesn't fail, doesn't succeed, just hangs forever. There's nobody to talk to in AWS about this. People who "certified" us (what a joke...) cannot do anything about this problem. And there's more stuff like that. Sometimes some resources won't delete first 1-2-3 times you try. Some other resources are created, but don't work once in a blue moon. And all you can do about it is just curse and try again.
  - scarface74 3y ago
    I work at AWS now (ProServe). But I got my start with AWS at a 60 person company that had business support. The live support was amazing and I often used them as the “easy button”
    - 3y ago
rr808 3y ago
Lol optimize to help the customer or Amazon?
- deleted 3y ago
  [deleted]
omneity 3y ago
1. At which point does it become cheaper for AWS to offer discounts to customers rather than optimizing their spend? 2. At which point does it become cheaper for AWS to just simplify their pricing structure?
- belthesar 3y ago
  Optimizing spend for a customer is also optimizing capacity, which is indeed finite. By optimizing spend with right-sizing and such, they lose a very small amount upfront, but can increase customer density, which is a much more sustainable data point for modeling capacity growth. More customers on the platform is more opportunity for larger growth at a sustainable pace that they can scale capacity for.
- dilyevsky 3y ago
  1. "optimizing the spend" is probably overengineering some insane Rube Goldberg machine which locks you in more and commits in engineering resources which could be spent thinking about moving to a different cloud / onprem 2. See 1. WAI
syrusakbary 3y ago
TL;DR: they want to rip you off less aggressively, so you don't ditch them on the short term. Cloud computing has become so expensive that so many companies are moving away from it. And for good reason. The only providers that are actually reasonable on pricing at the moment are OVH and Hetzner... by an order of magnitude (or two) cheaper than Google Cloud, AWS, Azure, Vercel, etc. Trusting for any of the latter companies to not rip you off is like trusting a wolf to take care of the sheep herd. It just doesn't make any sense, as their incentives are many times at the opposite spectrum than their customers.
- beebmam 3y ago
  Eh, it depends. I've seen such inefficient use of cloud providers. Really depends on what cloud users need to do.
- 0zemp1c 3y ago
  I expect almost everyone who tries to rebel and go "on prem" will flame out and come running back to the cloud Ops talent has really dumbed down over the last decade or so (sorry no polite way to say it). Long gone are the days when the ops engineers were talented devs who just liked hanging out at datacenters. Nowadays most of them are just button pushers who are good for standing up SaaS stacks or other simple tasks, but I'd never ask any I've dealt with in the last ten years to build out a datacenter presence from nothing. Most have never set foot in a datacenter. On top of that, most modern ops teams have been downsized (thanks to cloud) that they wouldn't have the hands to get the job done. Even for good ops people, it can be very hard to capacity-plan and understand what appropriate/affordable/useful hardware is. Most ops folks today have probably never purchased servers for production deployments. AWS will be happy to welcome these companies back after their on-prem dreams die.
  - delfinom 3y ago
    >Ops talent has really dumbed down over the last decade or so Counterpoint, the ops required for your own infrastructure has greatly dumbed down. It might surprise you, but OEM hardware solution have greatly evolved and simplified the same. Now I can setup a core switch running 100 GBs with failovers by just plugging in some cables between them, setting a flag and they immediately start replicating config between themselves. >Even for good ops people, it can be very hard to capacity-plan and understand what appropriate/affordable/useful hardware is. Most ops folks today have probably never purchased servers for production deployments. I'll shock you once again, the same way AWS has sales and support departments that help spoonfeed what you need. So do the hardware OEMs. I can get complete solution walkthroughs with Dell for example.
coding123 3y ago
We have some kind of k8s cluster that's just locked into a state where we can't delete it because of some wacky dependencies that no one at the company understands (it was set up by others). So at some point we'll reach out to amazon to have them wipe it. It's kind of a messy product.
- mdaniel 3y ago
  EKS is a special level of IAM pain, and my belief is they do everything possible to make it hard to use so people don't get all excited about that kind of cloud agnostic technology
no_wizard 3y ago
Now if only they'd spend time optimizing their management APIs and SDKs so they were more coherent. I do not like using the console or having to login to the web portal, but there are things you just can't do from the SDK, or at least, I haven't figured out the right way to do them yet. Entirely Byzantine. I wonder if they'll ever get around to addressing the mountain of complaints folks have about local dev and emulators too.
- sigjuice 3y ago
  Could you share examples of things that can't be done from the SDK? Thanks!
  - no_wizard 3y ago
    Its a mixture of hard to use and things seem to not work as expected. For instance, I want to do multi region deploys for lambda, I can't just do a simultaneous push to deploy across regions. I'm expected to use this messy switch[0] between the CLI and the CDK to do anything useful. This is a tiny example. Not to mention the CDK packages have no comments in the shipped files (at least for typescript) so I can't even introspect the typings and try to understand the purpose of things. The documentation is atrocious. Consider instead Firebase, Supabase or Fly.io, which are dead simple to use. Developer Experience needs a major overhaul. It should be as easy or easier as Supabase or Firebase. No, Amplify is not a solution, its too buggy and has zero margin for customization plus, its local dev experience is quite bad It'll probably never happen though, because developers are just end users, not the true customer, the buyer (e.g. management) is. I think that's the real reason why these improvements languish [0]: https://aws.amazon.com/blogs/compute/deploying-aws-lambda-layers-automatically-across-multiple-regions/ https://aws.amazon.com/blogs/compute/deploying-aws-lambda-la...
    - electroly 3y ago
      Your original post said SDK, that's AWS's name for this: https://aws.amazon.com/sdk-for-net/ https://aws.amazon.com/sdk-for-net/ https://aws.amazon.com/sdk-for-javascript/ https://aws.amazon.com/sdk-for-javascript/ etc. Not this: https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/ The person you're replying to was confused because you said "APIs and SDK" which clearly refers to the former, but then this followup post is referring to the latter. You can do everything with the SDK. The CDK is implemented on top of the SDK and cannot do everything.
epberry 3y ago
The original promise of the cloud was that it was cheaper than on prem. For many companies this has turned out not to be the case. Having worked on a cost optimization product for the past year (https://vantage.sh https://vantage.sh) my belief is that the cloud _is_ cheaper than on prem but it is difficult to configure it to be so. In particular it is difficult and stressful to understand all the knobs to turn within each cloud provider. It's a very AWS thing to put a lot of effort into lowering their customers' bills and I do think it makes for longer lasting business relationships.
- notyourwork 3y ago
  > my belief is that the cloud _is_ cheaper than on prem but it is difficult to configure it to be so. It takes discrete effort in the core planning of your architecture. You cannot look at AWS resources (or any other cloud provider) as an all-you-can-eat buffet. You have to look at your requirements, look at the viable options that may support your requirements and take into consideration cost associated. Without looking at cost during design your company/service/team will have a bad time at some point. There are also some really specific things you can do to lower costs but require knowledge and understanding of a myriad of technologies.
  - pwarner 3y ago
    you can and should look at them as aN "as little as you can eat buffet" option. the cost transparency is a huge part of the value of cloud, even if it cost the same as on prem, the transparency is huge, but it's even more valuable if you make smart choices with that transparency. of course often folks just ignore costs until al of the sudden it's a huge pain point.
    - notyourwork 3y ago
      Our team typically expects some cost consideration given in design documents. This way we know that some attention was given to it and it's a good starting place for discussing costs during design review.
- 3y ago
nixcraft 3y ago
A few weeks back helped someone move from EC2/ELB/RDS to Lightsail Vm/LB/Database The same app and stuff, but the price is now fixed[0]. So many apps can use something like Lightsail and cut costs. I am surprised AWS don't promote lightsail. They also have a weird OS selection and still have CentOS 8, which is no longer supported. They treat Lightsail as a second-class citizen. [0] https://aws.amazon.com/lightsail/pricing/ https://aws.amazon.com/lightsail/pricing/
- nik736 3y ago
  Lightsail is heavily throttled, so I wouldn't use it for anything "serious".
  - rstupek 3y ago
    Do you have any evidence that supports this?
  - Sohcahtoa82 3y ago
    Lightsail instances are just burstable (t2/t3) instances renamed.
    - Dylan16807 3y ago
      Plus a few terabytes of outgoing bandwidth tossed in. As long as you don't use it to "avoid data fees" which seems to be deliberately vague.
      - Sohcahtoa82 3y ago
        The root problem is that AWS charges way too much for data egress, and then sell cheap instances bundled with several times their purchase worth of egress. AWS doesn't want people putting their apps behind LightSail instances solely for the purpose of reducing data egress costs. I think it's a very reasonable rule considering the situation they put themselves in. The problem of course is it quickly leads to bad faith instances of people doing just that, then claiming not to be doing it. But it's going to be impossible for them to write a lawyer-proof rule that prevents it while also not preventing legitimate usage. Like, if I run a web app that accepts requests to example.com/mybucket/myfile.zip, and the app merely pulls myfile.zip from the mybucket S3 bucket and sends it, then yeah, that's a pretty cut-and-dry case of using LightSail to avoid egress fees from S3. But what if I'm using a LightSail instance as just a load balancer in front of EC2, because I don't think an ELB/ALB is flexible enough? That starts to be a bit more of a grey area.
clarkdale 3y ago
The title has two grammatical errors with quotes. The corrected form would be: > AWS staff spending ‘much of their time’ optimizing customers' clouds
micromacrofoot 3y ago
are there enterprise grade products that don't end up spending a large amount of time providing enterprise services?
fwungy 3y ago
IBM's Hybrid Cloud concept is promising. Run your sensitive or expensive bulk resources like dbs onprem and go cloud for the rest. You can often save big just bringing your db onsite.
- running101 3y ago
  Works if latency isn't an issue between app and db, which it often times is.
  - danpalmer 3y ago
    I did a cloud migration from a local datacenter to GCP and DB latency was the big issue for us. Latency from our DC to GCP was ~10ms, so an average page load with 10 queries added 100ms overhead which was mostly unacceptable. Big enterprisey applications like this would love to only be doing 10 queries, 30+ is much more likely, and I bet they won't be moving from 1 DC to 1 cloud region, so 10ms is also unlikely. Back of the envelope suggests more like 1s of additional latency. That would barely work for a big enough OLAP deployment, with all sorts of varied consumers, let alone OLTP.
- fortylove 3y ago
  The concept is promising, agreed. But like most (all?) recent IBM products, the failure point will be in the execution of the concept. IBM is a marketing company at this point, not a serious technology company.
  - acdha 3y ago
    Execution and rent-seeking – their culture is based on high margins so they tend to design things which will put a lot of hard to migrate logic into their app and even when they know they’re competing against more affordable options the prices will be eye-watering. I assume that the whales who do buy generate enough revenue to make up for the lost sales but it doesn’t seem like a good long-term strategy.
- electroly 3y ago
  In the AWS world, you can do this by colocating servers at an AWS Direct Connect facility. You get a fiber connection from your rack to AWS's rack inside the building, and then AWS backhauls it on their network to the AWS Region. There are such colocation facilities located within a few miles of any major AWS Region for low latency (~1 msec) connections.
DogTweezers 3y ago
[flagged]
eitally 3y ago
I was in Google Cloud's partner org for >7 years, managing a team of solution architects pointed at our most strategic partners (Accenture, Deloitte, Infosys, HCL, TCS, etc). I have been saying for nearly the entirety of the time that the way things will pan out for hyperscalers is going to roughly look like this: AWS = the bazaar of public clouds. A service for nearly everything, but WYSIWYG and quality & consistency will be all over the place, just like amazon.com has become. Azure = will ultimately own the enterprise. Microsoft is the new IBM and their mature GTM and Professional Services organizations will carry increasing value as cloud services become mostly commoditized. Microsoft has multiple large revenue streams to fund disruptive acquisitions and these will bear fruit through good management. Satya is proving to be an exceptional CEO. GCP = an also-ran on compute/network/storage, but potentially differentiated on data, analytics & AI if leadership can organize the troops and keep focus on things that matter. Still very rough on the GTM side, and late to the party, making enterprise sales that much harder. Has some unique strengths, but can't rest on its laurels. Execution and focus are key. Oracle = Making a killing selling an easy-button-to-cloud to existing Oracle on-prem customers, and frankly, this is plenty to keep things moving forward for a while. IBM = Lots of hopes & dreams associated with RedHat acquisition and GBS/GTS split. It's still a bit early to tell how things will pan out, but IBM isn't playing the same sport as the rest, and has a lot more in common with Oracle than the big three. My prediction for the next couple of years is that AWS continues to lose market share due to QoS and ultimately being spread too thin (and alienating partners), and all the rest capture it. MSFT is the biggest winner, Google will eventually find a sweet spot (it's already in the "too big to fail" category, and will achieve profitability this year), and ORCL/IBM will see increasing success in their niches but largely avoid direct competition/comparison with the others.
- nextworddev 3y ago
  People underestimate AWS but as long as their S3, EC2, SQS, and Lambda keeps kicking butt, it'd be really hard to displace them. All roads ultimate lead to storage and compute, which I think AWS does a really good job in.
  - danpalmer 3y ago
gumballindie 3y ago
Of course. AWS apps are a mess and needlessly over complicated. Even if sales went on they'd still spend more time untangling the mess they've made for their clients.
locustmostest 3y ago
I believe the next wave of SaaS is products that provide custom deployment, operational support, and cost optimization, where specialist software orgs can provide standard efficiencies and engage AWS for deeper looks.
nfRfqX5n 3y ago
this is not new. AWS support would always help with this.
perrygeo 3y ago
Isn't that the point? "Don't build your own infrastructure, outsource to the cloud!" has been the rally call for a decade. It's the entire reason "the cloud" has any value at all, beyond renting at hardware depreciation rates. Someone else is there maintaining the data center, managing failover, ensuring uptime, etc. by contract. This press release could easily be interpreted as AWS backpedaling on a commitment to maintain its infrastructure.
- tshaddox 3y ago
  Isn’t spending a significant portion of resources doing customer-specific work pretty much the opposite of the point? That sounds just like sysadmin work for hire, which is obviously valuable, but is essentially the key distinguishing factor from traditional server computing and cloud computing. Of course at the edges there is always going to be overlap, since important customers will have feature requests and complaints that the cloud providers will learn from.
  - perrygeo 3y ago
    > sysadmin work for hire you'd be shocked to know how many people believe that this exactly what the "cloud" is. these are the people making the support requests.
deleted 3y ago
[deleted]
matthewcford 3y ago
We had a RDS db running at 100% when typical traffic is say 40/50%. Support never found the solution, we had to scale up and out and completely replace the db two times for performance to return to the baseline. All costed about 10k for what was essentially an aws bug.

254 points by MISTERJerk2U 3y ago

Use vanilla products (K8S, "RDS", ...) so you can always dangle the threat of going on-prem or to another cloud provider. Once you use Lambdas and other deep AWS product, you're locked in.

master_crab 3y ago
You could use containerized lambdas. Your application logic would be mostly safe to migrate around as need be. But then again, migrating from one cloud to another is always a heavy lift no matter how it’s constructed.
- vidarh 3y ago
  Having done zero downtime migration from AWS to Google to managed servers (chasing credits, and then moving to Hetzner when the credits ran out): it's not much heavy lifting if you treat each cloud provider as just providing raw compute and storage resources.
  - jamsauceismad 3y ago
    It's because you did the heavy lifting up front with how your application is designed and how your infra is provisioned (I'm guessing everything is terraformed or something?).
    - sleepybrett 3y ago
      Also a great unlock if you do the bulk of your work in kubernetes. Amazon is certainly doing some things in their kube implementation that will make moving suck more (karpenter, some of their other integrations) in an effort to be better and thus sticky... But it's still pretty easy to go from one kube cluster to another.
    - vidarh 3y ago
      Everything in Docker containers + a service discovery layer (Consul on that particular case) will get you most of the way there as long as you don't get seduced into relying on cloud specific services.
      - scarface74 3y ago
        And then you’re managing Consul clusters (been there done that).
        vidarh 3y ago
        I never found that a problem. Consul was robust when I used it.
- croddin 3y ago
  With the lambda web adapter[1], you shouldn't need to make any code changes for web projects, just some dockerfile changes which are only used if it is running as a lambda, so the same image should still work on ecs or another cloud. [1]https://github.com/awslabs/aws-lambda-web-adapter https://github.com/awslabs/aws-lambda-web-adapter
deleted 3y ago
[deleted]
sarathyweb 3y ago
If possible can you suggest me a lof vanilla products. My team is building a platform that allows anyone to spinup instances on any cloud platform. We’re planning to add support for DNS management ( Route53, Google cloud DNS& Azure DNS) and storage buckets
- potta_coffee 3y ago
  Just what we need, another platform.
tyingq 3y ago
I don't personally feel like Lambdas themselves are the hard lock-in. It's the stuff around them that really gets into your code or forces specific patterns. SQS, SNS, Dynamo, Kinesis, EventBridge, etc.
- preommr 3y ago
  Which frankly are the essential parts of a robust cloud architecture. Deploying a server is trivial - just dump it on any kind of compute resource. Managing fault-tolerance and monitoring, etc. between those services is the tricky part.
  - mschuster91 3y ago
    IME, not if you're using Terraform with proper modularization and can stick to the commonly available feature set. Have one layer of modules that describe what you want (e.g. a virtual server, database, monitoring) and behind that a separate layer that implements it (e.g. creates an EC2 instance, an RDS database or a CloudWatch alert).
    - scarface74 3y ago
      Terraform is not “cloud agnostic” anymore than using Python with the various cloud providers SDKs. Each provider within TF is tied tightly with the cloud provider. Standard Disclaimer: yes I work at AWS and I do IAC with the CloudFormation or TF depends on what the customer wants
    - Karunamon 3y ago
      That's a nonstarter just because of how you describe the various services at each cloud provider. For instance, Google cloud is big into using "projects" as organizers for resources, where the closest analogue in AWS land is an entirely separate account.
- throwawayx35fw 3y ago
  In my opinion, SQS shouldn't be on that list. You save a lot of time and resources just using SQS instead of setting up your own servers. And the lock-in is not as problematic as Lambdas etc. It doesn't require much code change to move to an alternative message queue (RabbitMQ etc.), so the lock-in is minimal. In my projects, I just need to change a few lines of configuration code and the actual message processing code should remain the same.
roncesvalles 3y ago
I don't see much difference in vendor lock-in between EKS and Lambda. The abstraction between your Kubernetes application and the underlying platform isn't airtight.
deleted 3y ago
[deleted]
hnlmorg 3y ago
In my experience writing cloud agnostic infra usually ends up more costlier. Not just in monetary terms running the infrastructure, but also in terms of time spent maintaining the infrastructure. There’s generally very little point using the cloud if you’re not going to use cloud services.
- aeyes 3y ago
  If all you need is machines then there is still a massive benefit in using the cloud. You can spin up 1000 machines tomorrow without having to buy them, wait for getting them (2 months later), rack them, cable them, .... Especially if you need a couple of racks things get complicated quickly. If you have never racked machines for a week you probably underestimate the amount of time it takes before you can actually run workloads on them. And if you need a 1000 machines for x years which otherwise you'd put in your own data center you can absolutely go to AWS, GCP, OCI and bid them down against each other.
  - hnlmorg 3y ago
    > If all you need is machines then there is still a massive benefit in using the cloud. “massive” is an overstatement. “some” would be more accurate. And your example is correct, which is why I said “generally” in my post rather than “always” or “never”. In fact my current project is using AWS in exactly the way you described. > If you have never racked machines I have done. Many times. :) And there are ways you can get machines at short notice without going down the AWS route. In fact it’s actually pretty easy and used to be really common. I used to use all sorts of different VPS and dedicated hosting for personal projects (while managing on prem stuff professionally). These days a lot of those bigger companies are now just wrapped up as part of “cloud services” but there are still some smaller providers out there doing things old school. In fact I have a few GFX cards for machine learning in a London data centre managed by one such independent provider. > And if you need a 1000 machines for x years which otherwise you'd put in your own data center you can absolutely go to AWS, GCP, OCI and bid them down against each other. You’re now talking about cost optimisation and commitment-based discounts, which is a whole other tangent. Anyways, my point wasn’t that the cloud is more or less expensive than on prem. it was that designing your cloud architecture to be cloud agnostic is more expensive and rarely worthwhile compared with making use of the services offered by whichever cloud provider you’re using.

mooreds 3y ago

Not just their "clouds" but their "cloud spend". From the article: > Amazon Web Services sales and support teams are currently “spending much of their time helping customers optimize their AWS spend so they can better weather this uncertain economy.”

deleted 3y ago
[deleted]
gatvol 3y ago
No doubt by pushing the clients to use inappropriate vendor-locky-in serverless tech stacks that are inappropriate for the workloads.

samstave 3y ago

Personally, this is what I expect of them, specifically for smaller orgs that don't have CISO, SRE or other ops folks needed. Now, I'm not saying this should be the expected behavior for everyone or every situation, but "aws staff spends majority of time doing what aws staff is hired and skilled to do" Seems pretty "cost of doing business" to me

neves 3y ago
I think that this consumer oriented facet of Amazon is impressive. No other provider will dedicate this time to clients.
- hanselot 3y ago
  I can make a similar argument regarding Jehova's witnesses.
  - samstave 3y ago
    Guys! We have another ~~Linux~~ Zealot over here!
- mschuster91 3y ago
  Oh, I have had good experiences with German providers Manitu and Corpex. Very good service, although the latter almost exclusively deals in managed hosting.

boesboes 3y ago

They still have plenty of time to cripple their UI though

sebazzz 3y ago
What? The AWS UI is much better than that slow ever-slowing-progress-bars RandomError throwing Azure portal.
- edgyquant 3y ago
  Just because there are worse things doesn’t mean the current interface doesn’t suck
  - hot_gril 3y ago
    It does kinda mean that if everything else is worse.
- SketchySeaBeast 3y ago
  That's funny - I primarily have used Azure but whenever I drop into AWS I feel like it's actively punishing me for trying to use the UI.
  - mardifoufs 3y ago
    Azure UI is awful for stuff like hitting the back button and reliably going back, or even for a structured view of a resource. Try using AKS, and select any given pod or node and the little "path" disappears and you can't reliably go back to the main cluster without hitting the back button that usually does not work. This is also true for most Azure resources, though azureml is oddly very nice to use, UI wise. For some weird reasons, searching in some lists only works with exact prefixes, meaning that you better have the full, correct name of the thing you're looking for. Azure is fine to display surface level information, but it is atrocious when it comes to actually doing stuff or finding details. AWS, and the new UI in particular imo, is a breeze in comparison. But then again, my favorite cloud UI is GCP so maybe I'm just weird like that :)

coredog64 3y ago

We’ll see if it stays this way, but the goal of ProServe and Enterprise Support is to ensure business outcomes rather than directly drive cloud spend.

Macha 3y ago
Ehh, at some point the automatic suggestions for lambda, athena, sagemaker, whatever is at least a little interested in getting customer lockin/stickiness.
- scarface74 3y ago
  I work in ProServe. But even when I was in doing regular old enterprise architecture on prem, with Azure, etc. You’re always locked into your infrastructure and the cost to migrate any large infrastructure no matter how “agnostic” you try to stay comes with major cost both real and opportunity and risk of bugs and down time. Show me your “agnostic” solution and I can show you plenty of ways that you tied yourself to your choices. Not to mention all of the organizational constraints and coordination - architecture review boards, planning committees, project management organizations, etc.

silisili 3y ago

This sounds like a good thing. I work for a <1000 employee firm, and AFAIK we're spending in 6 figures monthly with AWS. I cannot even imagine what huge places spend there. All it takes is bad support, severe price undercutting, or degrading service and we're off to another, or a split. By having people at least feign caring, giving support, and giving suggestions, they're locking us in and getting way more back in revenue than what it's costing them, at least from us.

gowld 3y ago
> All it takes is [bad things] and we're off to another > By [avoiding those bad things] they're locking us in Providing a good product at a good price is "locking in" ?
- silisili 3y ago
  Well sure. We're happy with the service and support, so keep deploying more and more. It's not locking in like a gym membership sure, more of a trust relationship. And the more we deploy and use, the harder it would be to jump ship.
  - paulmd 3y ago
    Egress costs alone make leaving pretty much a non-starter once you're entrenched. Leaving really involves running two systems in parallel for a bit and gradually doing a changeover - blue-green in production between two different clouds. Which is not cheap/free either, you are actually going to increase your costs significantly as you leave.
    - robocat 3y ago
      Appropriately sneaky: https://aws.amazon.com/snowmobile/ https://aws.amazon.com/snowmobile/ appears[1] to allow export of petabytes of data but then the FAQ reneges “Snowmobile does not support data export”[2]. [1] tagline: “Migrate or transport exabyte-scale datasets into and out of AWS”. [2] “Q: Can I export data from AWS with Snowmobile?” A: No. in https://aws.amazon.com/snowmobile/faqs/#Using_Snowmobile https://aws.amazon.com/snowmobile/faqs/#Using_Snowmobile

alex_lav 3y ago

If AWS wants to stop doing this, AWS can prioritize making optimizations easier for the customer to do...

Anduia 3y ago

This is more of a side effect of providing self-support solutions, and a trend in Customer Support departments. Amazon Support has been on top of the lists and awards for best support because they have proper KPIs that incentive customer retention/satisfaction over just number of contacts resolved. So when you have good support/sales staff and most contacts are solved with self-service, what remains are contacts about complicated cases and inquiries. I imagine that they always had a lot of contacts about optimizing spending, and policies to help and retain those customers accordingly, and now the percentage of time spent in those is higher, probably because the other types of contacts are now self-service.

crabbone 3y ago
AWS doesn't even have a way to report a bug... what "on top of the list" are you talking about? Who else is on that list? AWS support is atrocious, unless you cozy up to them somehow to get special treatment. If you are a "regular" customer, you get zilch. AWS offers best performance for the best price, that and they are the largest service provider is what makes them succeed. They don't need to spend anything on support -- it's not cost effective. My personal experience: we provided a service through AWS marketplace related to storage. So, we are not your "regular" customer, had to pay them some for accreditation... and here's the thing: it's probably something about how we create EBS snapshots, but about every thousand or so snapshots creation stalls. Doesn't fail, doesn't succeed, just hangs forever. There's nobody to talk to in AWS about this. People who "certified" us (what a joke...) cannot do anything about this problem. And there's more stuff like that. Sometimes some resources won't delete first 1-2-3 times you try. Some other resources are created, but don't work once in a blue moon. And all you can do about it is just curse and try again.
- scarface74 3y ago
  I work at AWS now (ProServe). But I got my start with AWS at a 60 person company that had business support. The live support was amazing and I often used them as the “easy button”
  - 3y ago

rr808 3y ago

Lol optimize to help the customer or Amazon?

deleted 3y ago
[deleted]

omneity 3y ago

1. At which point does it become cheaper for AWS to offer discounts to customers rather than optimizing their spend? 2. At which point does it become cheaper for AWS to just simplify their pricing structure?

belthesar 3y ago
Optimizing spend for a customer is also optimizing capacity, which is indeed finite. By optimizing spend with right-sizing and such, they lose a very small amount upfront, but can increase customer density, which is a much more sustainable data point for modeling capacity growth. More customers on the platform is more opportunity for larger growth at a sustainable pace that they can scale capacity for.
dilyevsky 3y ago
1. "optimizing the spend" is probably overengineering some insane Rube Goldberg machine which locks you in more and commits in engineering resources which could be spent thinking about moving to a different cloud / onprem 2. See 1. WAI

syrusakbary 3y ago

TL;DR: they want to rip you off less aggressively, so you don't ditch them on the short term. Cloud computing has become so expensive that so many companies are moving away from it. And for good reason. The only providers that are actually reasonable on pricing at the moment are OVH and Hetzner... by an order of magnitude (or two) cheaper than Google Cloud, AWS, Azure, Vercel, etc. Trusting for any of the latter companies to not rip you off is like trusting a wolf to take care of the sheep herd. It just doesn't make any sense, as their incentives are many times at the opposite spectrum than their customers.

beebmam 3y ago
Eh, it depends. I've seen such inefficient use of cloud providers. Really depends on what cloud users need to do.
0zemp1c 3y ago
I expect almost everyone who tries to rebel and go "on prem" will flame out and come running back to the cloud Ops talent has really dumbed down over the last decade or so (sorry no polite way to say it). Long gone are the days when the ops engineers were talented devs who just liked hanging out at datacenters. Nowadays most of them are just button pushers who are good for standing up SaaS stacks or other simple tasks, but I'd never ask any I've dealt with in the last ten years to build out a datacenter presence from nothing. Most have never set foot in a datacenter. On top of that, most modern ops teams have been downsized (thanks to cloud) that they wouldn't have the hands to get the job done. Even for good ops people, it can be very hard to capacity-plan and understand what appropriate/affordable/useful hardware is. Most ops folks today have probably never purchased servers for production deployments. AWS will be happy to welcome these companies back after their on-prem dreams die.
- delfinom 3y ago
  >Ops talent has really dumbed down over the last decade or so Counterpoint, the ops required for your own infrastructure has greatly dumbed down. It might surprise you, but OEM hardware solution have greatly evolved and simplified the same. Now I can setup a core switch running 100 GBs with failovers by just plugging in some cables between them, setting a flag and they immediately start replicating config between themselves. >Even for good ops people, it can be very hard to capacity-plan and understand what appropriate/affordable/useful hardware is. Most ops folks today have probably never purchased servers for production deployments. I'll shock you once again, the same way AWS has sales and support departments that help spoonfeed what you need. So do the hardware OEMs. I can get complete solution walkthroughs with Dell for example.

coding123 3y ago

We have some kind of k8s cluster that's just locked into a state where we can't delete it because of some wacky dependencies that no one at the company understands (it was set up by others). So at some point we'll reach out to amazon to have them wipe it. It's kind of a messy product.

mdaniel 3y ago
EKS is a special level of IAM pain, and my belief is they do everything possible to make it hard to use so people don't get all excited about that kind of cloud agnostic technology

no_wizard 3y ago

Now if only they'd spend time optimizing their management APIs and SDKs so they were more coherent. I do not like using the console or having to login to the web portal, but there are things you just can't do from the SDK, or at least, I haven't figured out the right way to do them yet. Entirely Byzantine. I wonder if they'll ever get around to addressing the mountain of complaints folks have about local dev and emulators too.

sigjuice 3y ago
Could you share examples of things that can't be done from the SDK? Thanks!
- no_wizard 3y ago
  Its a mixture of hard to use and things seem to not work as expected. For instance, I want to do multi region deploys for lambda, I can't just do a simultaneous push to deploy across regions. I'm expected to use this messy switch[0] between the CLI and the CDK to do anything useful. This is a tiny example. Not to mention the CDK packages have no comments in the shipped files (at least for typescript) so I can't even introspect the typings and try to understand the purpose of things. The documentation is atrocious. Consider instead Firebase, Supabase or Fly.io, which are dead simple to use. Developer Experience needs a major overhaul. It should be as easy or easier as Supabase or Firebase. No, Amplify is not a solution, its too buggy and has zero margin for customization plus, its local dev experience is quite bad It'll probably never happen though, because developers are just end users, not the true customer, the buyer (e.g. management) is. I think that's the real reason why these improvements languish [0]: https://aws.amazon.com/blogs/compute/deploying-aws-lambda-layers-automatically-across-multiple-regions/ https://aws.amazon.com/blogs/compute/deploying-aws-lambda-la...
  - electroly 3y ago
    Your original post said SDK, that's AWS's name for this: https://aws.amazon.com/sdk-for-net/ https://aws.amazon.com/sdk-for-net/ https://aws.amazon.com/sdk-for-javascript/ https://aws.amazon.com/sdk-for-javascript/ etc. Not this: https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/ The person you're replying to was confused because you said "APIs and SDK" which clearly refers to the former, but then this followup post is referring to the latter. You can do everything with the SDK. The CDK is implemented on top of the SDK and cannot do everything.

epberry 3y ago

The original promise of the cloud was that it was cheaper than on prem. For many companies this has turned out not to be the case. Having worked on a cost optimization product for the past year (https://vantage.sh https://vantage.sh) my belief is that the cloud _is_ cheaper than on prem but it is difficult to configure it to be so. In particular it is difficult and stressful to understand all the knobs to turn within each cloud provider. It's a very AWS thing to put a lot of effort into lowering their customers' bills and I do think it makes for longer lasting business relationships.

notyourwork 3y ago
> my belief is that the cloud _is_ cheaper than on prem but it is difficult to configure it to be so. It takes discrete effort in the core planning of your architecture. You cannot look at AWS resources (or any other cloud provider) as an all-you-can-eat buffet. You have to look at your requirements, look at the viable options that may support your requirements and take into consideration cost associated. Without looking at cost during design your company/service/team will have a bad time at some point. There are also some really specific things you can do to lower costs but require knowledge and understanding of a myriad of technologies.
- pwarner 3y ago
  you can and should look at them as aN "as little as you can eat buffet" option. the cost transparency is a huge part of the value of cloud, even if it cost the same as on prem, the transparency is huge, but it's even more valuable if you make smart choices with that transparency. of course often folks just ignore costs until al of the sudden it's a huge pain point.
  - notyourwork 3y ago
    Our team typically expects some cost consideration given in design documents. This way we know that some attention was given to it and it's a good starting place for discussing costs during design review.
3y ago

nixcraft 3y ago

A few weeks back helped someone move from EC2/ELB/RDS to Lightsail Vm/LB/Database The same app and stuff, but the price is now fixed[0]. So many apps can use something like Lightsail and cut costs. I am surprised AWS don't promote lightsail. They also have a weird OS selection and still have CentOS 8, which is no longer supported. They treat Lightsail as a second-class citizen. [0] https://aws.amazon.com/lightsail/pricing/ https://aws.amazon.com/lightsail/pricing/

nik736 3y ago
Lightsail is heavily throttled, so I wouldn't use it for anything "serious".
- rstupek 3y ago
  Do you have any evidence that supports this?
- Sohcahtoa82 3y ago
  Lightsail instances are just burstable (t2/t3) instances renamed.
  - Dylan16807 3y ago
    Plus a few terabytes of outgoing bandwidth tossed in. As long as you don't use it to "avoid data fees" which seems to be deliberately vague.
    - Sohcahtoa82 3y ago
      The root problem is that AWS charges way too much for data egress, and then sell cheap instances bundled with several times their purchase worth of egress. AWS doesn't want people putting their apps behind LightSail instances solely for the purpose of reducing data egress costs. I think it's a very reasonable rule considering the situation they put themselves in. The problem of course is it quickly leads to bad faith instances of people doing just that, then claiming not to be doing it. But it's going to be impossible for them to write a lawyer-proof rule that prevents it while also not preventing legitimate usage. Like, if I run a web app that accepts requests to example.com/mybucket/myfile.zip, and the app merely pulls myfile.zip from the mybucket S3 bucket and sends it, then yeah, that's a pretty cut-and-dry case of using LightSail to avoid egress fees from S3. But what if I'm using a LightSail instance as just a load balancer in front of EC2, because I don't think an ELB/ALB is flexible enough? That starts to be a bit more of a grey area.

clarkdale 3y ago

The title has two grammatical errors with quotes. The corrected form would be: > AWS staff spending ‘much of their time’ optimizing customers' clouds

micromacrofoot 3y ago

are there enterprise grade products that don't end up spending a large amount of time providing enterprise services?

fwungy 3y ago

IBM's Hybrid Cloud concept is promising. Run your sensitive or expensive bulk resources like dbs onprem and go cloud for the rest. You can often save big just bringing your db onsite.

running101 3y ago
Works if latency isn't an issue between app and db, which it often times is.
- danpalmer 3y ago
  I did a cloud migration from a local datacenter to GCP and DB latency was the big issue for us. Latency from our DC to GCP was ~10ms, so an average page load with 10 queries added 100ms overhead which was mostly unacceptable. Big enterprisey applications like this would love to only be doing 10 queries, 30+ is much more likely, and I bet they won't be moving from 1 DC to 1 cloud region, so 10ms is also unlikely. Back of the envelope suggests more like 1s of additional latency. That would barely work for a big enough OLAP deployment, with all sorts of varied consumers, let alone OLTP.
fortylove 3y ago
The concept is promising, agreed. But like most (all?) recent IBM products, the failure point will be in the execution of the concept. IBM is a marketing company at this point, not a serious technology company.
- acdha 3y ago
  Execution and rent-seeking – their culture is based on high margins so they tend to design things which will put a lot of hard to migrate logic into their app and even when they know they’re competing against more affordable options the prices will be eye-watering. I assume that the whales who do buy generate enough revenue to make up for the lost sales but it doesn’t seem like a good long-term strategy.
electroly 3y ago
In the AWS world, you can do this by colocating servers at an AWS Direct Connect facility. You get a fiber connection from your rack to AWS's rack inside the building, and then AWS backhauls it on their network to the AWS Region. There are such colocation facilities located within a few miles of any major AWS Region for low latency (~1 msec) connections.

DogTweezers 3y ago

[flagged]

eitally 3y ago

I was in Google Cloud's partner org for >7 years, managing a team of solution architects pointed at our most strategic partners (Accenture, Deloitte, Infosys, HCL, TCS, etc). I have been saying for nearly the entirety of the time that the way things will pan out for hyperscalers is going to roughly look like this: AWS = the bazaar of public clouds. A service for nearly everything, but WYSIWYG and quality & consistency will be all over the place, just like amazon.com has become. Azure = will ultimately own the enterprise. Microsoft is the new IBM and their mature GTM and Professional Services organizations will carry increasing value as cloud services become mostly commoditized. Microsoft has multiple large revenue streams to fund disruptive acquisitions and these will bear fruit through good management. Satya is proving to be an exceptional CEO. GCP = an also-ran on compute/network/storage, but potentially differentiated on data, analytics & AI if leadership can organize the troops and keep focus on things that matter. Still very rough on the GTM side, and late to the party, making enterprise sales that much harder. Has some unique strengths, but can't rest on its laurels. Execution and focus are key. Oracle = Making a killing selling an easy-button-to-cloud to existing Oracle on-prem customers, and frankly, this is plenty to keep things moving forward for a while. IBM = Lots of hopes & dreams associated with RedHat acquisition and GBS/GTS split. It's still a bit early to tell how things will pan out, but IBM isn't playing the same sport as the rest, and has a lot more in common with Oracle than the big three. My prediction for the next couple of years is that AWS continues to lose market share due to QoS and ultimately being spread too thin (and alienating partners), and all the rest capture it. MSFT is the biggest winner, Google will eventually find a sweet spot (it's already in the "too big to fail" category, and will achieve profitability this year), and ORCL/IBM will see increasing success in their niches but largely avoid direct competition/comparison with the others.

nextworddev 3y ago
People underestimate AWS but as long as their S3, EC2, SQS, and Lambda keeps kicking butt, it'd be really hard to displace them. All roads ultimate lead to storage and compute, which I think AWS does a really good job in.
- danpalmer 3y ago

gumballindie 3y ago

Of course. AWS apps are a mess and needlessly over complicated. Even if sales went on they'd still spend more time untangling the mess they've made for their clients.

locustmostest 3y ago

I believe the next wave of SaaS is products that provide custom deployment, operational support, and cost optimization, where specialist software orgs can provide standard efficiencies and engage AWS for deeper looks.

nfRfqX5n 3y ago

this is not new. AWS support would always help with this.

perrygeo 3y ago

Isn't that the point? "Don't build your own infrastructure, outsource to the cloud!" has been the rally call for a decade. It's the entire reason "the cloud" has any value at all, beyond renting at hardware depreciation rates. Someone else is there maintaining the data center, managing failover, ensuring uptime, etc. by contract. This press release could easily be interpreted as AWS backpedaling on a commitment to maintain its infrastructure.

tshaddox 3y ago
Isn’t spending a significant portion of resources doing customer-specific work pretty much the opposite of the point? That sounds just like sysadmin work for hire, which is obviously valuable, but is essentially the key distinguishing factor from traditional server computing and cloud computing. Of course at the edges there is always going to be overlap, since important customers will have feature requests and complaints that the cloud providers will learn from.
- perrygeo 3y ago
  > sysadmin work for hire you'd be shocked to know how many people believe that this exactly what the "cloud" is. these are the people making the support requests.

deleted 3y ago

[deleted]

matthewcford 3y ago

We had a RDS db running at 100% when typical traffic is say 40/50%. Support never found the solution, we had to scale up and out and completely replace the db two times for performance to return to the baseline. All costed about 10k for what was essentially an aws bug.