Why we double down on AWS and the cloud

Blippex.org published a blog post yesterday why they moved away from AWS. In the blogpost and HN discussion we recognized a couple of important points were missing in favor of AWS or cloud services in general. Here is Codeship’s take on the topic.

Full Disclosure: We know the guys from Blippex very well as they are also from Vienna.

Blippex’s blog post didn’t mention that the team behind blippex has been working on their former company, Archify, for a few years. The technology behind Archify evolved into what is currently blippex. At this point they know and understand their infrastructure needs. Thus a self managed hosting became an option but would probably have been hard to do before when building the infrastructure.

AWS helped them a lot in the past to be able to experiment and build the infrastructure they need, as they mention themselves.

From the ensuing discussion on the blippex blog and Hacker News two main points were missing.

Speed of innovation is how you win

For a startup speed of innovation trumps everything else. Getting your MVP out the door as quickly as possible has to be priority number one. And building on top of that MVP until there is product market fit needs to happen quickly.

With this in mind being able to create, destroy and change servers at will is not just nice to have. It becomes essential to spend the least amount of time on maintaining and building servers and the most on building the product, marketing and everything else necessary to build the company.

Being able to focus on the growth of your business early on is way more important than infrastructure cost optimisations. We made the cost optimisation mistake ourselves a couple of times and lost lots of time that we could have invested in our growth.

AWS or other cloud hosting providers might be more expensive when only compared on raw power. The flexibility they give your team to focus on what is important for your business is way more important and will determine the success of your product and company.

Codeship – A hosted Continuous Deployment platform for web applications

AWS is great with Automation, stupid without it

We rebuild our complete infrastructure nearly every day. Cloud infrastructure and good automation give you these abilities. As Max mentioned himself:

The biggest downside is not to be able to start new servers just with a mouse click :)

This is one of the major upsides of AWS and not just a side note. And it’s not just about scaling to 10x traffic, although that can be helpful. Cloud servers are not 24/7 machines. They are building blocks that should be treated as immutable and volatile.

Considering an EC2 instance as a normal server that you ssh into and apt-get update/upgrade is plain wrong. Even Amazon says so. Building servers through automation is key. Everything can be and should be automated.

Take for example one comment made on Hacker News:

that somehow that instance of Linux running in EC2 doesn’t require the same maintenance as a physical one. It does.

It really does not if you do it the right way. Start by automating every step necessary to get a server up and running from a barebone OS. You can then store those images as EC2 AMIs. Now whenever a server starts to misbehave you simply destroy and replace it.

While it is technically possible to get there with netboot on self managed servers you have to sacrifice a part of your current infrastructure if you want to rebuild a server. With the cloud there is no sacrifice, as you simply launch new instances. This is a very different world.

Recently new tools have come up to help manage cloud infrastructure. We started looking into Packer over the weekend and will be switching to it for our test server deployment over the next couple of days.

And Packer is just one of a number of tools that make managing modern cloud infrastructure a lot easier. We will talk about some other tools we use like Vagrant or Ansible in the future.

Conclusions

AWS is expensive when you compare only the raw server costs and do not use reserved instances. But that premium lets you focus on building your product far more than going with a self managed machine. Especially for early stage startups or projects this makes all the difference in the world.

As this was a big discussion yesterday on Hacker News we’d be interested to know what you think. Feel free to add your thoughts in the comments.

Subscribe via Email

