AWS does not protect you from devops(smashcompany.com)
smashcompany.com
AWS does not protect you from devops
http://www.smashcompany.com/technology/aws-does-not-protect-you-from-devops
15 comments
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.
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.
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.
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.
[deleted]
"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.
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
[deleted]
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.
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.
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.
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.
>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.
This last bit alone shows the author doesn't really know what/how DevOps works.