Enough people are still trying to make fetch happen, where fetch is container orchestration, that I expect that fetch will indeed eventually happen, but this is a large vig for getting around not-a-lot-of-management-work (because the competition isn't Kubernetes, which is the bin packing problem returned to eat your wallet, it's EC2 instances, and there is a little management work but not much and it scales).
If you have decided that you want to undertake the bin packing problem, AWS's ECS or the new Elastic Kubernetes Service makes some sense; you're paying EC2 prices, plus a small management fee (I think). I don't understand Fargate at all.
$0.0506 per CPU per hour
$0.0127 per GB of memory per hour
Under this economic-incentive-system lens, I'm curious whether new AWS services might also be intentionally started out with high premiums, as a sort of economically-self-limited soft launch. Only the customers with the biggest need will be willing to pay to use the service at first, and their need means they're also willing to put up with you while you work out the initial kinks. As you gain more confidence in the service's stability at scale and matching to varied customer demands, you'd then lower the price-point of the service to match your actual evaluation of a market-viable price, to "open the floodgates" to the less-in-need clients.
S3 select will likely let me delete a lot of custom code.
I’d be willing to pay a premium but this is just not cost effective.
Want to scale up/down when you have high or low load? Cool, configure it at the ECS service level AND at the auto scaling group level. Will the auto scaling group take instances away before they’ve been drained of connections or randomly? Who knows the systems don’t talk to one another to coordinate: Fail
What about just removing a node from the cluster when it fails? Decrease service count min temporarily -> Drain connections elb -> remove from target group -> kill instance. This is a 5-10 minutes process to do correctly that should be 1 click. Same problem, stuff doesn’t talk.
Want to update to a new ECS optimied AMI to get updates and patches but ensure a minimum of core services keep running while you scale down after you’ve scaled up? Good luck!
The cheapest seems to be more than $40, but based on the description its only allocated $5 to $10 worth of computing. I am using Linode or Digital Ocean pricing for that, but even with Amazon's inflated EC2 pricing it's probably like $25 max.
So I can't justify paying $40 per month when I can get the same horsepower for $10 or $20. I can set up an open source system for monitoring and containers restart automatically.
For people that have $200,000 burning a hole in their pocket, it may be a different story.
Start simple and take care of your scalability problems when you have them, not before.
What you don't get is all their regions, easy scalability with EBS, managed services, etc. But all of that has a very high price, and depending on who you are and what you're trying to do, these cloud providers are probably the worst option.
For build and test tasks... sure scalability would be needed.
What would you suggest, scaleway seems to have poor APIs for automation, and atom CPUs so not useful..
I'd rather have two T2's than one M4 for most web services, or 8 T2's over 4 M4's etc. for both better performance, reliability and price. T2's are the best bang for your buck by far, as long as your service scales horizontally.
t2's are for really bursty workloads, which only makes sense for a webservice if you aren't handling much traffic in general and you have maybe 2 instances total.
FWIW this is, unfortunately, a pretty common description of many low traffic Rails apps.
We have been serving around 10 million web requests / day per t2.medium. Not lightweight static files or small json responses, actual dynamic pages with database load. Our servers mostly sit around 20% though.
Might not be that much compared to larger web services but we have a localised audience so nighttime cpu credits get collected and used during peak times. So it fits our workload. They are great value when the credit system work in your setting.
Have a grafana dashboard constantly monitoring credits and have alerts in place though. But haven’t had a sudden issue that we needed to manually remedy.
This, otherwise your infrastructure will come grinding to a halt at the worst time. It's a potential DoS vector in that way too, if you're relying on charging up credits overnight to handle traffic during the day.
If you use t2's for anything important, keep an eye on the CPU credit balance.
With T2 Standard auto-scaling based on the CPUCreditBalance can be a really bad idea, because the rate at which an account can launch T2s with an initial credit balance is limited. If your application has a bug that causes a health check to fail, the ASG can quickly burn through your launch credits by cycling the instances, and then it's possible for your health checks to keep failing because the later instances start with a CPUCreditBalance of zero.
We just released T2 Unlimited in part to solve that. In this new version all instances start with a zero balance, but none are ever throttled and you can do a sustained burst immediately at launch: https://aws.amazon.com/blogs/aws/new-t2-unlimited-going-beyo...
> T2 Unlimited instances have the ability to borrow an entire day’s worth of future credits, allowing them to perform additional bursting.
What does this mean? Specifically, what is meant by "borrow"? Do they have to be paid back? Does the next day then have fewer credits?
We removed the direct relationship between credits and 24h cycles, so your current usage no longer affects tomorrow's balance: https://forums.aws.amazon.com/ann.jspa?annID=5196
I think it's a misnomer to call it expensive or compare using a more abstracted service like Fargate vs something more granular like EC2.
If I need a service that lets me prototype, build a product, be first to market, etc. splitting hairs over compute costs seems moot. Not to say it isn't interesting to see the difference in pricing or how AWS quantified how to set pricing of the service.
FWIW, if you watched the Keynote stream, the theme of it was literally "Everything is Everything" and a bunch of catch-phrases basically meaning they've got a tool for every developer in any situation.
One other note: From my experience I'd also argue it's often times easier to migrate from fully-managed to more-self managed services than the other way around. By nature of owning more operations, you make more decisions about how it operates. Those turn into the pain-points of any migration project.
Trying to run a DCOS/marathon or K8s cluster is not trivial. Last time I looked, every service out there basically spun up a Docker machine with some auto-magic cert generation.
Surely there are other services out there which will just run containers, allowing you to deploy from a k8s or marathon template? What are the other options?
Most AWS services IME offer a fair amount of portability. My high-level point is: I just want tools to build things. Not to obsess over the tools I use the build them.
That said, I don't have specific enough domain knowledge to answer your questions or suggest alternatives.
> For example, your service uses 1 ECS Task, running for 10 minutes (600 seconds) every day for a month (30 days) where each ECS Task uses 1 vCPU and 2GB memory.
> Total vCPU charges = 1 x 1 x 0.00084333 x 600 x 30 = $15.18
> Total memory charges = 1 x 2 x 0.00021167 x 600 x 30 = $7.62
> Monthly Fargate compute charges = $15.18 + $7.62 = $22.80
So the total cost for 5 hours of running time is $22.80? Am I even reading this correctly? If so, what would this be cost effective for?
$0.0506 per CPU per hour
$0.0127 per GB of memory per hour
(1 * 2 * 0.00021167 * (600/60) * 30) + (1 * 1 * 0.00084333 * (600/60) * 30) = 0.380001
Because that's much better than the original:
(1 * 2 * 0.00021167 * (600) * 30) + (1 * 1 * 0.00084333 * (600) * 30) = 22.80006
When I think about the offerings this way, I can start to decide when I want to use them because now I can ask myself "Do I need strict temporal/spatial control over my application?" and "Do I think I can optimize temporal/spatial costs better than Lambda/Fargate?".
Meanwhile, in AWS, you already have pre-sized blobs of RAM and compute. They're called EC2 instances. And then AWS pays the cost of the extra inventory, not you. (To forestall the usual, "overhead" of a Linux OS is like fifty megs these days, it's not something I'd worry about--most of the folks I know who have gone down the container-fleet road have bins that are consistently around 20% empty, and that does add up.)
You may be the one percent of companies for whom immediate rollout, rather than 200-second rollout, is important, and for those companies a solution like Kubernetes or Mesos can make a lot of sense. Most aren't, and I think that they would be better served, in most cases, with a CloudFormation template, an autoscaling group with a cloud-init script to launch one container (if not chef-zero or whatever, that's my go-to but I'm also a devops guy by trade), and a Route 53 record.
You're basically paying overhead for the privilege of `kubectl` that, personally, I don't think is really that useful in a cloud environment. (I think it makes a lot of sense on-prem, where you've already bought the hardware and the alternatives are something like vSphere or the ongoing tire fire that is OpenStack.)
And it doesn't cost anything to use.
 - https://github.com/eropple/auster
 - https://github.com/seanedwards/cfer
Our job is not just to automate servers, it's to automate processes, including stupid developer-facing ones.
I've definitely been burned many times by adding an extra tool or layer meant to make things easier, that ends up not, for all manner of reasons. I think we all have.
We used to use troposphere, a Python library for generating CloudFormation templates, but have since switched back to vanilla CloudFormation templates now that they added support for YAML. We're finding it's much nicer to read and write in plain YAML. We're also now using Sceptre for some advanced use cases (templatizing the templates, and fancier deployment automation).
YAML and sensible formatting conventions really do transform the usability of CloudFormation.
The Terraform domain spec is not sufficiently expressive (just look at the circumlocutions you need to not create something in one environment versus another). It's way too hard to build large modules, but the lack of decent scoping makes assembling many small modules difficult too. Worse, the domain spec is also requires HCL, which is awful, or JSON, which is a return to the same problem that cfer solves for CloudFormation. One of my first attempts at a nontrivial open-source project was Terraframe, a Ruby DSL for Terraform; I abandoned it out of frustration when it became evident that Terraform's JSON parsing was untested, broken, and unusable in practice. Out of that frustration grew my own early CloudFormation prototypes, which my friend Sean did better with cfer.
If you're looking for an alternative to CloudFormation, I generally recommend BOSH, as it solves problems without introducing new ones. Saying the same for Terraform is a stretch.
 - https://github.com/eropple/terraframe
 - https://github.com/cloudfoundry/bosh
We use Terraform for our foundation and a clever Cloudformation custom resource hack to export values out to use in Cloudformation stacks where appropriate(use with Serverless services, etc). Works great for us; Terraform has seen significant(surprising even if you haven't looked at it in 6+ months) development over the past year.
The bin metaphor is that you imagine one or several bins on the floor, and a bunch of things to place in bins. Binpacking is just playing tetris to make sure all your things are packed into as few bins as possible, because bins cost money.
If you have a bunch of jobs and you need to run them efficiently on a bunch of compute, you need to be careful not to oversubscribe the hardware, especially wrt memory. There's an isomorphism between running differently sized jobs concurrently on a compute resources, and the bin packing problem. It's a scheduling problem.
Kubernetes does really well with this, although ease of deployment using config files and the abstraction from underlying vms/servers is probably more useful for most companies.
You can argue about the configuration-based deployment being worth it--I disagree, because, frankly, Chef Zero is just not that complicated--but it's more expensive in every use case I have seem in the wild (barring ones where instances were unwisely provisioned in the first place).
K8S/docker also makes it easy to avoid all the systemd/init issues and just use a standard interface with declarative configs and fast deployments that are automatically and dynamically managed while nodes come and go. We have preemptible instances with fast local storage and cheap pricing that maintain 100s of apps. K8S also easily manages any clustered software, regardless of native capabilities, along with easy networking.
Why would I use chef for that - if it can even do all that in the first place?
Just a historical perspective: GCE used to charge a flat fee for K8s masters after 6 nodes. After the announcement of the Azure K8s service, with no master-fee, GCE has dropped the fee as well :)
Edit: I think they have a mistake on the pricing page: the per-second rate looks more like a per-minute rate. Doing the calculation with the per-second and again with the per-hour stated prices gives a 60x difference in monthly cost.
Edit2: Yep, they've now fixed the per-second price; it was originally 60x the correct price.
This looks very similar to what we launched with Azure Container Instances last summer.
The Azure Container Instances kubernetes connector is open source and available here:
Perhaps Azure needs to work on marketing? Is there a legitimate reason Azure isn't getting more traction in the non-enterprise world? I mean that as a totally serious question, not in a dickish way. Is it because it has the Microsoft name attached to it or just because AWS has so much traction?
As always, full disclosure that I work at MSFT as well.
Devs in my team can pretty much chose their favourite cloud to deploy things to. Everyone always picks AWS, it's just the easiest to navigate and feels like everything links together well.
I think the only things we use Azure for is the Directory, and Functions to run some PowerShell.
As AWS is the industry standard, I feel that a lot of people like to stick with what they know too.
Yes on both counts.
Also, the perception is common that Microsoft = Windows Server, to a very high degree of bias. Thus, if you don't operate on that platform, you'd immediately disregard Azure. A lot more work is needed to convince non-Windows operations & developers to buy into Microsoft's offerings around Linux. Emphasis that that says nothing about the quality of existing offerings, rather, the issue is of perception. The perception is that Linux is and will always be a secondary concern with Microsoft; and potentially worse, skepticism over whether Microsoft will invest into and support Linux over the very long term. If one buy into that skepticism or doubts Microsoft's commitment to Linux, AWS is immediately a superior choice as a long-term platform bet.
HN has strong biases towards things that are startup-targeted or individual hacker targeted: open, inexpensive or new and small, or ubiquitous. Kubernetes and AWS in general get a lot of play compared to Azure , GCP or VMware (or even OpenStack these days). Nothing wrong with that necessarily, just a cognitive bias of the up voters.
The problems of support and network effects go two ways. People perceive that Azure favours Microsoft tech, and may not support other platforms as well, which may or may not be true. More definitely, the tools and libraries for non-Microsoft languages tend to support AWS as the cloud of choice by having more features and being more heavily-used and tested with AWS than GCP or Azure.
The OP is short on details anyways, does Fargate run on a tuned xen vm's or do they have linux servers under there (or maybe they're SmartOS ;) ).
Maybe I was doing something wrong, but my experience so far with ACI is that it consistently took about three to four minutes until a smallish container was ready for use.
AWS is a drug dealer.
I will tell you that we plan to support launching containers on Fargate using Amazon EKS in 2018
Two new container services announced but São Paulo still doesn't even have ECS which was announced in 2014.
ECS has been on death's doorstep while AWS has been pushing the Lambda strategy. My guess is that their numbers show a slowdown in Lambda uptake due to the problems with Lambda, so they're now moving over to this Fargate platform and ECS is getting a few dribbles of dev time as a consequence.
I think they need to get over this NIH/Rebrand&Relabel syndrome and implement Istio (https://istio.io/).
First of all you are using the wrong measurement of growth vs stagnation. We've continually been releasing features (not all of which are part of ecs-agent), while also working on many interesting backend projects such as Fargate. Much of what we develop is closed source or open sourced later, so the ecs-agent repo is not a good measurement of progress or attention.
Second the idea that ECS is on death's doorstep is just false. In the container state of the union at re:Invent Anthony Suarez, head of engineering on ECS, shared that ECS has experienced 450% growth, with millions of container instances under management, and hundreds of millions launched per week: https://pbs.twimg.com/media/DP1sWVZUMAAflSW.jpg
This matches up with my personal experience as a developer advocate for ECS talking to customers pretty much every day who are considering ECS or moving to ECS because it makes it easier to connect your containers to other AWS services.
Take a look at any random Github project that's unmaintained. That's the image Amazon has been showing the development community when they look at ECS. They don't see the closed source work. They don't see the hundreds of millions of internal KPIs ticked per week.
Now, I haven't spoken with a developer advocate, but I'm happy to share some of my frustration with you: I've had a dedicated resource working around bugs and limitations in ECS for months. We built a service mesh because ECS lacks service discovery, and then we built wonky patches to work around weird bugs in ecs-agent regarding how containers identify themselves. We've spent serious, deep time tracking down intermittent failures in the scheduler. We've worked in and around the strange task abstraction. This hasn't been a lovely experience. It's been hard and painful, but we press onward only due to the lack of time to convert to Kubernetes/Istio.
Are you in Seattle? Shoot me an email; I'd be happy to grab a coffee and share our experience.
I'm not sure if I should be surprised or not.
The Amazon stuff is especially confusing, it seems they have reinvented just about everything with their own jargon, it really doesn't help.
It's closest analog is Azure Container Instances or Google App Engine Flex.
Why would I deploy to Fargate over EKS? I assume it's because with Fargate I don't have to write a k8s deployment spec?
Why would I deploy to Fargate over ECS?
Legitimately curious, and looking for clarification/correction.
ECS and EKS are just two different schedulers for orchestrating the containerized services that you want to run. Fargate is the engine behind them that executes the containers for you without you needing to worry about servers.
ECS as a scheduler will always integrate much better with other AWS services. EKS will give you the advantage of being able to run the same scheduler on an on premise or on another cloud.
Fargate is a placement target for containers, just like EC2 instances in a cluster would be.
You use ECS and EKS to define and schedule tasks/containers on a placement target.
The primary difference between Fargate and EC2 is that with Fargate you don't need to manage physical instances and the software stack running on them (Docker daemon, etc). When you start a task, it runs...somewhere. In the AWS "cloud".
With Fargate, you get access to AWS-managed multi-tenant nodes. So, Fargate connects to either your ECS or EKS cluster and avoids the need for you to worry about managing the nodes as well.
It's not for everyone, it's not a "one solution fits all", it's very specific and what it does, it does it great (only tested, of course we have to see long-term...), because you don't need anymore to manage a cluster, which is really expensive especially because you don't want to shutdown your machines when you go home and restart them when you come back to the office (for example, in case you don't have a smart autoscaling in place).
Thanks AWS for providing this service!
Comparing the pricing of Fargate to EC2 is the same as comparing the pricing of EC2 to bare metal. It is more expensive, but it is also more convenient, and is easier to scale up and down.
However, you don't have to execute only batches with it, you can also run a temporary service within a specific VPC - with the biggest advantage that you don't have to resize/manage your cluster.
For example, you could set a Cloudwatch alert that, reached a peak of 80% of CPU, spins up a bunch of instances for a specific image with Fargate and keeps it alive until the CPU goes down to 60% (there it can be stopped). This way you don't have to worry about optimizing your autoscaling in ECS, because sometimes peaks happen in a matter of few seconds and it could be the case that you have not enough EC2 instances running, because lots of containers are running and they are spinning up in parallel. With Fargate it's like having an unlimited amount of EC2 instances running in your cluster... (which you pay for but certainly less than if you really had such EC2 instances always running)
Let's try to think about it from another point of view: you could also try to use Fargate to execute all your services, but then you would get the following features already implemented:
- maintenance/cluster management
- you don't like how AWS does autoscaling, because you notice that many times the nodes are under stress, and you would like to use a different strategy, or maybe you have computed your own autoscaling algorithm which is great and lets you save a large amount of money with it
- HA is trivial for you to implement, because you already have a lot of experience with it, lots of CloudFormation scripts, and well, so far it worked like a charm, so why would I want to switch now? the platform is really functioning well, no need to switch to another technology
- maintenance is not a problem for you, because your ECS cluster is small and easy to manage
Maybe in such cases, yes, you don't need Fargate after all. Keep your ECS cluster and don't worry about that.
Unfortunately Fargate isn't available on the Ireland region yet.
(I run the containers org at AWS. I happen to run Batch as well)
All I want is to be able to do this:
1) specify a DAG of tasks. Each task is a docker image, CMD string, CPU and memory limits
2) hit an API to run it for me. Each task runs on a new spot instance
3) be able to query this service about the state of the DAG and of each individual node
Sounds like if AWS provides an API to create a batch cluster (or whatever you call it) and lets the tasks be defined in terms of what docker image to run with what command you'll satisfy this desire
I'm curious, what would be the interaction between Batch and Fargate? Right now I use Batch to run a container and then exit out with as little thought about the underlying machine as possible. Is Fargate a push further towards serverless?
One concern I had with Fargate from the product description is around the configuration options. Our models require more than 100GB to build, but I'm seeing "Max. 30GB".
For an easy getting starting command line experience for ECS I highly recommend this tool: https://github.com/coldbrewcloud/coldbrew-cli
I'd say this is exactly why Google Cloud is superior (in my opinion). AWS lacks user experience and KISS philosophy. Just feels like AWS keeps on bolting things on.
But being able to put use either EKS or ECS for orchestration, and then schedule those tasks on either EC2 or Fargate (depending on compute needs), opens up a lot of options. You can start simple and grow as requirements become more complex—without fundamentally changing the deployment artifact. That was the promise of containers originally, so it's nice to see it play out.
You manage the containers with ECS (Or the newly announced Kubernetes equivalent). They are placed on either EC2 instances or somewhere inside Fargate.
If the startup time is fast, and it can run of GPU, a killer Deep learning platform could run on this.
Azure Container Instances uses Windows Hyper-V Isolation that boots a highly optimized VM per container, so containers have VM isolation.
Has AWS built a highly optimized VM for running container?
Edit: Maybe we'll get it! https://twitter.com/AWSreInvent/status/935909627224506368
This is different, this is where your containers run, not for managing the containers.
You can use either ECS or EKS for scheduling containers on Fargate, the same as scheduling them on EC2 hardware.
Oglethorpe: We have successfully traveled eons through both space and time through the Fargate. To get free cable.
Emory: I think it's a s-star gate
Oglethorpe: Its the Fargate! F, its different from that movie which I have never seen, so how would I copy it?
(I run the containers org at AWS)
We'd be using services like RDS for everything we could, of course, but sometimes someone insists on persisting something to disk, and sometimes that strategy makes sense.
Would love to have an extension of the run-task command that specifies an EBS volume to attach and where to mount it when using Fargate.
edit: (I dont actually know, im just saying yes cause you asked)
A part of me really hopes the pm named it this as an aquateen reference
Sorry for the offtopicish post...
Full disclosure: former AWS Employee
Hope everyone loves amazon!
Note: I do not work for Amazon. :)