3 ms·
Good info. You are right, AWS can cost more, but I disagree with "always". I run my personal website for $15/year, and most of that is the domain. I would say
by ldoughty 8y ago
Good info.
You are right, AWS can cost more, but I disagree with "always". I run my personal website for $15/year, and most of that is the domain.
I would say: if you're trying to list and shift to AWS, you're doing it wrong, and it will always cost more. You also can't really fire many people aside from pure network guys. Server admins will still be needed for the virtual servers.
If you take the opportunity to redesign, you can realize cost savings. I still advocate avoiding layoffs, because you can retrain competent ops people to support the new infrastructure. The grizzled old guys that have trouble adapting are still usefull because chances are high you are not fully serverless within 3-5 years after a lift and shift.
As you become more familiar, you realize the tweaks that can be made to save money. We used to spend $600/month on 3-4 concurrent CICD workers. We swapped to docker-machine Spot-based CICD and spend $100-140/month for 12+ concurrent workers (we started at 6 and keep raising this number because the costs simply are so small)
Our front end is all static files (JS driven API calls). The $100/month server is now under $5 month for S3+CloudFront.
So I agree, AWS always costs more if you are trying to replicate a physical data center and ignore all the possibilities for improvement... But with slight tweaks (even starting with auto scaling.. or even more simply, timed lambdas to turn on/off servers overnight), you can reduce costs. Migrating to containers is also a huge cost savings, since you can pack more work into fewer servers without worrying about as much (I lived the nightmare of virtualenv's and managing 12 apps on 1 server.. I prefer containers now as an ops guy)
- scarface74 8y agoMy goal and marching orders are to use AWS managed services for anything possible. We (the CxOs and myself) agreed that out of all of the business risks we had, our dependence on AWS is the least of them. For builds we are completely serviceless. We use CodeBuild with mostly the prebuilt Docker images and one custom image to build some .Net Framework code. We use CodePipeline to deploy lambdas with CloudFormation and Code Deploy agents for EC2 instances. For any new work, we have to justify a need for servers instead of using lambda for both APIs and back end ETL work loads - with step functions. There are a few back end workloads that we will need to transistion to Docker eventually but even then we are looking to use Fargate.
- mooreds 8y agoI have liked Corey Quinn's advice about saving money in the cloud. Here's a tweetstorm about the topic: https://mobile.twitter.com/QuinnyPig/status/1091041507342086144 https://mobile.twitter.com/QuinnyPig/status/1091041507342086...