The Google Compute Engine is really easy to use, and the browser console makes it easy to treat it like a Linode or Digital Ocean type host, if that's all you want.
I recently transitioned off of Linode (after about a decade?!) to Google. Largely, this was because I needed a lot more disk space to mirror some large public databases, and it was significantly cheaper to do this with Google than it would have been with Linode. This is because Linode couples the disk space with both the RAM and the number of processors. I needed more disk, and would have liked more RAM, but had no use for more processors.
With this announcement, Google has now decoupled the RAM from the number of processors, which is a development I'll be taking advantage of.
Thanks! If there's a public dataset that you're mirroring, maybe we should be hosting it for everyone under our public datasets program (feel free to ping me with your details).
Sadly, extended memory does not mean you can arbitrarily scale RAM versus cores for free. The memory above a certain ratio per vcpu is charged at a higher marginal rate. The focus of the product is for people that might only want more RAM, but if they add cpus something bad will happen (e.g., they don't have enough licenses for their software, or their code will literally crash). We'll try to update the docs to be clearer about this.
>"The Google Compute Engine is really easy to use, and the browser console makes it easy to treat it like a Linode or Digital Ocean type host, if that's all you want."
I agree, the browser console is really fantastic. Does anyone know how this is implemented?
I'm a long-time Linode customer as well, and over the years I've been scaling my services up but the pricing model is quite restrictive! I also need more disk space, but not necessarily RAM and CPU...
For what it's worth Linode has said (in Feb, 2017) that they will be announcing block storage in the coming months.
Yes–you can create budgets, either as absolute amounts or based on last month's spending. You can also set percentages at which you're notified by email.
I want to point out that a bunch of things are rolled into this announcement:
- Skylake is now generally available
- Broadwell is now globally visible
- "Extended Memory" custom machine types are now in Beta
I decided to focus on Skylake as GA for the title, but depending on your interest these other announcements may be good to know as well. In particular, this changes the historical "us-central1-a is the oldest zone" into "us-central1-a is a better choice than 1-f".
Disclaimer: I work on Google Cloud (and want to sell you cores)
For comparison, bandwidth that costs me if I directly peer or rent from a European hoster 20$ a month costs at GCP over 900$ a month. With Firebase, it'd be a major 5-digit sum even.
Seconded, for similar reasons. Even in the US, for $400/mo you can get a colo with an unmetered gigabit pipe (Hurricane Electric, FDCServers). Assuming you only use it 50%, that's about 160TB, for a final price of $0.0025/GB. Google internet egress is 32x more expensive and that's with the steepest discount. Hell, even their CDN interconnect pricing of $0.04/GB is 16x more expensive than standard egress pricing.
In Europe their pricing is even less competitive.
It's insane how much they charge for bandwidth and it severely limits the usefulness of the service.
I guess that might be the point though. If egress is expensive, you're encouraged to keep everything inside GCP.
I used to work on Compute Engine itself. I led the team that built and launched Preemptible VMs, and I still participate in its upkeep / improvements. So I generally still write little bits of code that nobody else wants to (especially monitoring and other cleanup type work).
About a year ago we started an Office of the CTO with me as the first "hire". So I transitioned from building new things and writing code much of the time (Note: Many at Google will snicker at this, as I am routinely teased for being a pseudo-PM) to talking to high-profile customers most of the time (think CTO / VP Eng types). We usually talk through where they are, what challenges they have, and whether or not GCP can actually fulfill their needs today (and as my group focuses on candor, we certainly say "You shouldn't migrate to us until we do X, Y, and Z, or you rewrite Foo").
I love preemptible VMs, you and your team's work has made some impressive compute projects financially feasible. :- )
You folks should really have a utility on the default images (maybe call it `seppuku` or `dienow`) which sends an "o" to /proc/sysrq-trigger; using that has allowed me to time shutdowns to within a couple seconds at worst (though there is an unfortunate discrepancy between the account logs, which show the accurate node shutdown time, and the instance logs, which only show it a few seconds later).
I'm not trying to contradict Solomon's reply, but I lead our partner-centric solution architect team and we do send a good portion of our time in the same sort of engagements the Office of the CTO do, just in the context of three party (Google+partner+customer) opportunities. It's fun and I'm hiring (MTV, Bangalore and Paris).
There's certainly some overlap, though the Solutions Architects (SAs) are more explicitly focused on publishing solutions (cloud.google.com/solutions).
My team is composed of a mix of Google engineers that can (kind of) talk to people, and recovering CXO types from various industries (Finance, Healthcare, etc.). Each of us try to only work deeply with 1-3 customers at once, while SAs are usually focused on more broadly applicable solutions.
We all weave in and out depending on personal relationships with customers and individual skill sets, but we're all behind trying to make our customers successful regardless of role or title.
As far as the title goes sticking to plain English words instead of acronyms would be nicer. I have to think for a moment to guess what GA stands for and GCE is completely meaningless to me without following the link and seeing that it is Google cloud crap.
Speaking of search engines: why don't you just look up acronyms you don't know? The one-time inconvenience would seem to be much better than denying everyone the benefit of using acronyms (as demonstrated by their use). And what's the standard for acceptable acronyms? Is it "GA" or "GCE" you don't know? What about GPU, CPU, FLOP, CIA? And why only acronyms? Surely, some people will have to figure out what "Skylake" is, as well. And considering nobody is born speaking English, should the title include some sort of explanation of "now" that starts from first principle?
It's about good writing and judging your audience.
You can safely bet anyone here will know what CPU stands for. But this title is just badly written and lazy. I actually managed to figure it out after a couple of seconds of staring but the point is - I shouldn't have to.
I really love Google's UI, it's miles ahead of AWS (though kudos on Lightsail, they nailed that one), but last time I tried porting my toy projects, I was stopped by Google's requirement to be a registered business. Is that still a limitation, or can anyone sign up these days?
That unfortunate limitation applies only to European customers. The reason for it is that they don't charge VAT and customers are responsible for their own tax liability, which wouldn't fly if they were selling to consumers instead of to businesses.
Yeah, it's one of the benefits of being attached to "the rest of Google". As with Broadwell, Google was front and center in helping Intel qualify this part. The distinction is that with Skylake the lead time over general availability was even longer (see our announcement of this at Supercomputing in November).
We still have some things on Skylake we're going to do beyond today's announcement, so today is really "Welcome!".
Sadly, GKE wraps GCE in a fairly manual manner. For each instance feature, they have to decide if and how they want to reflect that. I'll file a bug though!
That's why we didn't do this with machine types. If you don't care, you don't have to. If you care, ask for a particular CPU platform (or newer). Most people won't and probably shouldn't care, but Skylake is enough of a jump that we finally are giving people the explicit ability to choose.
Both clock-for-clock and even more strongly for applications that can take advantage of AVX-512, Skylake can be a lot faster than either Haswell/Broadwell. Like the jump from Sandybridge/Ivybridge to Haswell/Broadwell, the jump to Skylake is a big one. For now the best comparisons are going to come from independent sources like Anandtech and hopefully from customers running their actual code on Skylake and publishing the results.
To be fair, there's also a general purpose option for both AWS and GCE. AWS has the M4 and GCE has the n1, something in the middle for either should be good enough for most applications.
No, m4 (mostly) is a specific architecture. There were things before it like m3.
I'm not saying it's hard to understand what to do when new ones come out, but for each architecture there's a new machine family. GCE has only historically provided n1-whatever and you got whatever CPU platform we had in that specific building.
As for extended memory, as I clarified elsewhere, while you can make a 2x24 it won't be saving you money compared to having the cores. I forget if this is made clear in the docs, but via the API this is laundered through machine types as custom-2-24000-ext.
I recently transitioned off of Linode (after about a decade?!) to Google. Largely, this was because I needed a lot more disk space to mirror some large public databases, and it was significantly cheaper to do this with Google than it would have been with Linode. This is because Linode couples the disk space with both the RAM and the number of processors. I needed more disk, and would have liked more RAM, but had no use for more processors.
With this announcement, Google has now decoupled the RAM from the number of processors, which is a development I'll be taking advantage of.