Why shouldn’t You migrate to AWS

As strange as may appear we would like to show You why it is not worth to migrate to Amazon Cloud or any Cloud at all.

For a last few years we have a cloud boom that causes a lot of confusion, fear and competition breathing over your back.

So, why is it worth not to migrate?

 

1. Costs are not predictable in the cloud

Well.. in typical data center You buy one server or whole rack. You get Your upfront price or some monthly lease for Your hardware, then pay for electricity, then again pay for internet connection witch is normally without any data transfer limit and that’s it! If You need more hardware, You either connect with data center provider to put a new server in the rack (and lease it for the next 3 years) or ask data center provider to install completely new rack. If by any chance your data center provider doesn’t have space for new racks, you just move all your hardware to different data center provider that will have more space. In terms of other costs you always put Hyper-V or Vmware or open source hypervisor to take the full benefit of your hardware. Do never forget about your SAN network, LAN network and remember to ALWAYS have few spare disks and that’s it. Everything is so predictable. You also foresee that you will need to sell this old hardware after 3 years and buy a brand new one. It’s all calculated.

And in the cloud? Well.. here you never know. One day you might decide to have 100 servers, and another day you decide to have just 1. How possibly can you predict all that cost when paying only for what you use? And what about storage? What if one day you decide that you need extra 10TB of storage and next day you decide to shrink it back to 1TB. Network traffic? What if you need to use 1MBps one day and the other day your requirement goes up to 1Gbps. You will have to pay for this peek!

2. Servers have lower uptime in the cloud

In your own data center you always tried to have all your servers up and running all the time. Of course your reputation is based on it. You can always show your clients, that uptime of development servers that are secured behind your firewall so you don’t worry about any security concerns, is over 400 days(!). You invested a lot of time to configure all your services on key servers and they never break. Only once.. When you had to call your hardware provider to replace your motherboard, but it was just one time last year.. Oh. Yes. And that CPU in the other one, but total repair time was 4 hours so that was OK.

And in the cloud they tell you to stop your servers at night (!) so uptime is around 1 day for most of them. If something breaks they tell you to throw away your server and start a brand new one that doesn’t have problems and is fully configured to suit your needs. All the time they tell to treat all my servers like cattle while I love pets!

3. Scaling out for your clients cannot be predicted in the cloud

In your own data center you have bought 2 brand new 16 core and 64GB of RAM servers just for your MySQL/Oracle/PostgreSQL databases. They are inter connected. They also talk with farm of 10 servers that do all the application & web stuff. They are all hidden behind a brand new F5 firewall that load balance your traffic. All this is to survive your client’s black friday as during that time peek-s are VERY high. All server CPU load goes up to 80% (while normally they are just 10%). Time it took to configure all those 10 app/web servers were billed to the customer at very low rate and all that is done just perfectly (in exception of third app server that has some unknown glitches.. But we will analyze that next week..). Last year’s black friday had around 1mln unique users so I guess servers that I had last year will be sufficient this year.

How many servers will I have to start in the cloud to handle such traffic peak? Oh.. wait. How many servers will Auto Scaling start for this peek how can I answer this question when I do not know if 1 mln users will kick in or 10 mln users due to perfectly made newsletter?

4. R&D hot heads will be able to test their ideas too fast

In my own data center they had to order brand new servers and make orders for a lot more disk space to do test their innovative ideas. This led to high R&D budget and allowed us to buy cool new hardware for their needs. In most of the situations, ideas were shut down and only few of them new servers were being used so it allowed us to always have spares in case of black fridays. From idea to buying new hardware, R&D had to go thru a very long way that usually took at least 3-8 weeks. This allowed them to think their ideas more carefully and not ‘just do stuff that might work’.

What will stop R&D department from installing new servers in Amazon Cloud when they can do that in seconds instead of week-s period. How many more ideas will they be able to test? Won’t my management be less happy that they run so quickly?

5. Operation guys will have more sleep

Our old data center running model involved night shifts. This allowed my operation guys to get fresh text messages about hard drives not working or f.ex. about stopped FAN on CPU nr 4 in server nr. 8 that might cause CPU to burn out. This in turn would lower capacity of application servers from 10 to 9 and therefore lead to increased CPU usage across all nodes to spike from 5% to 6%. Our clients pay for servers to be up & running all the time so our guys needed to drive to Data Center and fix the issue. What about situations where suddenly one of application servers had a blue screen and iLO was not responsive? They also had to go there and hit the magic reset button – that’s what we called “remote finger”.

How will they sleep at night when in the cloud their cattle servers will be replaced automatically in case of failure and in case of traffic spike new servers will be started to handle such increased traffic? What if a fan burns out in… oh wait, where again? They won’t care about this as it’s Amazon’s responsibility.

6. You will have to hire expensive AWS experts

In your own data center you had your good linux/windows admins that did most of stuff using self-written scripts, and other stuff using their own hands. They were sure that everything worked smooth! They went on night shifts, evening shifts, morning shifts, noon shifts. When one of them left your company for unknown reasons you were pretty confident that you will need to re-do most of work after the old admin as new admin does it differently.

In the Cloud and IAAC (Infrastructure as a code) model you will have to hire one or two AWS guys that will setup your infrastructure and this in turn will allow you to take everything down one day and start it fresh right up on the next day. Their total work time will be way lower than your linux/windows admins who created your ‘pet’ linux/windows in a course of few months (and kept their perfectly long uptimes). So.. what will happen to the guys who are just admins and have no will to think in DevOPS model? And how can 2 good AWS specialist-guys handle work that was done by my 20 linux/windows administrators and have good night sleep?!

7. AWS Cloud is not as secure as your own Data Center

In your data center you used to have ability to walk into Data Center and see all those guards, see how the cooling system works, look at UPS-es and see how much fuel they have in case of outages. Security of your own rack was also a masterpiece – you had to be on the “magic” list, and your fingerprints were analyzed before you were even able to open your rack. And you had your route to your rack remembered. Your CTR guy knew the same route when he fixed your not working hard drives and they always knew where to sign the papers in order to get to the Data Center. Drives that he replaced were always kept at your place. There was no need to encrypt your traffic between your load balancers and other servers as it was your own. You spent couple of thousands on HSM that encrypted your servers.

In Cloud you have no idea on which floor your server is, you have no opportunity to see the data center itself. You almost never know when your underlying disks fail. You should have all your data encrypted between even load balancers and your application servers. You have possibility to encrypt your data at rest, you can use cloud HSM that goes in pay as you go model (again!). Disks that get damaged are cleaned up and they get only the highest certification of PCI DSS 3.2 Level 1 Service Provider & ISO 27001. In case of global failure you can instantly move to other Availability Zone or even to other continent. How can you compare cloud to your own precious data center?


So, if despite all of the above facts you’re still crazy enough to go to the AWS cloud as we were, irrespectively if you’re not frightened by lower initial costs, cheaper PoC infrastructure setup or autoscaling doing the magic for your e-commerce, we’ll be more than happy to give you all the support need!

 

Contact us at contact@tameshi.eu for more details.