August 26th, 2019

# High Availability is not compatible with a MVP

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

Samy Dindane asked me a question:

How would you deploy a simple React/NodeJS app?

Deployment is a big question but I’ll try to summarize. First, ask yourself, do you need to High Availability? When I ask CEOs of early stage startups, they always say “Yes” yet I think only 10% really need to High Availability.

I think of High Availability as implying massive redundancy and multiple failover databases, multiple data centers, multiple regions.

A recent client of mine had raised $5 million then hired Robots And Pencils and spent$1 million to build their MVP, and the CEO insisted on High Availability. Yet the public did’t like the MVP. And the “M” was a lie. If you go for High Availability, then “M” is a lie. Unless it’s redefined as “Maximum”. High Availability is excessive.

The whole point of a Minimal Viable Product is that the public might not like your first idea, that’s why you keep it minimal, you might need to iterate through multiple versions before you get something that the public likes. An MVP is an experiment, and fast iteration of extremely minimal products allows you to test many ideas — you thus decrease your risk of failure because you are increasing your ability to test many ideas, and thus find something the public is really going to like.

High Availability is a symptom of perfectionism, and as such it is the absolute opposite of an MVP.

Which startups need to be Highly Available, right from the beginning? Startups doing finance, actually handling money, or startups doing security. That’s it. Unless you’re handling money, or protecting money, you don’t need to start with High Availability. Get there slowly. It’s a nice ideal: when you are big and successful then you should eventually implement it. But don’t start with it.

That means you don’t need massive redundancy in some cloud strategy. You can consider bare metal servers, which can be very, very cheap. Or have you priced a co-lo center? It’s surprising how cheap they can be.

If you avoid High Availability, your setup can be very simple. Bare metal servers, and then deploy an uberjar, or a fat Go binary, or some other easy system. If you have multiple microservices with internal dependencies, you can write a deployment script in Jenkins, and this will still be simpler than a Docker/Kubernetes setup. Much simpler.

Not that you have to go with bare metal, I only mention it because it’s faster and cheaper than many of my clients seem to realize. If you want to be in the cloud, you can. And Terraform/Packer gives you an easy way to setup a standard virtual machine that your developers can use.

Terraform/Packer is an easier way to get what developers typically use Docker for. If you want an easy way to scale, you want isolation, easy deployment, security, a standard development environment, plus an AMI that can be spun up many times in AWS, use Terraform/Packer.

Terraform means you’re still working with a standard Virtual Machine, which you can run in VirtualBox or Vagrant, as well as run on AWS as an AMI. You can work with something standard, that you’ve probably been using for the last 10 years. You can setup a standard Virtual Machine that runs Linux or Windows, and that means you can stay with the environment that you have many years experience with, using tools that you’ve used for years. By contrast, if you instead use Docker/Kubernetes, you are launching into an adventure that involves a still new eco-system which is still somewhat immature and is still undergoing rapid evolution. If you really want to be loyal to the spirit of MVP, building something really minimal, then avoid Docker and Kubernetes. They are an advanced optimization, and therefore they are not MVP.

I mentioned the client who paid Robots And Pencils $1 million to build their MVP? The CEO at this client said, “The public is going to go wild over our product, once they see it, so we need to be ready to scale quickly. I expect we’ll have 10 million users within the first 6 months.” But in fact, after a year, they had 40,000 users, and that was after spending another$1 million on marketing. But hey, their app was Dockerized and set up in AWS Fargate, so they were ready for 10 million users, whenever those 10 million users decided to show up. None of this followed the real spirit of an MVP: there was nothing minimal here, instead, the project was contaminated with maximalism and perfectionism — the two biggest enemies of an early stage startup.

My basic point is, Docker/Kubenetes brings in a whole new ecosystem, with a lot of new worries, but you can get all the benefits via older Virtual Machine tech, and then script those older Virtual Machines with Terraform (assuming you want to be in the cloud).

Whether you go bare metal or EC2, MVP should be about a simple approach to devops.

High Availability is a beautiful ideal and every company should work toward that. Eventually, it is something you should achieve. Once you have proven product-market fit, then you can focus on reliability. But should a small startup begin with that, before you even know if the public likes your product? I say, leave High Availability till later. Don’t start with that. High Availability is not MVP.

Source

