Smash Company Splash Image

August 26th, 2019

In Uncategorized

2 Comments











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

High Availability is not compatible with a MVP, because MVP is about fast iteration

(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?

I responded on Twitter:

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 High Availability.

I think of High Availability as implying multiple servers, multiple load balancers, multiple failover databases, multiple data centers, multiple regions. Lots of redundancy, probably configured for failover.

Beware of perfectionism and maximalism. 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. He felt certain that his product was going to be the next Pokemon Go:

Beyond being a global phenomenon, Pokémon GO is one of the most exciting examples of container-based development in the wild. The application logic for the game runs on Google Container Engine (GKE) powered by the open source Kubernetes project. Niantic chose GKE for its ability to orchestrate their container cluster at planetary-scale, freeing its team to focus on deploying live changes for their players. In this way, Niantic used Google Cloud to turn Pokémon GO into a service for millions of players, continuously adapting and improving.

First of all, that’s rare, and second of all, does it actually matter if you lose a few customers because of a few dropped connections? Most of my clients seem to believe they are in markets where they must support uptime of 99.9999999%, even though most of my clients could have 98% uptime during a spike, and it would be fine in the long-run.

In the case of my client, the public didn’t like the MVP. Which is a common experience. 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; there is nothing “minimum” about it.

For a new startup, fast iteration is important. As Steve Blank says, you’re looking for product/market fit. Every variation of your product is a new experiment. 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 — don’t waste much money on any one idea, till you have reason to believe that the public likes your idea.

You want fast iteration of your business idea, not fast iteration of a devops setup. You want agile product development, not agile devops resource use. Once you have product/market fit, it is nice if you have fine-grained control of devops resources, because you can save a few dollars that way, but it’s not the kind of money you should worry about when you’re still trying to find an idea that the public likes. Small optimizations should wait till you are a stable and mature organization.

Fast iteration of extremely minimal products allows you to test many ideas — you thus decrease your risk of failure. 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.

I’ve previously been critical of certain devops strategies, especially Docker/Kubernetes. People have pushed back against my criticism, they ask, “If it’s good enough for Google then surely it is good enough for us?” But Google is a stable and mature company, so it is appropriate for Google to optimize its devops setup, to increase efficiency and lower costs at scale. Are you running a large, mature, stable company? If yes, this essay is not written for you. I’m writing for small startups launching an MVP.

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

You have to balance the risks, based on what your company really needs. I’ve a good friend at a startup who found a co-lo data center in a small college town in Virginia, where they were able to build out a massive MongoDB database, sharded across 4 massive servers, each server holding 256 gigabytes of RAM, 1 terabyte of RAM in total. They also had a Cassandra database and several servers for their front-end. They were paying $7,000 a month for this. The co-lo center was conveniently close to where their devops guy lived. Then the devops guy quit. Because the co-lo center was in this small town, they had to hire another devops person who was also in this small town, which was a limited market to hire in. The company decided that they could lower their risks by moving to AWS, because then they would be able to hire a devops person who lived anywhere. So they re-created their setup on AWS. Suddenly they were paying $35,000 a month. Yes, their bill went up 500% for the same setup. Co-lo is often much cheaper than the cloud, but you do face the risk of being location dependent. This can be a good risk for some companies, and a bad risk for other companies. You need to think carefully about which risks you really need to mitigate, and remember that it is impossible to mitigate all risks.

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.

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 (VM) 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, you can use Terraform/Packer. Your resource use will end up being course-grained, compared to the fine-grained control you get with Docker/Kubernetes, but most startups do not need the fine-grained resource control that Docker/Kubernetes makes possible.

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.

I wish I could say that this problem only happened at one of my clients, but in fact, nearly every client I’ve had these last few years have been swept up in a kind of perfectionist mania, chasing after expensive (but flawless!) implementations of ideas that had not yet been tested against real customers. This is not the correct way to build a company.

Beware hosted solutions that promise to remove all the devops pain from your life. The CEO felt certain that if Robots And Pencils could Dockerize the app, then it would be easy to achieve infinite scalability via AWS’s Fargate service. While that service is very good, and scales very well, it also turns out that you still need to write auto-scaling rules! Which they never got around to, because by the time they got to that point, they realized their app was not popular with the public. So they spent considerable money trying to achieve “easy scaling” and they never quite got there. Even more sad, or futile, or wasted, is the fact that their server app is a completely self-contained Go binary, with all dependencies included. So they could have easily achieved infinite scaling without Docker.

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 some mix of Ansible and Terraform (assuming you want to be in the cloud).

Whether you go bare metal or the cloud, 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, because MVP is about fast iteration of the main idea, not fast iteration of some devops strategy.

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:




RECENT COMMENTS

2 COMMENTS

August 26, 2019
10:39 pm

By Joshua Hoover

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

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>