AWS does not protect you from devops

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

Once upon a time, people made fun of Linux GUIs because they would give you a graphical way to edit a configuration file, but you still had to know everything in the configuration file, and what the settings did. People made the reasonable point that slapping a pretty graphical interface on a configuration file did not make it any easier to work with Linux.

Nowadays, the clients I interact with say things like “We want to use AWS because then we won’t have to spend so much money on devops.” This is a victory for Amazon’s marketing. The reality is that Amazon offers a graphic interface for configuring complex systems, but you still need to understand the complex systems. Amazon is not actually hiding the complexity from you, Amazon simply makes it a little prettier.

I wrote about this a year ago in AWS is inappropriate for small startups because its complexity demands a specialist.

That post sparked some interesting conversations on Hacker News.

I’ll expand upon the point here, based on work I’ve been doing this week.

Recently I’ve been working on an app to write a few million small JSON documents to ElasticSearch on AWS. I get a lot of SocketTimeout errors and, more surprising, JVM OutOfMemoryError errors. To be clear, it is AWS that is throwing the JVM OutOfMemoryError errors. ElasticSearch is written in Java, and it is the ElasticSearch instance on AWS that is throwing the JVM OutOfMemoryError errors. Apparently the task of figuring out the appropriate level of hardware needed for my app is entirely on me. AWS does not auto-scale the ElasticSearch service. Which is to say that the crucial devops work is still my responsibility. AWS is not helping here.

It took me days to track down the AWS documentation that explains why I was seeing this error.

So I reconfigured the ElasticSearch cluster:

And I set up a bunch of dashboards and alerts to let me know when something goes wrong with this cluster:

The expensive thing about devops is that you need to learn a lot about configuration. That takes time. Time is expensive. And when I use AWS, I still need to learn a lot about configuration. For example, how many instances, of what size, do I need to use before I stop getting JVM OutOfMemoryError errors? The only way I can find out is trial and error. Amazon is not helping in any way here. I’m still spending time on devops tasks.

Among my frustrations, Amazon does not emphasize the errors that I was seeing. Check out the Troubleshooting page:

I would guess that there are more developers who have made my mistake than who have been tripped up by Kibana. Writing too much information too quickly and getting SocketTimeouts and OutOfMemory errors is probably a common mistake, especially since one or two million small JSON documents really should not be a lot for AWS. There are surely a few developers out there who started their projects with the naive belief that a default AWS cluster would be enough for a fairly minor task?

More so, Amazon does put some interesting obstacles in my way which would not exist if I was working with raw hardware. For instance, I have long known that Amazon has a load balancing service, for websites, and that load balancing service dislikes sharp spikes — its much better at gradual changes in volume, rather than sharp changes. I wouldn’t have thought they would use the same balancing in front of its ElasticSearch servers, but that does seem to be true — when my app first starts writing to ElasticSearch, the app faces frequent disconnects and so I see SocketTimeout errors in the logs, but after 3 or 4 minutes the app can write about 15,000 documents a minute. And this implies that they are load balancing:

“Your performance can also be impacted if your application isn’t sending enough I/O requests. This can be monitored by looking at your volume’s queue length and I/O size. The queue length is the number of pending I/O requests from your application to your volume. For maximum consistency, HDD-backed volumes must maintain a queue length (rounded to the nearest whole number) of 4 or more when performing 1 MiB sequential I/O. ”

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.

===========================
===========================
===========================

Follow the conversation on Hacker News.

Post external references

  1. 1
    https://news.ycombinator.com/item?id=11884507
  2. 2
    http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-handling-errors.html
  3. 3
    http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-troubleshooting.html
  4. 4
    http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html
  5. 5
    https://news.ycombinator.com/item?id=15413018
Source