cheesgrateron

I think you must have a limited mindset of how long it can take wheels to turn in large companies. Without cloud, it's not uncommon for the F500s I've worked at to take literal months (90+ days) just to provision and stand up a new server for an application team to even begin developing on. Even if you spend time "debugging black boxes" (which is highly debatable), most of the time you're still moving a lot faster with cloud than before.

Some companies are better than others. One place I worked had a decent OpenStack implementation in their own data centers, and it greased the wheels a little bit (though it was not without its own issues). And of course smaller companies are likely more agile and able to move faster. But for the most part, these big companies see some very real benefits in speed by embracing public clouds.

On the contrary, I'd say if you're not re-architecting your apps every couple of years then you're at risk of falling behind.

I'm not talking about rebuilding everything from scratch, but making an active effort to do self introspection and ask yourself "we built this app 3 years ago with certain requirements in mind and chose stack X to host it, but a lot has changed in the past 3 years, both in our requirements and in the technology landscape. Should we still be using stack X or does something else fit our needs better?" is unequivocally a good practice.

Any of the companies I've worked with (and I've worked with many) are large enough and have been around long enough to understand that re-architecting apps, doing lift-and-shifts, re-training employees, or anything like that is an inevitable cost of doing business that is going to happen every couple of years no matter what, so any time fretting about "lock in" would ultimately be a waste of time.

And perhaps more importantly to these companies, lock-in is more than worth it if it means benefiting from some real revenue or cost optimizations. Paying $3 to "unlock" from a platform is more than worth it if said platform gave me $5 of benefit.

>I think AWS is early to offer a not-yet-matured product just to get it in front of customers and start gathering real usage feedback.

It's not just this. In many cases, the services launched are essentially MVPs that were only created to serve a handful of customers' needs. If a huge whale of a customer says they want hosted Jupyter notebooks on AWS (just a theoretical example I picked because I saw someone criticize Sagemaker, but I don't have any specific knowledge of Sagemaker), then AWS will create that for them, but, AWS doesn't actually do "one off" services for a specific customer, so they will also launch those hosted notebooks as a public service.

The result is of course that this service was built with one customer's use case in mind, so it might not serve other customers' use cases very well, which leads to some negative perception. But ideally AWS then goes and incorporates feedback into the service, turning it into a "tier 1" service rather than an MVP. It just takes time.

I've worked as a consultant in this area for years with large F500 companies and not once have I heard anyone actually be concerned with the "lock in" boogeyman. There used to be a lot of concern around general trust of the cloud, which drove people to stick to on-prem servers. But "lock in", IME, is only something people fret about on HN.

What I think is happening is that companies are starting to gain more experience in the cloud and are less intimidated by it. In the past, using just one cloud was scary enough, let alone trying to use 2+ at the same time. But now, with more experience under their belt, companies are realizing that each cloud has its own advantages and disadvantages. AWS is rock solid when it comes to EC2, S3, RDS, Lambda, and some others. But if you have some teams in your company that want to use a PaaS, GCP App Engine is preferable to AWS Elastic Beanstalk. Similarly, your data science or AI/ML teams might prefer to use GCP services over AWS. Or maybe your risk management team is going the full stretch for disaster recovery and says not only do you have to be multi-region within one cloud, but you are required to be multi-cloud as well.

With companies moving this way, I think this is AWS realizing that multi-cloud is inevitable, so they might as well support it, if not embrace it.

>I am not interested in any certifications and such

ACG is very focused specifically on helping you pass the certification exams. It can still be helpful even if you don't want a cert because naturally there is some overlap between passing a cert and knowing how to use AWS/GCP/Azure, and one great thing about ACG is access to the AWS playground environments where you can get hands-on experience. However, if your goal is to ignore the cert and really learn the material, you might look elsewhere.

That said, the ACG courses for the basic level AWS certs really don't take more than a couple weekends to go through, and at only $25/mo, it's not a bad investment to just pay for 1 month, get the foundational level knowledge, then move on to other ways of learning.