Check out my books:
"I wish I could go back," said Anna. "I guess I thought it would always be there, and I could go back and learn more when I was older. But now I'm older and it's gone."

"All the great art scenes are like that," said Mariah. "Renoir's career was half over before the term Impressionism caught on. And Fitzgerald and Hemingway had given up on the Left Bank long before the place was overrun by talentless hacks who wanted to imitate the Lost Generation lifestyle. And the Beats had mostly left San Francisco before busloads of visitors started to do tours of the Haight-Ashbury. When Johnny Rotten couldn't work with the Sex Pistols anymore, he left and the London punk scene began to die. Later on, he said he regretted his decision to leave. Everyone thinks they can go away and come back later, but they never can. When Joan Didion and her husband left New York, she quipped that some other couples were staying too late at the party, but that gets it all backward. The party ends whether you want it to or not, and it takes an unusual arrogance to celebrate the end of an era that some people will remember as the best years of their life. Hemingway lived in Paris during his twenties, but he didn't write about his experience in Paris until he was in his sixties. No one ever knows they're part of an art movement; it's something you only see afterward."

"But if we only see it in retrospect, then how can we find the next great art scene?" asked Anna. "What do I look for?"

Also read this true story about a startup I worked at in 2015:

September 2, 2019 11:58 am

"Chrisco, thank you, this is a great comment. You raise the point of MySQL in Docker, but you have to provide a..."

September 1, 2019 8:12 pm

"I live in the Java world. Since about 2000 all my web apps have been deployed into what have been known as "ap..."

August 29, 2019 5:39 pm

"This is a fantastic story. There's something deeply harrowing in the sentence "[then] I took Amoxicillin for 1..."

August 27, 2019 1:53 pm

"Joshua Hoover, I strongly agree. I've previously advocated for Heroku, which was the pioneer in the serverless..."

August 26, 2019 10:39 pm

"Agreed on HA not being a part of MVP. It's waste. The MVP is one step closer to discovering you have to do som..."

August 21, 2019 8:47 am

"Hi there and I agree completely but I can resume as follow: Docker promises simplicity, i.e. IT IS EASY. ..."

August 20, 2019 2:29 pm

"Which is fine. Like I said, there are dance scenes that have strict “no alcohol” rules. That might appeal to y..."

August 20, 2019 1:35 pm

""Promise of an early bed" - the whiff of danger keeps me away from many venues like the one you describe...."

August 20, 2019 12:22 am

"I think any time you go to any club there is the possibility of running into an angry person, maybe a person w..."

August 19, 2019 7:56 pm

"I'm confused. You and your friends went out, had a fight, and it's still a great place to go to? Maybe..."

August 18, 2019 8:57 pm

"You seem to have little patience for people who choose different tech paths than you. Although it looks like o..."

August 18, 2019 8:53 pm

"You don't suffer slights well, do you? Others who choose to waste time with dumb tech, do they keep you up at ..."

August 18, 2019 8:34 pm

"Me again. I've worked for a company that focuses on containerized applications for some time now. There is abs..."

August 18, 2019 8:00 pm

"To build on my last statement, I'm not trying to show that I'm "smarter." I'm probably not, or if I am, who gi..."

August 18, 2019 7:48 pm

"You think that containerization is going anywhere? I agree that it isn't strictly necessary, but you mistake y..."

August 26, 2019
10:39 pm

Agreed on HA not being a part of MVP. It’s waste. The MVP is one step closer to discovering you have to do something different, which all that money spent on HA could’ve gone towards.

One quibble. I’d suggest serverless as the path of least resistance these days. Let someone else run all your infrastructure. It’s relatively cheap, “scales to zero”, and even makes HA a little closer should that MVP take off like a rocket ship and require something more robust. :-)

August 27, 2019
1:53 pm

By lawrence

Joshua Hoover, I strongly agree. I’ve previously advocated for Heroku, which was the pioneer in the serverless space. Back in 2016 I wrote “AWS is inappropriate for small startups because its complexity demands a specialist” and in that essay I wrote:

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 LSQ.io, 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.

I said “serverless isn’t there yet” but it has come a long way in the last 3 years. Nowadays You can find a hosted service for almost anything you might need, including Cassandra, so the need to do these things yourself is gone. Nowadays the only question is cost.

http://www.smashcompany.com/technology/aws-is-inappropriate-for-small-startups-because-its-complexity-demands-a-specialist