Smash Company Splash Image

October 5th, 2017

In Technology

1 Comment

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

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.

Source



Check out my book:





RECENT COMMENTS

February 20, 2019 10:41 am

From Just An Observer on Don't waste your life on Twitter

"A couple of my favorite bloggers started doing twitter. Instead of permanent additions to knowledge, there is..."

February 20, 2019 3:24 am

From Brennan on Did sleep paralysis start the Salem Witch Trials?

"If you have occasional sleep paralysis, you can take steps at home to control this disorder. Start by making s..."

February 19, 2019 11:09 am

From Ryan Earp on Why I prefer dynamic-typing over static-typing: the speed of adapting to change

"If static typing lead to greater programmer productivity (via a reduction in bugs) then corporate Americ..."

February 3, 2019 2:32 pm

From ruurd on Argument about attraction and sexuality and trans

"wait wait wut? what's the liberals doing here?..."

January 18, 2019 10:22 am

From Justin McGuire on When will the era of CyberPunk end?

"The reason cyberpunk doesn't die is because it all came true. From Noah Smith on twitter: "The cool thing a..."

December 16, 2018 9:06 am

From lawrence on Yair Lapid: What does it say about us that Israel has become the only democracy in the world in which Jews don’t have freedom of religion?

"Cat Mara, thank you for catching that. I've fixed it now. (The URL was a "v" by mistake. Looks like I was tryi..."

December 12, 2018 7:50 pm

From lawrence on Object Oriented Programming is an expensive disaster which must end

"Jussi Nurminen, thank you for writing. I believe you are correct, in the sense that Python 2.x had all the bas..."

December 12, 2018 5:13 am

From Jussi Nurminen on Object Oriented Programming is an expensive disaster which must end

"Hello! I've lately became a bit more suspicious of OO designs (including my own), so I read your original 2014..."

December 4, 2018 9:22 am

From lawrence on Docker is the dangerous gamble which we will regret

"GK, thank you for writing, but I don't understand what you mean when you write: "However, at that point you..."

December 4, 2018 7:14 am

From GK on Docker is the dangerous gamble which we will regret

"A development VM is a fine choice, provided that it comes with tools that make it just as easy to run commands..."

November 30, 2018 7:04 pm

From lawrence on Docker is the dangerous gamble which we will regret

"GK, thank you for writing. About this part: "That thing is writing portable shell scripts. The moment you n..."

November 30, 2018 1:41 pm

From GK on Docker is the dangerous gamble which we will regret

"The fat binaries article was nice, but full blown fat binaries are not really necessary. Whats needed is that ..."

November 27, 2018 1:13 am

From lawrence on Object Oriented Programming is an expensive disaster which must end

"Andres Moreno, thank you for writing. Among other points to be said, I'll say I'm almost heart broken about Py..."

November 26, 2018 9:11 pm

From Andres Moreno on Object Oriented Programming is an expensive disaster which must end

"I am stunned! Why did it take so long to show that the Emperor has no clothes? I got bit by the Lisp bug early..."

1 COMMENT

August 21, 2018
11:48 am

By Nanacy

Very good post.

Please have look for AWS and DevOps Training online or corporate http://www.a2info.com.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>