Earlier quoted context omitted.
Did you reserve your instances? Were you using current generation instances (c3, m3, etc). Did you try to take advantage of traffic patterns to scale up and down the number of instances you were running?
We had reserved instanced and regular ones, we did not see any patterns in stability issues between those. Re: instance types - I do not really remember which instances we were using to be honest. And as for the scaling up and down - we had a hard time keeping it all up as it was, we did not want to spend resources trying to make it work with constantly changing node pools (though I understand, that it would push us…
How and Why Swiftype Moved from EC2 to Real Hardware
171–180 of 194 posts
Re: How and Why Swiftype Moved from EC2 to Real Hardware
#172Earlier quoted context omitted.
Can you elaborate why not ? You can get some cheap dedicated hosting (ex: [1]) for a fraction of the price. It's so cheap compared to AWS you can order a few spare ones and still come out cheaper than your one beefy AWS instance ? The only way it doesn't make sense is, if you need to scale up and down very fast ? [1] 60 euro/month: Quad-Core Haswell, 32 GB (non-ECC) RAM, 240Gb SSD @ https://www.hetzner.de
Hetzner is fantastic but if you're not in Europe, what's your latency like?
Re: How and Why Swiftype Moved from EC2 to Real Hardware
#173Earlier quoted context omitted.
I would like to know the cost calculation after a year or two. With a handful of servers it's easy to get the false impression that HW failures are rare.
We have 100 physical servers and hardware failures really are very rare. Very rare. In fact over 4 years we have only had 3 hard drives fail and no other hardware failures.
Re: How and Why Swiftype Moved from EC2 to Real Hardware
#174You can...
1. Make your own hardware
2. Own/manage your own hardware
3. Rent commodity hardware from a standard hosting provider
4. Use IaaS (e.g. EC2)
5. Use PaaS (e.g. AppFog, Nodejitsu)
6. Use BaaS (e.g. Firebase, PubNub, Pusher.com)
The higher the level, the more technical flexibility you lose. The bigger the company, the more it makes sense operate at a lower level because there is no significant wastage being introduced as you move down the levels (you remove the middlemen so you can pocket their profits) and the capital cost to move between levels is relatively low.
If you compare software to another industry like cheesemaking for example, if you're a cheesemaker and you want to make your own milk, the next step is to buy the whole farm and then you have to figure out what do do with the meat (wastage). Going between these two levels is expensive and could mean doubling or tripling your expenses so it's not an easy move to make.
Re: How and Why Swiftype Moved from EC2 to Real Hardware
#175Earlier quoted context omitted.
If you're a small org with relatively small volume self-hosting doesn't make sense.
Can you elaborate why not ? You can get some cheap dedicated hosting (ex: [1]) for a fraction of the price. It's so cheap compared to AWS you can order a few spare ones and still come out cheaper than your one beefy AWS instance ? The only way it doesn't make sense is, if you need to scale up and down very fast ? [1] 60 euro/month: Quad-Core Haswell, 32 GB (non-ECC) RAM, 240Gb SSD @ https://www.hetzner.de
Re: How and Why Swiftype Moved from EC2 to Real Hardware
#176Interesting article, thanks for sharing. We actually just went the exact opposite because of the larger scale issues we were having with Softlayer. Do you feel like you lost any resiliency by making the switch to physical servers (more virtual instances on one physical server, servers in the same rack, etc)?
No, I really do not think going to EC2 could be beneficial in any way in terms of improving resiliency compared to Softlayer. SL allows you to control which VLANs your box will end up on. VLANs could be treated as racks (since they do not allocate more than one VLAN per rack). Then you have multiple DCs in one region (e.g. DAL01, DAL05, DAL07, etc) and you have many different regions (DAL, SEA, WAS, AMS, etc). I'd be…
Aside from that it was mainly nit-picky type stuff, but still things that were annoying (networking issues between DCs, networking issues between pods, internal mirrored apt-get repos going out of sync, API is kind of blah, etc).
We use docker so having a few bare metal machines with tons of containers on them wasn't a great HA setup (for us at least), even running in two data centers. The fairly quick setup time though was a nice selling point.
When we went to AWS things just kind of worked. The API was easier to use and the GUI portal was way nicer/stable. So far we have not had any odd issues with our instances, but we also typically run them at about 50% capacity so that might be why. It is also still early so maybe things will come up in 6+ months that send us back to SL :)
Re: How and Why Swiftype Moved from EC2 to Real Hardware
#177Re: How and Why Swiftype Moved from EC2 to Real Hardware
#178Earlier quoted context omitted.
> There's not much need for a fancy article on a fancy website in order to understand a key concept of cloud computing: I wish it were true, but plenty of companies are gripped by cloud fever. I've seen quite a few going down the route of charging into the cloud not because they've run the numbers and found it stacks up, but because they want to be in the cloud, and Amazon have some great marketing people.
Sounds akin to the outsourcing binge that went on a decade (?!) or so back. Back then it seemed most companies did it not because they had done the numbers, but because a few big names had done it and so the others did it to apparently piggy back on the stock markets attention.
Re: How and Why Swiftype Moved from EC2 to Real Hardware
#179Earlier quoted context omitted.
> There's not much need for a fancy article on a fancy website in order to understand a key concept of cloud computing: I wish it were true, but plenty of companies are gripped by cloud fever. I've seen quite a few going down the route of charging into the cloud not because they've run the numbers and found it stacks up, but because they want to be in the cloud, and Amazon have some great marketing people.
Sounds akin to the outsourcing binge that went on a decade (?!) or so back. Back then it seemed most companies did it not because they had done the numbers, but because a few big names had done it and so the others did it to apparently piggy back on the stock markets attention.
Re: How and Why Swiftype Moved from EC2 to Real Hardware
#180Earlier quoted context omitted.
> There's not much need for a fancy article on a fancy website in order to understand a key concept of cloud computing: I wish it were true, but plenty of companies are gripped by cloud fever. I've seen quite a few going down the route of charging into the cloud not because they've run the numbers and found it stacks up, but because they want to be in the cloud, and Amazon have some great marketing people.
Often times companies move because their organization doesn't deliver, and the hope is a cloud company will do a better job of it. If you have a great team, I firmly believe hosting yourself is far, far, far less expensive. If you have a terrible team, then cloud (hosting) is less expensive. Even if it was exactly the same cost, you're gaining by not having to have a staff to run it, and the costs of managing them, e…