AWS does not protect you from devops | Hacker News Reader

AWS does not protect you from devops

smashcompany.com

47 pointslkrubner13 comments

It sure doesn't protect you from devops at all. What it does do is allow you to take your small devops team of 3-4 and allow them to operate at tremendous scale.

The bulk of the article was based around ElasticSearch, which is one of their more awkward-feeling services (for instance, locking down by IP address takes several minutes to deploy, whereas the rest of their services are configurable via security groups in seconds)

I don't think the AWS story has been protecting you from devops, but rather, protecting you from infrastructure.

Not all AWS services are created equal. Not all have the same sizes of team/funding/investment into new features.

As a customer, I pay one bill. If you look at the pricing of services that are just value adds atop EC2 (like ElasticSearch and ElastiCache) it seems that AWS seems they are comparably mature.

>There might be reasons to use AWS, but please don’t use it because you think it’s going to save you a money that you would otherwise waste on devops. If you use AWS, your contractors will still end up doing a great deal of devops.

This last bit alone shows the author doesn't really know what/how DevOps works.

Google Cloud provides way more hosted services that do protect from devops. App Engine is fantastic (though it can be pricy). Similarly BigQuery "just works" vs. Redshift's need to choose instance sizes and scaling policies. Nearline is zero effort vs. Glacier's need to issue restore requests. (and Google seems to have a better container story too) Also GCS has multi-region buckets (and I believe GCP auto-migrates VMs too). You can do multi-host shared FS more easily, etc.

I don't agree with this article. Lets say a company was managing a mysql like database by themselves which would require a full time database maintainer doing all sorts of devops work. However, if company moves to AWS and starts using RDS, it might only need a part time db maintainer. So company indeed save some devops work like pushing security patches, monitoring etc.

How would running a single MySQL service require a full time dba?

I agree this article is fallacious making the investment in devops a binary choice. Of course in aws you will need some whether through aws Support contracts, your own hires or somewhere in between.

>How would running a single MySQL service require a full time dba?

"Enterprise". I've seen guys who manage a single SQL server with 300 users or a share point install of a similar size "full time".

Sad :( I bet these people have multiple “full time” jobs.

And yet, my current client is using RDS, and they still have devops work, in terms of ensuring that the failover is setup correctly, the tables are correctly indexed, the IP whitelist is kept up to date, etc.

You could argue that using RDS means they face less devops work than if they ran MySQL on their own dedicated servers. That might true in some aspects, but then, with RDS, you also need to keep track of some issues that are specific to AWS. Availability zones, regions, management via console versus the AWS CLI, management of the keys, etc. So there is the question, which you must ask yourself, and your team, do you want to be learning skills specific to the technologies you are using, or do you want to be learning skills that are specific to AWS? Would you like to deepen your knowledge about MySQL, or would you like to instead spend time memorizing the various decisions that Amazon has made?

I'm not suggesting that there is a right answer, but I am suggesting that the answer is much more muddy and nuanced that Amazon's marketing suggests.

"So there is the question, which you must ask yourself, and your team, do you want to be learning skills specific to the technologies you are using, or do you want to be learning skills that are specific to AWS?"

If you are running a commmodity product like MySQL with the AWS hosted offering, then AWS is effectively replacing the network, server hardware and server OS layers that your organization would have to acquire and manage some other way. It is definitely true that it requires a different set of (non-trivial) knowledge, but the time and cost of acquiring them is significantly lower than for learning equivalent on-premises infrastructure. The MySQL knowledge is more of a fixed constant, since you need that regardless of how you host the databases.

It is definitely true that if you invest AWS/Azure/GCP, then you still need some Ops-orientated people, and many developers don't have much interest in it. There is an issue of Dev and Ops being different mindsets.

Has devops just come to mean, uh, ops? lol

Reply on news.ycombinator.com