Take CloudWatch for example. It's technically "competing" with Splunk, Datadog, and other logging/metrics services. But the usability of CloudWatch is beyond poor - it's slow, the UI is terrible, and has tons of limitations. It provides just barely enough usability that hobbyist users can use it. But most serious businesses will revert to Splunk or Sumo Logic or Datadog.
Another issue I have with AWS is that they simply provide too many ways to do the same thing. I want to run a container. Should I use ElasticBeanstalk? ECS? Fargate? EC2 with Docker? I've been using AWS for years, so I get the subtle differences, but some users just want to click a button and be done with it, which is where third-parties can excel.
There’s a line item for “integrated log analysis” that needs to be met, but there’s less analysis on how useful that feature may be in reality.
Enterprise IT processes are filled with these kind of word-docs filled with checkboxes, and for that, AWS's featureset excels.
It does seem like as of last week's announcement they are starting to try to fix this. I was annoyed we had to log stuff to both Cloudwatch and Splunk to try to get decent logging.
About the only thing I don't like doing is managing my own DB server... so I'm really happy to see DO expanding into this space. For applications and services, dokku gets me where I need to be with the least fuss. I know if anything took off it would mean some pain, but I'll take that when/if it ever happened.
The integration aspect really matters for security and compliance, as well as standardisation: all of which become bigger concerns the larger your organization. If you use the AWS service, you can re-use IAM, CloudTrail, CloudFormation etc. If you attach a third-party service to your AWS setup, then there's a bunch of things to work out.
That being said, they excel at building things that are scalable, reliable and secure, and while you may only see that as 10% of the features, for a lot of ppl that is 80-90%, especially if data is involved. They do tend to improve their products over time as well and for better or worse I am sure a lot of those resourcing decisions are driven by data/revenue rather than how crappy the product is.
At the end of the day this allows others to continue to compete with them, which is a good thing.
Whether or not that's enough remains to be seen.
Reality is, they didn't want to pay FEE's big money because they weren't worth it, and now the company is starving for good UX and they want to pretend they invented a solution to the problem by creating a role that's existed at Google for more than 10 years.
Amazon finally rectified it by introducing the FEE role, which has the same pay scale as SDE's. Perhaps more importantly, the WDE role terminated at WDE III and even that was incredibly difficult to achieve.
That is just your opinion, I love McD burgers. I can also guarantee that in a line up of 5 burgers you wont be able to figure out which one is from McD with blindfold on.
I mean, we've all got a limited amount of time to learn and try new things... being very hard to get some simple SaaS endpoints setup from AWS is often an exercise in frustration. And while I appreciate all the detailed IAM and Firewall options, on Azure (by comparison), if I have the correct security token, I can generally connect over a secure connection from anywhere in the world to pretty much any of their services without friction.
And if I'm going to have to learn a bunch of crap, I'd just assume learn a little more and roll my own on Linode or DO, or any number of much less expensive compute options.
It works because if you are already using a bunch of AWS services, and then you need something that they are providing, you will give that a go first. If it doesn't provide enough, you will move to something else.
Many, many projects, will meet business or contract requirements with the lowest friction product. A great example is "IDS/IPS" or "Anti-malware". Unless specific metrics, requirements, or fine/fee structures exist, 9/10 times, people will check the box on the easiest to deploy.
This is a broad statement :-)
Compliance is mandatory and often sales advantage for being able to sell to certain class of enterprises.
IMHO, quality vs. rich feature set are different things and I see that being mixed up in the overall discussion. All AWS services exceed certain quality standards. Services are built to solve customer problems first. It's not unusual to find gap in feature set vs. competition.
Disclaimer: I used to work for AWS, but do not work there anymore.
This is pretty much spot on.
We use a ton of AWS's services because AWS is already on-boarded for our enterprise. It's way easier to use a AWS feature than to on-board a specialized vendor.
They should brand it 'AWS Basics'.
Having to manage across multiple different system vendors is not a trivial task, if AWS offers a half baked, yet good enough solution, the customers at least will be willing to give it a try.
Ultimately, the competitiveness of your service shouldn't be defined as whether Amazon choose to compete with you or not. If it is indeed the case, then that is something you need to rethink how to position yourself in the market.
Or is it that they hope people would rather get everything from 1 vendor even if it's sub par?
I've noticed for example, that Prime Video and Music are inferior Netflix and Spotify. But I could see myself, if I wanted to tighten my belt, dropping the latter two to save some monthly fees.
Depends on what you're trying to do... I find that dokku goes a long way if you just want to coordinate a few things on a small scale. It's also relatively easy to put 2-3 instances behind a load balancer and just doing blue-green deploys that way. Elastic Beanstalk was also pretty easy with a simple Dockerfile in place. In terms of having a modestly flexible service layer.
I can't speak to the rest, but I just tend to avoid friction as much as possible for as long as possible. I'd rather have a good enough solution that I can work with quickly and not have to spend a lot of time/effort on over more complex solutions.
I don't know what Samsung did with the stuff that was being done by Joyent, but theirs was always an interesting approach in my mind.
Or pay overpriced “Implementation Consultants”. I have no sympathy for people who don’t take the time to learn the subtleties of the platform they choose to use.
On the other hand, I’ll gladly charge them a nice hourly rate to help them.
There is no way to get something really that way but getting away from IT is already worth it even if the result is still not very good.
So so did everything like I would do on prem with a bunch of VMs.
I asked them to set up a dev, qa, uat, and production subnet. All with multiple VMs.
I used 7 VMs for Hashicorp’s Consul, 7 for Nomad, and 7 for Mongo. (1 for each non production environment and a cluster of 3 for production.) I also used Fabio. Between all of that I had my configuration key/value store, service discovery, job scheduling (Nomad), and data store. I also had build boxes for Team Foundation Server (or whatever MS is calling thier hosted TFS version these days with local agents.)
It wasn’t until after I was getting ready to leave the company that I realized how dumb this setup was for an AWS hosted solution. Don’t get me wrong, I wouldn’t have done too much differently today for a self hosted solution.
I left the company, self demoted to an individual contributor role at a smaller company that was “cloud native” and I spent the next year learning AWS inside and out and taking advantage of reimbursements for certifications.
I’m still at the company now, but when and if so do decide to leave, I’m. It going back to being an architect for a company. Consulting is way more lucrative.
Historical reasons. The technology has evolved, and AWS has simply continued to add new services. Sometimes there is overlap. Perhaps if they were starting from scratch they might offer only one product.
They have nothing that is feature complete, but if it were just 10% they wouldn't get buyin.
Even their API interfaces are dated and cumbersome to use.
They build their own custom nitro ASICs to integrate with KVM, for networking, storage, security, etc. That code doesn't make sense anywhere but AWS. They build things in ways that are tightly integrated with their internal systems and at a scale that few have experience with.
Take their new Envoy based service mesh for example, I really do hope that they make meaningful contributions back to the main project, but I also suspect they will doing lots of custom integration with their own hardware and internal network that will never make sense to support in an OSS project. Who knows, their Annapurna Labs divsion might even be building a custom card that includes Envoy functionality.
As to them being known for destroying OSS businesses I am drawing a blank there, can you provide some examples?
Open source takes work and the foresight to separate your custom shit from things genuinely helpful to the community. Amazon doesn't encourage or incentivize that kind of thinking.
That is exactly what AWS has done in releasing Firecracker. Better late than never.
Releasing stuff isn't simple, the hosted services only work because of the rest of their infrastructure. Writing about the tech is usually the best way to spur clean open-source versions that we can all use.
From what I recall DynamoDB is a somewhat hacky API layer over a bunch of MySQL clusters. I'm not sure anyone would, or should, attempt to use a non-managed version of it.
The recent MySQL info comes from this 2016 thread on DynamoDB storing empty strings: https://news.ycombinator.com/item?id=13170746
Confirmed by this comment specifically: https://news.ycombinator.com/item?id=13173927
The latest 2018 ReInvent deep dive on DynamoDB doesn't reveal anything but still fits if mysql is powering the storage nodes: https://www.youtube.com/watch?v=yvBR71D0nAQ
But there is more to this as well. AWS is a huge ecosystem by itself, a lot their services intertwined with each other, simply open source DynamoDB isn't enough without open sourcing the networking/storage functionality that is probably provided by other services.
I thought the point of permissive licenses over copyleft licenses is that you're explicitly granting companies the right to make money off your code without giving anything back.
Tim O'Reilly has a story (which I'll probably butcher) where after publishing the BSD manuals as books he was accused by someone at a conference of stealing the author's work. One of the authors stood up and said something like "Actually what Tim is doing is exactly what we want - spreading the material as widely as possible and making it as useful as possible. We knew exactly what we were doing choosing that license".
It's the same spirit in which MacOS being based on BSD is fine, even if not a single line of code is shared back. The question isn't "What did Apple share back to BSD programmers recently?", it's "Is the world a better place with MacOS in it as something people can choose to use?".
The same applies to Amazon. It simply wouldn't have been possible to build something like Amazon purely on proprietary code, running only proprietary OSes and services. Even if they had, it would have been a lot less interesting. I think it's pretty clear that the world is a better place with services like AWS available. As long as they follow the licenses of the software they use, there isn't a problem, but if some licensors disagree they can always change their license.
If you want a quid pro quo, then you should have been using copyleft (or something else) all along.
To me, the fact that AWS is basing all their services OSS is a good thing for consumers. The thought of it all being proprietary is what would scare me.
I think amazon are unlikely to give up any competitive advantage they are not forced to give up.
I'm not sure I'm reading your statement correctly, but it sounds like you're saying that anything not developed under a copyleft license is proprietary.
If it was important for authors to receive contributions from derivative works, why would they have selected a license that doesn't require that?
I agree that your statement is correct.
That said, I agree with your argument, but found it rather funny that you just picked two AWS services you can indeed run locally.
Many either don't understand or don't want to take on any risk associated with some kinds of licensing or barriers in certain situations. Right now I've had to work around calling a GPL executable (pngquant), simply because we don't want to have to require it as a separate install. So switched to an alternative implementation.
It just depends on where you are, where your business is, and what you're working towards/against. It's hard to find a balance. And it will take some time to flush out. MongoDB and Redis come to mind here. They have to make some money to pay their bills and developers, also profit isn't a bad word. At the same time, huge cloud providers are offering services using their software and the devs make nothing. I get both sides here. There's no perfect solution here.
If they're going to compete on $1.28 shower hooks there's no proprietary SaaS with millions in MRR on AWS that will be too hard to copy.
When the Spectre/Meltdown hit, Amazon also open sourced the mitigation used for the AWS version of Xen ( http://xenbits.xen.org/xsa/xsa254/README.vixen )
If you search the Linux git commits for people with @amazon emails, you'll find contributions, bug fixes, etc.
I don't think it's fair to say that barely anything is contributed back.
It was announced last week during reinvent.
The fact that all of these services are based on OSS software is what will help keep Amazon in check as they continue to grow and dominate, because at the end of the day if AWS starts to turn into Oracle and get abusive with their pricing/licensing then the customer has a lot more leverage to move to another cloud or self host.
I am not holding my breath for some kind of government driven intervention, nor have I heard an idea of how that would work that makes sense. I think OSS is what is saving us here, and we should celebrate when a project becomes popular enough for AWS to offer it.
Is it fair to the developers that they don't get compensated, nope, but isn't part of the point of OSS to make sure that great solutions get reused and widely deployed?
I think companies building great software can continue to make money servicing it even with AWS in the picture, but I think if you want to make unicorn returns you are going to have to move further up the stack.
Honestly, at some point I hope we are no longer even taking about low level components like Kubernetes and Kafka and that we look back and laugh at the fact that we used to have to license and get support for these things individually. I do also hope that we manage to find a sustainable (if not equitable) model to support the development of these tools.
All the clouds are built on top of the Linux kernel and nobody really expects the kernel devs to get a cut of all those profits, but they seem to have a sustainable model for development, I hope we can continue to figure out good ways to do this for more and more OSS tools.
MSK makes sense now as Kafka has matured significantly, while Amazon has had experience in porting OSS onto their infrastructure stack (Aurora, managed ActiveMQ, EKS).
Think about it like "store brand" software. If people seem to be installing docker on 40% of AWS instances, then evolving Amazon ECS to include an Amazon branded Docker clone, effectively replacing Docker, is a no-brainer.
Seems like this is the way they are going. No need to acquire companies if you can just build infrastructure or services natively that work more easily.
Terrifying times out there for starting a software company.
The main difference with AWS vs Azure or Google is that they have been focused on the space longer and they have really optimized the rate at which they can build out a new scalable, reliable, secure, mananged service.
Sure, the UI/UX is usually not great, and the documentation is imperfect and there are features missing, but they get the hard things right, they charge per second/hour/GB, and they improve over time.
Arguably though the US Government (as a customer) has a role to actively encourage a competitive market.
This is why I recently switched to Azure. UI is a million times better, and each product seems to work. Documentation is fantastic.
AWS is full of bugs and stagnant products that overlap. It’s an absolute mess.
1. If Amazon is providing a service that is as good or easier to implement than others, people don't care enough about competition or open markets to decide based on that.
2. From the govt perspective, I'm on the front lines of the DoD cloud discussions and I can tell you that even though we don't want a single provider, and hopefully I can push hard to ensure we have multiple providers, Amazon has the mindshare in the govt and growing.
- High free cash flow businesses that other traditional industries salivate over
- Unlimited rapid scalability
- Virtually no up front computing costs and virtually elastically tied to usage growth
- Limited vendor lock-in
Yes, truly terrifying. /s
- No speed to scale advantages over FAANG
- No rapid scalability outside of a FAANG owned platform
- No advantage in new/exiting/upcoming technologies or verticals that FAANG doesn't already have projects in
All the advantages you identify also reside natively inside FAANG, while they have no barriers to scale, with a larger sales force and more easily integrated platform.
All of the factors you mentioned are characteristics of any fortune 500 business. Are you familiar with the Innovator's dilemma?
> - No personnel, pay/benefits, recruiting or technological advantage over FAANG
Says who? Don't people leave FAANG companies all of the time because they realize they have technological advantages or don't have the right people? Good example - Otto. https://en.wikipedia.org/wiki/Otto_(company)
> - No speed to scale advantages over FAANG
So let's ignore the agility and nimbleness associated with startups then? Isn't that precisely why so many software startups have been created in the last 15 years?
> - No rapid scalability outside of a FAANG owned platform
Microsoft would like to have a word with you. Ok snarky I know...I get your point. But, the rapid adoption of cloud is creating more and more cloud providers. Since lock-in is less of a problem which means we're getting more vendors with equally competing offers (just look at Equinix, Flexential, Digital Ocean, Linode, Pivotal, Rackspace, etc...just to name a few). Why do you think Azure/AWS/GCP all keep lowering their prices?
> - No advantage in new/exiting/upcoming technologies or verticals that FAANG doesn't already have projects in
What does this even mean? If a FAANG company doesn't have a project in the new/exciting/upcoming technology but you do and you prove the commercial value, then you absolutely have an advantage, no? You're there first! If, as you point out in your original post, FAANG sees that your offering has commercial value (they see more people adopting your technology) then they have to catch up to you anyway. You have a new competitor now, sure, but that is going to happen regardless of whether AWS exists or not. Is it a problem because they have the intelligence to approach the market quicker...sure. Not to mention, your ability to scale was already provided by them! Ultimately, you're complaining that the company that helped provide the scale is now competing against you? Boohoo. If this becomes such a huge problem than another provider will come along and create a "we won't compete against you" policy and change the market. I just don't see why that's such a problem.
> All the advantages you identify also reside natively inside FAANG
I think you've just proven my point. There is a level playing field when it comes to the technology services available to startups. FAANG's have a capital advantage and startups have an agility advantage. There's obviously a lot more nuance to that, but this isn't a terrifying situation at all.
My point is that you can't make a company today that will beat Facebook, Google, Amazon, Apple or Microsoft. There isn't going to be a "changing of the guard" like what happened with IBM, Sun, etc...
The "agility" of a startup, which itself isn't unique anymore, doesn't get you to scale faster than these companies anymore. They will wait for you to prove the market and then blow you out of the water. Trust me I have first hand experience here.
All the channels are saturated and you'll either get bought or crushed. That's what is scary.
Said the same people when those companies changed the guard of predecessors. Don't you remember the time when people thought Walmart and IBM were infallible?
> Trust me I have first hand experience here.
Trust me, I can cite billions of dollars that have bets (with real money) that say otherwise.
> My point is that you can't make a company today that will beat Facebook, Google, Amazon, Apple or Microsoft.
You wanna bet on that? Guess what? You can! Do you have all of your net worth tied up in Facebook, Google, Amazon, Apple and Microsoft stock? If not, then your hard stance on the matter is pretty empty.
> The "agility" of a startup, which itself isn't unique anymore, doesn't get you to scale faster than these companies anymore.
> All the channels are saturated and you'll either get bought or crushed. That's what is scary.
Bought yes. This is definitely a problem, but for other reasons than your original argument (this is bad for startups)...but I think you just proved my point - you can get bought (for lots of $$ mind you) if you compete.
That's a pretty naive view to how markets work. You can easily come up with scenarios where FAANG companies end up wrecking the scene for both startups and themselves. Stifle innovation long enough through a combination of acquisitions and lobbying government officials for big tech company legislation (e.g. this EU copyright bill, GDPR, obscure data compliance specs, etc) to ensure that nothing too disruptive can really take hold. Then just bloat like all uncompetitive companies while failing to meaningfully grow revenue for 30 years and you have a recipe for underperforming the rest of the market.
Seems like a great way to get paid for competitors to do market validation and then swoop in and clean up.
Any content provider that uses AWS is just helping to train the beast. That beast might not seem like a threat but it will begin to rival and eventually supplant and usurp its antecedent.
For what it's worth, I often recommend customers look to our partners (e.g., Elastic with their managed offering). The people who build the product will know it best. Moreover, they would be way better suited to running say a multi-cloud variant, or staying with you as you move between cloud providers.
There are still barriers though for third-parties on a cloud platform, some of which we as providers can slowly chip away at:
- Integration/Feel: You want to be in the console and feel like a natural part of the platform. This is double-edged though, because holding all partners to such a high bar (say a Google internal API review... ha!) is unrealistic.
- Support: Who do customers call? Their overall cloud provider or their specific service provider? If the customer is having trouble with their Elastic cluster, is it because we're having a GCE outage or did the customer write a query-of-death? For the latter, our front-line support won't be much help. [Edit: And you want to be able to still have a very fast "Hey! My stuff is down!" path. I think technological things could make automatic handoff here much better, but I believe it'll be "not great" for a while.]
- Economics: most service providers are going to be smaller than our largest customers. Those customers have usually signed up for multi-year commitments with high volumes resulting in a discount. If your service pricing model is "on-demand GCE pricing plus our service fee", you suddenly look over 2x as expensive to their TCO folks (just from missing Committed Use, or RIs with AWS). Unbundling the resources from the management fee would make this easier, but I've not seen many service providers attempt it.
We owe you much better docs (start here ), but we're trying to get there on at least some of these. All of the "human" factors though are still going to be a challenge, no matter how much software gets written.
The trick will be differentiating within that space. Take hosted search - AWS Elasticsearch for example doesn’t necessarily prevent companies like Bonsai, Elastic, or Searchstax from standing out for the right use cases. Most importantly these companies can provide a lot of high end support and combine with other industry focused products and services (like Elastic XPack) that Amazon doesn’t provide for the niches these companies work within.
We probably need to assume Amazon will host X thing and work to find the niches deeper in X that need to be served.
Amazon scales. Niche does not.
You are dealing with companies that have the power and money to become your main competitor overnight, and you don't know what kind of business intelligence they are gaining from you being on their hardware, and if there is espionage going on with your software and service. How honest are they being?
Judging by the size, scope, behaviors, and attitudes of the companies, I think it's turning into a risk to host on their platforms if you work in a space they may be interested into getting into.
that I know well enough to comment on
that have a culture where protecting their intellectual property is important
that wanted "cloud"
that could afford to set up their own on-premises cloud
...all of them did so.
Profiting from any marginal gain from such espionage would be deterred by the huge reputational risk for AWS, were they caught.
That said, the name of the game is "Co-opetition". Everybody is simultaneously competing and cooperating.
Going beyond that though, it does lead us to wonder at what point it would make sense for us to move off of AWS and build everything on bare-metal, using our own servers in a co-lo center, etc. Of course that takes a lot more up-front $$$, and we wouldn't have the same economies of scale as Amazon, so...
Yeah, it's complicated.
Amazon is crazy expensive. especially if you consider the far lower labour costs in most of the EU.
Kind of like taking your car to a local shop, vs going to the dealership.
If it didnt make so much sense to keep building these tools yourself you would almost be able to suggest these other companies built expensive MVPs for AWS.
There are some things though that I bet their customers are asking badly, take for example the Transit Gateway, one might thing that it is trying to put out the vendors that users use for their Transit VPC, for example Cisco, Fortinet, Palo alto to name a few, however, the Transit VPC is ugly, tough to maintain and cant scale, yes, the vendors make big money from licences for Transit VPC, but the need of a native service was there, the vendors will still sell licences, just not for Transit VPC, they will be able to focus on other parts that AWS dont prodive a lot.
i thought what Trader Joe's did was find food makers that sell products at other retailers (e.g. Naked Juice, sold for example at at Whole Foods) and then negotiate a deal with that same food maker to supply that same product to TJ's under the store label and at a lower price.
if I'm not mistaken, TJ's also develops its own product concepts (e.g. Thai Chili Cashew Nuts or their Winter blend coffee) in conjunction with some outside food makers and sells those in its TJ's stores too.
but, I'd be interested in finding some examples of where TJ's basically ripped off one of their own supplier's ideas and had it made by someone else for their store label. interesting stuff!
Trader Joe's is very secretive about who supplies its products. When I google for something like "Who makes Trader Joe's $product" I find various articles that seem like they've actually uncovered suppliers in certain cases, and I think those suppliers are pretty willing to sell a version of their existing products at TJs for lower prices. But I certainly don't know the whole story.
One other thing I notice about TJs is that it does not carry a "full" product line like a normal grocery store. TJ's often seems to cherry pick or negotiate relatively good deals from outside food suppliers where they can. And if they can't do that, in many cases, they just don't offer that product at all. Still, they offer a wide enough product line to keep the customers flowing in.
I was chatting to the CEO of a cloud product who went to reinvent and was relieved to find out that Amazon had not launched a competing product. But we both know it's a "when, not if" situation.
Part of the reason my new startup is on GCP. I don't want to AWS to have any of our internal growth numbers.
Reposting an earlier link.
Sometimes developers choose a niche that’s either directly in the path of the vendor, or even worse, on the roadmap of the vendor. In those cases, they don’t really deserve our sympathy.”
Therefore if you do not want to compete with the same platform on which you've based your solution you should make solutions that are niche specific - I believe the example was a Apple and a dentistry service, because no matter how much revenue your dentistry service made Apple would not go and copy it because it had nothing to do with their business.
Maybe this claim is not fair for DynamoDB, Kinesis, Lambda and etc. But these are just managed service. Customers could not get a binary to play around on their own server. So I could not call them software or middleware.
So their strategy is simply making the most popular software running on IaaS as a managed service, like managed Hadoop, Spark, K8S and now Kafka...
From a customer's perspective, it is pretty good since managed service just works without hassles to manage servers.
Also, with AWS's offerings you get better management with security groups etc.
2) AWS is going to build what its customers ask for. I work for a relatively big consumer of AWS services, and we have a great relationship with our customer support team, who connect us to the engineering teams building the tools we use, and without fail down to the team, they are always very interested in how they can better serve our needs and build products we want to use. And if they hear "Kinesis is fine for some things, but we really want to also do Kafka" from enough people, they will build a Kafka managed service, just like they built ElasticSearch service, a Redis service, an RDS. And why shouldn't they?
3) For customers, AWS's cost model is far better than most managed cloud services. I don't know anything about Confluent's managed Kafka offering, but having everything metered in tiny increments is a huge reduction in the barrier to entry. If we want to build on a managed Kafka platform, but we want to start slow and grow as we need, it's so much better to be able to just spin up a tiny version to try things out, tear it down, take a break for other priorities, then come back with more confidence and more experience and iterate into building something real. Whereas too many cloud services require a huge lock-in agreement up front before you can get any support, or often any service.
And it's not like the lock-in is necessary. These companies could be integrating their services to allow potential customers to leverage their AWS infrastructure. There's no reason these third parties can't use IAM credentials for authentication, and publish their services to customers over PrivateLink, a tool AWS built for explicitly this sort of purpose--to enable cloud providers to provide tight integrations with their shared customer base.
4) In terms of product quality, I don't think Confluent et al have anything to be worried about. AWS "competes" with Dropbox, technically, but is WorkDocs really serious competition? AWS's managed services have their place, but you can't use RDS to replace the flexibility and scale you can achieve by running PostgreSQL yourself. Their managed ElasticSearch and Redis products are okay, but ultimately very rigid, and nonsensical to use beyond mid-range scale. Their managed k8s service is something of a joke at this point (though I'm sure it will get better). If Confluent is truly offering a strong managed Kafka product, they will be just fine.
5) In fact, I suspect Confluent will get a lot more customers as a result of this announcement, as management at hundreds of mid-sized companies will now be convinced thanks to the AWS marketing that this Kafka thing their engineers have been begging for for years must be really key now, but they'll figure out how the AWS version doesn't quite live up and will end up being really expensive to scale to their company's needs. Then they'll look a little deeper and find Confluent. So I hope their marketing and sales teams are ready for the influx. It's coming.
I guess you don’t realize how many people in middle America would love to “tax the rich” and if you’re making six figures “they” consider you rich.
Most people only have one company offering terrestrial internet. So yeah that should be regulated. It’s considered a natural monopoly.
Companies don’t have to depend on the major cloud providers - but there are at least three major ones and IBM and Oracle are making a play. There are even smaller providers that just host VMs like Linode. I can easily imagine Linode partnering with companies to provide managed services.
On top of that cloud providers hosting servers is dwarfed by the number of companies who are using colos. There are plenty of business opportunities out there.
So no, I don’t think that you should have regulation to protect a business model. Government regulation and monopoly regulation in particular was meant to prevent harm to consumers.
But you really trust the government to have sensible technology regulation?
The government is ruled by cronyism and even worse cow tow to people’s worse instincts, superstitions, and prejudices.
The function of government is to make sure those other parts happen - that the capitalist doesn't take the money and not provide the goods (the courts, the police) or provide goods in one place at a low price by dumping toxic shit in another hurting people (EPA), tell you lies and get you to invest in their firm (SEC) or a million other examples. The burden in burdensome regulations is in the eye of the beholder.
Also remember that (at least in a democracy) we are the government. If you don't like what they're doing, vote the bums out. It's a little harder to vote out the plutocrats.
If you live in a populous city in a populous state your vote is worth much less than someone who lives in a rural city in a less populous state.
You’re also assuming as a fact that the court system and the police are not corrupt and can be trusted...
AWS faces plenty of competition. There’s a reason that the pricing schedules of the major cloud vendors are so similar.