Smash Company Splash Image

June 11th, 2016

In Technology


If you enjoy this article, see the other most popular articles

If you enjoy this article, see the other most popular articles

If you enjoy this article, see the other most popular articles

AWS is inappropriate for small startups because its complexity demands a specialist

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

Sean Hull references a conversation that he and I had in Slack. I would like to expand on the argument that I made then. You might want to read his essay first, where he makes these points about AWS:

1. Over 70 services offered

2. Still complex to build high availability

3. Need a dedicated devops

4. Orchestration involves many moving parts

5. Troubleshooting failed deployments is difficult

At the time of our conversation I had crashed an AWS instance and we were having trouble fixing it. Among the points I made to Sean was that the problem was specific to AWS. If we’d been in the Rackspace cloud, I simply would have rolled back to yesterday’s image. A problem that would have taken 5 minutes to fix instead dragged on for 2 weeks. We became embroiled in a mystery no one could quite figure out. I even went to the great popup office that Amazon now maintains in New York (a fantastic resource), and I spoke in person with 2 AWS engineers, and they were unable to come up with a definite answer about what was wrong. To his enormous credit, Sean had the best guess of anyone, and when I followed his advice, the problems stopped (a problem starting with carrying over a root harddrive from one EC2 instance to another).

I’m about to mention some simple server setups, but I first want to say, if you are just starting out, consider using Heroku. That is the absolutely simplest way to get started with an app on the Web, and ” absolutely simplest” is almost always what you want when you are just getting started.

At the last few startups where I’ve worked, I’ve insisted on using the Rackspace cloud. It is fairly simple and straightforward. The interface is simple. A mediocre developer can figure it out in 20 minutes. This simplicity is a powerful feature! We should not underestimate it!

Though I strive to be the most amazing programmer that I can ever be, I am not striving to be the most amazing devops guy in the world. And yet, at very small startups, the lead developer is typically also the lead devops guy. I’ve already written of the drama that went on at Celolot last year, yet despite the many, many problems that we had there, we never had any devops problems. And that is because I was in charge of devops, and our needs were simple, and I managed everything through Rackspace. Rackspace made it easy for me to create an image of my servers each night, and when we needed additional development servers, we just spun up a new one from an existing image. Simple.

I can handle basic Linux devops. But AWS is not Linux devops. AWS has become its own specialty. With over 70 services offered, only a full-time AWS specialist can properly understand how to build something in AWS.

Some of you, reading this, will be tempted to say “You are only complaining because you are ignorant about AWS!” But that is exactly my point! Knowledge of Linux devops does not translate into knowledge of AWS, and for most small teams, they only need basic Linux devops. What AWS offers is overkill!

Some of you will say “Hey, if you need something easy, just use the EC2 service and ignore the other 69 services.” But it isn’t that simple. The problem that Sean Hull and I spent 2 weeks figuring out is a problem that exists when dealing with virtual servers, but not real hardware servers. Play around with EC2 instances enough and you will run into those cases where they are different from a physical machine.

Last year we built a system with an architecture similar to what Matthias Nehlsen has written about — we had some Clojure apps that talked to each other over Redis. So I set up a simple Redis server. Please note: I did not setup a cluster. We didn’t need that yet. We just needed a simple Redis server. So I spun up a basic Linux server, installed some packages, spun up Redis, secured it, and I was done. It took less than hour, perhaps as little as 30 minutes.

Recently I was working with a team that had to build a data ingester, to pull data from multiple 3rd parties. I was working with an inexperienced team, so I taught them the basics of how such a system would work. I created this humorous illustration, which we reviewed together:

Again, even though I am not a devops guy, I took on the role of devops to set this system up. But this team had already committed itself to AWS, so I figured I would do this the official AWS way. How do I set up Redis in AWS? Immediately I run into this:

and this:

Ugh! It’s a bit more than I need right now!

Please note, I’m not saying AWS is bad! I think AWS is wonderful! For a big company with a dedicated devops guy, AWS is awesome. Or if a medium sized company has the budget to call in someone like Sean, then AWS is awesome. But for a small team with no dedicated devops guy, AWS is inappropriate. Because over and over again it forces you to think about complexities that you don’t yet want or need to deal with.

Again, if you are just starting out, think about something like Heroku. It’s the easiest way to get started.

Last week I was talking with my friend Chris Clarke. He runs devops at Parsely. Their servers are all at AWS. Their frontend is written in Angular, and it makes calls to ElasticSearch. Chris told me he was running a 62 node ElasticSearch cluster, which stores over 100 terabytes of data. No doubt, when you are working at that scale, then AWS is very useful. But you need someone with the incredible skills of Chris Clarke, and that is a rare thing. And specialized. Small startups don’t normally have/need/want a devops guy of that skill level, because the devops needs of small startups tend to be minimal.

And of course, there has been a trend to reduce devops in small startups to nothing at all. Heroku started that trend, mostly for the Rails crowd, but then for other technologies. More recently, there have been companies such as, run by the very brilliant Antonio Pellegrino. If you are working with NodeJS, then you should be using LSQ — they give you a fantastic way to test, deploy and monitor your NodeJS apps.