Be sure to join 13,643 subscribers of our newsletter to receive updates on software development best practices, Continuous Delivery and tips and tricks to start shipping your product faster.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • KW

    “The biggest downside is not to be able to start new servers just with a mouse click ”

    This is a mistake on their part. Being able to click / script VMs is a must-have capability on owned hardware, not just in the cloud.

    • https://www.codeship.io/ Florian Motlik

      Agreed. It makes all the difference in the world to scale up/down or rebuild anything on your servers.

      • Jessica Darko

        Yeah, you’ll get a low performance VM that you can turn on with a click connected to EBS for the same price as a dedicated machine on which you can run (And start/stop) a dozen known performance VMs.

        And you say that’s better?

        Your position isn’t even honest.

  • Pingback: Why we’ve doubled down on AWS and the cloud | Rocketboom()

  • machikakara

    One thing that i have learned is to built my hardware like a private cloud. I dont like cloud pricing i find it wrong and unfair in most cases A good week or two allows me to setup kvm virtualization and scripts that I can use to bootstrap a new dedicated server and add it to my kvm cluster and then the same thing is with just using configuration mangment to keep my vm’s alive i am able to have custom hardware sata or sas were i want it at the size i want it and ssd where i need it. Not trying to do amazon math to figure out what size machine I think i need.

    • https://www.codeship.io/ Florian Motlik

      >A good week or two

      that’s a long time that you could use to focus on building the necessary application or talk to customers. For lots of times setting up your own hardware is a good choice, but often times it seems physical hardware is used because someone can, not because someone should or planned it through.

      And I think this is a problem that a lot of tech teams face and then struggle or even fail.

      • machikakara

        I think when companies cant spend time focusing on their infurstucre early on they end up writing HN posts on how they had to change X to Y because of performance issues. To many times do developers push so far forward to develop there product that when they are left with scaling issue they are then rushing on how to scale. They end up having to develop automation systems later in the game when they could have already been in place.

        Dont get me wrong 2 weeks of development is a good amount of time. Its a great amount of time to be speaking to customers people and investors. With out code you just have an idea, without soild infeatucture your left with code and an idea but no platform, the amount of money saved by building out your own servers and understanding your servers because you built them out and not paying that to another service is well worth it. I have seen companies drop 6 figures monthly to pay for servers on amazon but they could have spent 1/4th of that if they were on hardware and could have hired 3 developers each month with the money saved, and those developers could write more code.

        • https://www.codeship.io/ Florian Motlik

          >the amount of money saved by building out your own servers and understanding your servers because you built them out and not paying that to another service is well worth it

          the problem is that most companies don’t make it to this point. If you build the infrastructure first chances are you don’t have time to focus on getting customers and revenue. Then you are stuck with technology that no one uses.

          Scalability is a luxury problem. If you need to rebuild parts of your system because people are using it like crazy and you get major traction that’s a great thing. Optimising for that situation from day one is a lot of wasted time though

          • Jessica Darko

            Yes, rather than use off the shelf servers from hetzner, and have good performance, and focus on product and traction, you’d rather someone make themselves dependant on AWS and spend all their time trying to figure out why EBS is returning data with latencies on the order of SECONDs.

            You picked Amazon because of ideology, and now you’re trying to pretend like it makes good business sense. This is cargo cult repetition of nonsense from people who don’t know how to do a startup at best.

            Choosing non-performing, highly customized systems that you have to spend a lot of resources getting to work– e.g. AWS– and that will let you down and drive away your customers, does not make it easier to get traction.

            and saying otherwise is absolute nonsense.

            You act as if you can’t just rent a bunch of servers at hetzner or any number of other hosts.

            Completely asinine.

          • https://www.codeship.io/ Florian Motlik

            Your comments contain no substantial contribution, but only personal attacks.

            While I don’t have a problem with your personal attacks on me I will not accept your personal attacks on my team. We have great and hard working developers here who put all of their time into building a great product.

            You can ask any of the thousands of developers using and paying for our product how well using AWS or the other technology choices we made work for them.

            As you do not seem to be interested in any meaningful discussion we will block you from any further interaction on our blog.

      • Jessica Darko

        This is the most asinine and dishonest thing you could say. You’re saying, rather than using the things you already know, using off the shelf hardware from a host like hertzner, we should spend several WEEKS building automation on top of AWS, and become beholden to the pricing they dictate, get lower performance and constant outages, becuase it makes us more agile?

        If you think AWS makes you more agile and gives you more time to spend on your product or customers, you’re simply lying to your self.

        Constant outages, terrible, randome performance and a bespoke API you have to learn (and your recommendation of building automation on top of all that) …. all take away from creating real value.

  • Mengu

    Thanks for the post and I have a question.

    >> You can then store those images as EC2 AMIs. Now whenever a server starts to misbehave you simply destroy and replace it.

    How do you deal with database servers then? What kind of instance you are using?

    • thomas whaples

      I’ve seen good results for certain workloads using medium-to-large instances, storing data on disk in instance storage and doing replication (including cross-region replication) to insure against the instances being trashed.

      And, of course, crazy-backups, and really good testing of the backup-and-restore process. But you’re doing that with your database anyway… riiight?

      (Of course, the database infrastructure also needs to be able to efficiently bring a new node up to speed, if you hope to replace nodes effectively.)

    • Jessica Darko

      I’m sure, because they have more money than sense, they put their DB into a proprietary Amazon service, you know, rather than running a half dozen dedicated machines at hetzner or some other much cheaper hosting service and getting better performance at lower cost.

      Don’t ask these guys pesky problems about database servers, they don’t even understand the concept of distributed solutions.

      They are incompetent, so they presume that everyone else is as well.

      • Darren Sherwood

        Guess they didn’t get around to blocking you.

    • https://www.codeship.io/ Florian Motlik

      We use the Heroku Postgres Service. It’s terrific and let’s us focus on building our product.

  • Praveen Kumar. Muppala

    When you have a continuous deployment, recycling, high autoscaling, Everything available at your doorstep in Amazon AWS. We are in great favour of running the customer applications. We have migrated 10’s of E-Commerce applications and 100’s of Social media websites to the cloud. They are happily living there with great cost savings. For some reasons like : Business model, revenue, application usage cloud will not be a suitable like as mentioned blippex.

    • https://www.codeship.io/ Florian Motlik

      Yes, sometimes there are obvious problems with going to the cloud, but too many teams don’t use the cloud just because they don’t want to. Going cloud should be the default choice and only if you have to do you should be going to your own hardware

      • Praveen Kumar. Muppala

        Myth :-
        Lot of people thinks that Cloud will solve all their hardware, monitoring,scaling, backup and cost problems.

        Truth :-
        Cloud will bring the new challenges in managing your application,data, scaling. If you are not expert enough cloud will cost you like anything.

        I don’t agree only hardware is the concern to move to the cloud. There are 1000’s of applications in my notice are designing, developing and building for cloud ready in Iaas and PaaS.

      • Jessica Darko

        NO. People don’t use AWS because they don’t want monthly outages, terrible performance and to pay thru the nose for the privilege, while being locked into a proprietary API.

        The bottom line is, you’re just incompetent, and since other people have chosen a superior solution, you don’t want to admit it, so you’re smearing them.

        Really when you have to be so dishonest, how can you expect anyone to believe you?

  • Jessica Darko

    Let me get this straight– you’re saying that if you create a layer of automation on top of AWS, then it becomes usable and fast. Except, you can create a layer of automation on top of any number of other hosting services– all of which offer you better price/performance than AWS. Many of which can give you the agility to do what you want, without having to learn (and be locked into) a bunch of proprietary amazon APIs.

    Amazon is like google– there’s a certain group of non-technical people whose ideology is wrapped up in the idea that they are superior, so no matter how much reality disagrees, they will bitterly cling to their faith.

    If you aren’t doing short term jobs that need thousands of machines, then AWS is a waste of money, and you should get fired for recommending it.

    Since irrational faith, or ideology is what you’re making decisions on, rather than the facts of reality, you’re by definition, a bad employee.

  • http://www.gigaom.com/ barb darrow

    Dump question. MVP means ???

    • https://www.codeship.io/ Florian Motlik

      MVP = Minimum Viable Product.

      The minimum feature set that you need to get your product into customers hands so it gives them value and they want to use it, while you can iterate with customer feedback.

  • Pingback: Amazon Web Services: should you stay or should you go? — Tech News and Analysis()

  • Pingback: Amazon Web Services: should you stay or should you go? | 8ballbilliard()

  • Pingback: Amazon Web Services: should you stay or should you go? | Earthgrid()

  • Alex G

    How can you explain that using a really huge instance like CR18XLarge will cost around 2500$/Month if you use it at 100% ??! it’s really expensive. if you look for something similar that you can buy, you will pay something like $12.000 that you can pay off in 3 years. As a result, you will pay $4000 a year or $333,33/month. It means that you pay 7,5 times your server. Do you think that this kind of cloud is only for elastic workloads ? Do you also think that the range of services provided by aws justify this factor 7,5 ?

    • https://www.codeship.io/ Florian Motlik

      For our use case being able to quickly scale up/down all the time, so a high level of elasticity, is very important. Additionally if you factor in all the time and money it will cost you to keep your hardware running it’s not that expensive to be in the cloud.

      But most importantly we are a small startup and want to focus on building our product, not unnecessarily maintaining the infrastructure. We’ve selected the Cloud and we are using hosted services because they work for our business model and give us the ability to focus as much as we can on building the product. This is way more important than driving the price down a bit. Especially in the beginning while building the product.