Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.

AWS Makes It Easier to Save Money with Spot Instances

Nov 29th, 2017 9:02am by
Featued image for: AWS Makes It Easier to Save Money with Spot Instances

Amiram Shachar
Amiram Shachar is Founder & CEO of Spotinst, helping teams leverage excess capacity (eg Spot Instances) to save up to 85 percent on cloud costs. Prior to founding Spotinst, he was Director of DevOps at Ybrant Digital and led the Israeli Defense Force's move to the cloud.

Back in 2009, Amazon Web Services released a revolutionary offering called “EC2 Spot Instances.” This offering allows AWS to get some value out of their excess capacity by selling EC2 instances of virtual machines at bargain prices (up to 80 percent off). These bargain prices come with a major caveat — Spot Instances can be interrupted with two minutes notice once other customers demand full-priced servers.

Over time, Amazon EC2 Spot Instances became very popular as the best way to lower EC2 costs dramatically (see: Ticketmaster using Spot Instances), but have become synonymous with risk. While utilizing the spare capacity AWS offers at up to 90 percent off the On-Demand price can be a gamechanger for companies big and small, the lack of any form of SLA or guarantee that your instances will remain available makes them too tricky for most to leverage.

At the company’s re:Invent 2017 user conference, held this week in Las Vegas, AWS has introduced new features and changes to Spot Instances. This is the dawn of a new era of Spot, immediately opening the door for creative DevOps teams to run any workload on Spot.

“We launched a new pricing model and simplified access to Amazon EC2 Spot Instances,” said Joshua Burgin, general manager of EC2 at Amazon Web Services, about the new update. “With these changes, you can launch Spot instances the same way launch On-Demand instances, and customers can count on low, predictable prices.”

The lack of service level agreement (SLA), however, remains — so if you require consistency or high availability for your workloads, this problem is still unsolved. For this reason, at Spotinst, we’re proud to help AWS provide that SLA to their customers. As Burgin says on our blog, “Spotinst, an AWS Advanced Partner, has been helping AWS customers to leverage Spot Instances for many years. By supporting these new features, Spotinst’s service enables customers to move additional workloads to Spot Instances with less-effort and greater confidence.”

New Pricing System Has Arrived

So what’s new with Spot? In short, Spot Instances will become less “volatile” and easier to consume via standard EC2 APIs, removing some of the barriers for those looking to get started with AWS’ spare capacity.

Before we explain how it affects you as an AWS user, let’s first take a look at the specific changes:

1. Spot Market changes are less frequent

Spot Market prices rise and fall based on demand of the specific instance type and region where you’re looking to run Spot Instances. Until now, these changes would be frequent, sometimes spiking multiple times a second.

Now, these changes will only come 3-5 times a day.

2. Bidding for Spot Instances is now Optional

No need to figure out a new way to get Instances when dealing with Spot. Bidding is now optional (though it can be a great way to set an upper limit on Spot costs for transient apps). Where you used to be required to set a maximum bid, you now just launch a Spot Instance as you would an On-Demand Instance. AWS will mark your “virtual bid” as the On-Demand price, and will terminate your capacity arbitrarily, whenever they need that capacity back.

No more worrying about what bid to set.

3. Spot interruptions are tougher to monitor and predict

You used to be interrupted when the Spot Market price exceeded the bid price. So when does your Spot Instance get interrupted if you don’t set a bid price?

It’s a simple answer, but one you’ll be unable to track. Your Spot Instances will be interrupted when AWS runs out of spare capacity — when all spare Instances of this type and region have been requested for On-Demand or Reserved purposes. As users, however, we have no insight into what AWS’ spare capacity looks like. There won’t be any way to predict or prevent interruption, understand why your Instance was interrupted, or know how AWS chooses which Spot Instances to interrupt first.

You’ll just lose the Instance.

4. New feature: Hibernate for Spot

This feature is awesome for workloads that don’t require high availability. Spot Instances can now save data after being terminated.

If you leverage Spot hibernation, when your Spot Instance is terminated, your data will be saved into an EBS volume. Your Spot Instance will then reboot once the spare capacity is available again. Hibernate will keep the memory state for your EC2 machine and will continue to work from the same way it stopped. This feature is now available for Linux EC2 Instances.

5. Launch Spot instances via RunInstances API

You can request Spot instances from the same API you use for On Demand and Reserved instances by simply specifying “Spot” option.

Okay, So Is This Good or Bad?!?

Well, both. It all depends on how you want to leverage Spot Instances and how sophisticated your Spot strategy currently is.

For users that are confused by Spot Instances, this makes your life easier. Without any SLA, however, managing Spot Instances will still be rather tricky if you’re looking for a reliable form of consistency or availability.


  • It’s way easier to get started with Spot Instances. By removing the need to determine a bid price, there’s little learning to be done before diving into the world of Spot Instances. They basically work like On-Demand Instances now, only way cheaper.
  • Not as many price jumps. While the Spot Market still may jump up and down quite a bit, limiting the price changes to several times a day means that you can rest a bit easier while running on Spot. No longer you will see noisy Spot price graphs and no longer you will be kicked-out by another Spot customer. Your Spot Instances will only be interrupted if AWS needs that capacity for another On-Demand customer.
  • Hibernation! By using this new feature, you won’t lose all your data when your Spot Instance goes down. This makes running things like Batch jobs on Spot a lot easier.


  • Running workloads that demand high or consistent availability on Spot is harder than ever. You’ll have no visibility into the price changes to predict interruptions and no way to be alerted in advance before an interruption.
  • “Where did my instance go?” You’re likely to say this a lot as Spot Instances will be interrupted arbitrarily. Without visibility into the pricing or price changes, your instances will disappear without clear reason and any warning before they’re lost.
  • Still no SLA for availability. You have no insurance that any of these instances will stay live for an extended period of time. For workloads demanding consistency or availability, this can be problematic.

In short, if you’ve never used Spot Instances, getting started has never been this easy. If you’re looking, however, to run workloads requiring high or consistent availability, you’ll either need to work internally to build your own Spot management strategy or leverage an existing platform that does it for you.

Feature image via Pixabay.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.