And yet, the serverless movement is not quite 100% there yet. Heroku and LSQ are awesome, but if you need a Cassandra database then you need to set that up yourself. Someone like me, if I was running a small startup, I would offload what I could to such services as these, but for any special thing that my startup needed, I would spin up some servers in the Rackspace Cloud and I would install whatever packages I needed, and I would customize it myself. I am not a devops guy, but I can do all the basics that are typically needed at a small startup.

What I can’t do is deal with the vast complexity of AWS. I don’t have the time. I’m busy building software, and I need to learn the algorithms and technologies needed for my software. Learning AWS is, at this point, its own specialty, and therefore AWS is only useful to companies once the company is big enough to hire a full time devops AWS specialist, or at least big enough to have the budget to bring in someone like Sean on a regular basis.



Post comments on Hacker News


Check out my book:


July 14, 2020 8:53 am

From lawrence on How I recovered from Lyme Disease: I fasted for two weeks, no food, just water

"In my experience, yes. I have made it common to do a 3 day fast a few times a year. Anecdotally, I would say i..."

July 13, 2020 3:07 pm

From Tes on How I recovered from Lyme Disease: I fasted for two weeks, no food, just water

"Thank you so much for sharing your story. I have recently been diagnosed with Lyme disease and want to treat i..."

May 31, 2020 9:03 am

From Gábor Hidvégi on What does PHP offer now?

"Dear Lawrence, I can agree with you partially, but not in the whole at all. I agree with you that even P..."

May 22, 2020 12:43 pm

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

"Good article. However I hate to see so called "SOLID Principles" conflated with OOD. SOLID is a form of cargo ..."

May 22, 2020 10:29 am

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

"The first time I looked closely at OOP I was astonished at the – idiocy, the absence of any usefulness, the ad..."

May 13, 2020 5:03 pm

From Just+An+Observer on His Girl Friday

"Closest match to the intensity of this is the movie "Twentieth Century" with John Barrymore and Carole Lombard..."

October 19, 2019 3:08 am

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

"I really enjoyed your article. But i can't understand the example with the interface. The example is reall..."

October 17, 2019 4:50 pm

From Anderson Nascimento Nunes on The conventional wisdom among social media companies is that you can’t put too much of the onus on users to personalize their own feeds

"Can't speak for anyone else, but on my feed reader: 5K bookmarked feeds, 50K regex on the killfile to filter o..."

October 9, 2019 3:08 pm

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

"Object-Oriented Programming is Bad"

October 4, 2019 8:44 pm

From lawrence on My final post regarding the flaws of Docker / Kubernetes and their eco-system

"Gorgi Kosev, I am working to clean up some of my Packer/Terraform code so I can release it on Github, and then..."

October 4, 2019 5:14 pm

From Gorgi Kosev on My final post regarding the flaws of Docker / Kubernetes and their eco-system

"> Packer, sometimes with some Ansible. The combination of Packer and Terraform typically gives me what I ne..."

October 4, 2019 12:40 pm

From lawrence on My final post regarding the flaws of Docker / Kubernetes and their eco-system

"Gorgi Kosev, about this: "I would love if you could point out which VM based system makes it simpler and..."

October 4, 2019 7:31 am

From Gorgi Kosev on My final post regarding the flaws of Docker / Kubernetes and their eco-system

"I won't list anything concrete that you missed, because that will just give you ammunition to build the next a..."

October 4, 2019 1:39 am

From lawrence on My final post regarding the flaws of Docker / Kubernetes and their eco-system

"Gorgi Kosev, also, I don't think you understand what a "straw man argument" is. This is a definition from Wiki..."

October 4, 2019 1:23 am

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

"Alistair Bayley, that is valid criticism. Still, in my essay on Object Oriented Programming, I did suggest the..."


Pingback: WEB OPERATIONS WEEKLY NO.70 | 科技与人文的十字路口

November 20, 2017
2:21 am

By Mark

I think in this case you are confusing your experience with doing things a certain way, and your lack of experience doing things another way, as meaning one is easier (universally) than the other.

I say this as a developer (ie not dev-ops) that has transitioned from the ‘linux admin’ style setup you mentioned, to the AWS focused one.

Using your own example, now that I have knowledge of both approaches, I would find it much easier to use for example AWS Lambda than whatever approach you use to make workers. Once you have a system for piping your queue to your workers, AWS handles the scaling of the workers itself. It’s insanely easy compared to the ‘old way’.

February 26, 2018
1:52 pm

By Richard Remer

If the AWS way already works for you, then it’s useful. But if the AWS way does not, it’s like pulling teeth to get anything done.

For example, our workers are in PHP, using the Laravel framework. So, if I want to take advantage of the AWS way, I need to figure out how to get Laravel bootstrapped in Lambda, which is excessively complicated, error prone, and a nightmare to maintain.

All of our system configurations are stored in Github and are completely versioned, and restorable. Except for the AWS configuration, which lives in the “cloud” and is impossible to reproduce without creating ever more layers of management software on top.

95% of the time, AWS is the wrong tool.

February 26, 2018
4:58 pm

By lawrence

Richard Remer, thanks for writing. I agree, it is often best to simply have a powerful server. I think the cloud is over-sold. There are some really wonderful tools in AWS, but the real benefits are for companies that are big enough to have full-time devops staff, as keeping up with the ever-changing AWS world is something that only specialists can do.

Leave a Reply

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