If you are running in the cloud then you still need a devops guy same as you would if you where bare metal. In fact you will probably need _more_ devops people the deeper you get into the AWS ecosystem.
If you are running in the cloud then you still need a devops guy same as you would if you where bare metal. In fact you will probably need _more_ devops people the deeper you get into the AWS ecosystem.
Granted, we're a mature startup and have put a few years of investment (at the cost of 2-3 "Devops Guys") into our infra, but ultimately it doesn't take much to manage a ton of AWS infra once the tooling is in place.
Terraform and the fact that I came in with experience makes this doable. But only just.
They were capable of scaling in a way that is certainly an anomaly, and not indicative of the costs of an ordinary team.
It speaks volumes about what the right talent and architecture/technology choices can do if leveraged successfully, but is more of an interesting anecdote than a realistic infrastructure budget.
That’s a pointless calculation. The acquisition wasn’t for the employees. As with all network-effects products, the acquisition was for the active user base. They could have acquired WhatsApp, fired the engineering team, rewrote it with an architecture that required 100x the servers and still been happy.
The instances we use are not the largest (we use 2xls) but we also incorporate spot instances as part of our autoscaling.
Everything is a tradeoff.
You can manage things efficiently in AWS if you do it right. You can manage metal efficiently if you do it right.
You can kill your business if you do either one wrong.
Every place that I have worked it’s the responsibility of the team who wrote the code to create the CI/CD pipelines.
Dang, I wish we had a term for this blending of roles...
But still ops serve developers not the other way around. The senior developers who knew AWS well, basically set the standards and kept ourselves accountable to the ops guy we hired, even though any of us can override him because of our influence in the company.
I started taking away some of my own access and privileges just so I would be the first to hit roadblocks to feel other developers pains who weren’t given the keys to kingdom.
Hiring "DevOps" teams completely misses the point, in the same way that I don't hire Unit Testing teams to write the unit tests that my Devs don't want to do the grunt work for.
When a Dev understands Ops they write more efficient code, as they realise what storing your entire DB in cache really means for the server.
But at least three of the senior engineers (including me) I feel could hold our own against any “specialists”. My experience are too many of the “specialists” are old school netops people who got one certification and treat AWS like an overpriced colo.
I'm a software engineer who went the specialist route because it does take real skill to do this well. Yes, I am embedded on a team of old school netops people now, but I'm in charge of all of this and I get to drag them kicking and screaming in to the modern world.
Specialists are worth it if you find the right one.
Old school netops folks are so afraid of becoming less relevant they do their best to keep control. But at least they are harmless compared to the ones that have tried to transition to the cloud. They are actively harmful costing clients and companies more with little to show for it.
And no I am not young. I’m 45 and started programming in assembly in the 80s.
“lift and shift” should be phase 1. Not the end goal.
The cloud formation code is (likely to be) much less than your application code. ... and if your intention and need is to have couple servers, then you don't really need any infrastructure code. If these cases, yes bare metal is much cheaper and (probably) better option.
This does not make any sense. You don't need cloudformation or anything, you can just use a wizard and provision as many VMs (baremetal or otherwise) as you need. It's literally a form and next -> next -> next.
Now that you have systems you can login to, their complexity is the same – except you won't have to care, or manage any hardware.
You still have to manage those systems yourself. Keep them patched, secure, and the workloads up. It's your choice whether or not to delve deeper into the AWS ecosystem.
Note that even though I said you don't need cloudformation (actually just use Terraform instead), you have a lot of power at your disposal if you do. You can't automate racking and stacking of physical servers, but you can fully automate the lifecycle of a cluster of VMs. At my job I can bring up a 40+ cluster containing many kinds of workloads, with a single butotn press. And destroy it just as easily (for non-prod). That's invaluable.
Depends upon the number of servers you have.
Back when I worked on several somewhat popular websites ( a handful with ~1-5mil daily unique users), we had about 40 servers and they mostly took care of themselves. Between me (primarily a developer) and the CTO we averaged maybe a single day thinking about hardware per month, and that was mostly to install new hardware rather than taking care of existing stuff.
If you have this number of servers, once you have something like Ansible setup (we used cfengine back in the day, ugh), both hardware and software mostly manages itself.
I set up an EC2 instance behind a load balancer and set it to auto-scale. done. If I had to handle that bare bones, I would have had to upgrades switches, manage dozens of servers, deal with hard drive failures, etc., and most of that would be idle 99% of the time.