Google Cloud NEXT '17 - News and Updates

Deciding between Compute Engine, Container Engine, App Engine and more (Google Cloud Next ’17)

NEXT '17
Deciding between Compute Engine, Container Engine, App Engine and more (Google Cloud Next ’17)
5 (100%) 1 vote
(Video Transcript)
[MUSIC PLAYING] BRIAN DORSEY: Hello, everyone. Thank you for coming. Thank you for being here. This is going to be a lot of fun. And this is, where should I run my code? A few minutes late– so awesome, thank you very, very much. My name is Brian Dorsey. I am in developer relations on Google Cloud. And let's get going. So I wanted to quickly get a sense of kind of who's here today. How many people are relatively new to Google Cloud products? Awesome, so like most of the room. We're in the right place together. And this talk is geared mostly at that level. If you already know deeply the stuff, you might learn a few things. But it's mostly going to be kind of overview things, and what's a good fit, what are the challenges, what's not a good fit, that sort of thing. Other quick question. How many folks here are kind of developers, kind of that angle of the world? Kind of writing code, IT operations, kind of that side of the world? And maybe you raised your hand both times.

Awesome, or perfect. OK, so we've got maybe 70%, 30% kind of mix. That's great. So here's a bunch of logos. And we're going to talk about all these today. So these are the four primary places to kind of run software that you write or bring to Google Cloud. And Compute Engine is our VMs, our Virtual Machines, the networking around that. Most of the rest of this kind of lies on top of that. So that's kind of why I drew it this way, so that it's kind of in layers, logically. Container Engine is hosted Kubernetes, so it's the system for running lots of containers on VMs. App Engine is the original Google Cloud in a way. You kind of push your code up, and then we will run it for you. And Cloud Functions is just one function. It takes some inputs, has some outputs, and does some work. And we handle all the rest. So that's the high-level hierarchy. If you just want to bail right now, or the take away at the end of the talk, very, very some simplistically, Cloud Functions are when you have a primarily event-driven work.

You've got some HTTP request that comes in, or a new object in a cloud storage bucket, and you want to do something about it. App Engine is focused on making your web code run extremely well. It's optimized for that. And it's code first kind of thinking. Container Engine is a system of containers working together to solve your problems. And Compute Engine is, basically, kind of everything else, or even all of those things if you want. It's VM. So you have full control to do whatever you need to do to connect things together. It's also a really good fit for existing systems. OK, so that's the framework for the talk. But does that answer the question, where should I run my code? Probably not. And the real answer is, as in all good computer topics, it depends. And so what we're going to do is run through each of these. And I'm going actually start at the bottom– because they work in layers– and kind of work our way up through the different pieces. And for the most part, they inherit the attributes of the lower layers.

So you just get to work at a higher level of abstraction, so kind of a more focused workload. So I'm going to start with bottom, work our way up, talk about things that are a really good fit for those. And you may, at the end of that, or through that process, say, oh, that looks like my problems, like my world. And you may just go, boom. And then I'll point you to some talks, and some other resources to follow up on that. But there's some other angles of thinking about this too, not just kind of straight product-centric. So we'll revisit the where should I run my code, and then go into next steps. But this is kind of like this big decision. Like, we're going to spend the whole talk on how to make this one decision. And I'll get this back at the end, but this is a relatively low-risk decision. You can move things around. You can mix and match. And there's a lot of options here. So no worries on– it's a low risk. Let's start with Compute Engine. And Compute Engine is virtual machines like at a very high level.

It's virtual machines, network. You get to inherit the network the Google Cloud platform is built on. And what makes these virtual machines special, in a way, is that they're built in Google data centers. They live, essentially, on the internet. And the interconnect between those machines is very, very fast. In numbers, these are very, potentially, large machines. So you can go up to 64 CPUs. You can go up to 416 gigs of ram, 64 terabytes of disk. We now have GPUs, if that's of interest for your workloads. And all of these pieces are independently configurable. So you can mix, and match, and create the machine shape that's right for your workloads. So especially for a lot of existing workloads, it's hard to tune them. They're kind of like a certain shape. And if you're in that situation, you can kind of create machines that are the right shape and size. So this is, you could put whatever size disk on whatever size instance, that sort of thing. The one constraint is there's a ram to CPU ratio.

They're a little bit connected. These start relatively quickly. So you go, in about 30 seconds, you're running your code. So the machine gets provisioned, boots, and gets off into your boot scripts and your software. We have a bunch of pre-built images. And it's virtualized hardware. So you can take your own images from other places and use them. Lots of different options for Linux OSs, and also Windows Server. So got that there. I'm going to dive down deep in just one part, just to give you an example of how rich this really is. And there's a few Compute Engine talks I'll recommend you to later. But just to dive deep for just a moment, the disks here are amazing. So you get a slice of an entire data center worth of disks. So while you're provisioning something that is a spinning disk– you know, I'd like a terabyte of disk. That's actually on hundreds or thousands of disks out in the data center. And so when you make a read, we pull from a couple different places, and actually, bring that back up to you.

So you get very consistent performance. And the random read is very good. You can pick whatever size you need. And network-attached storage is our default. That's what we boot all the machines on. That's how most of our internal workloads work. We're really big fans of network-attached storage. There are some cases where you just need the really, really low latency IOPS. And so we also offer machine-attached SSD for those scenarios. But most of our workloads, most of the workloads we see people use, use the network-attached storage. And they're independent of the VM lifecycle. So you can detach one from a running VM if it's a data disk, attach it to another one. You can make snapshots of them while they're running. You can take those snapshots. And you can create new disks from them, including in completely different regions around the world. So if you're thinking of things from an IT perspective, and you need to image a box, it's just a button click, or API call.

And then you can make that available somewhere else. One gotcha as you're evaluating the disks, larger disks have higher throughput. So you get a bigger slice of the data center. And so you get more throughput, and higher IOP quotas. So if you're evaluating this, there's some dock on it. But pay attention to the disk size. OK, so I'll pull back up a level. Most to talk is not at this level. But the whole platform is like this. Everywhere you look, there's all kinds of good things that are there to make your life easier, as you're operating these systems, and as you're running your software. So there's that. And then, it's more than just virtual machines. So this is kind of an orchestration system for virtual computers. So one example– actually, somebody I talked to earlier was saying they want to run containers on virtual machines. And you may have like a one-to-one– a lot of times, it's really convenient just to run one container on and one machine.

You don't really want a big orchestration system. So you can actually do that straight to the UI, and point it at an image. And we'll start a managed OS, and just run your one container for you if that's what you want to do. So that's an option. There's also groups of all these machines. And this is where it gets really powerful. One computer is only so big. But if you can think of your system as a collection of computing devices, the data center is your computer. Then you can go much, much further. And so we have something we call managed instance groups, where you have a template for what you want a machine to look like, either based off of a snapshot of a disk, or a machine you've pre-populated, or a script that sets them up. And then you say, OK, I'd like to run five of these. And I'd like them all to be behind the same load balancer. And you have a dial to make more or less of those. Or you can hook up an auto-scalar based on load, or CPU usage, memory, that sort of thing.

That instance group can actually span multiple zones, multiple failure zones, within the same region. So if you have a system where you can have multiple workers that are all collaborating on getting the work done, you can very easily have a very high reliability by having those in different failure zones. And then with using that, we can actually– when you make your base OS, base image, or your software, you can actually roll them out with this mechanism, as well, and roll them back. And then just to kind of highlight, the load balancer is the data center level load balancer. So we've got an article online talking about this. But you can basically go from zero to a million requests per second with no pre-warming, no talking to somebody. You're configuring the data center to do the load balancing for you. That's all happening off of your machines. So when you're thinking in Compute Engine, when you're thinking in VMs, this is logically virtual infrastructure. So you're thinking about your software, the operating systems it runs on, the size and shape of those machines, and what the networking looks like between them, the configuration there.

So this is, as a software developer, as an IT person, this is what you think about when you're working at this level of abstraction, these pieces. Constraints-wise, if you need to adapt very, very quickly, like in a few seconds to a burst of load, that may be a little bit challenging. So each machine starts very quickly, about 30 seconds. But it does take 30 seconds to get up to running your code. Now that's per machine. You can run thousands of machines in a few minutes, no problem. So if you need to do a big batch job, no problem. But if you need very, very quick stuff, you may need to break things up a little bit. And it is a whole computer, so you'll have to decide how you want to do your updates. It's an incredibly good fit for existing systems. The abstractions model very closely to what we're used to seeing, both in our own data centers and in other virtual environments. So you can usually move very quickly from software you have running. I mentioned before, this one-to-one container scenario.

Sometimes, you've got a container. You just want to run it. It's very convenient for that. If you need specific kernels, licenses, other very particular criteria about your operating environment, usually that'll push you towards Compute Engine and virtual machines. And let's go from there. OK, it's demo time. Too much talking. And we will do live demos, because scary. OK, so you may or may not have seen it, but this is the web console for Google Cloud. And this is the single most important piece of that. This button is access to all the other pieces. It might not have looked like it, but this is important. OK, Computer Engine is down here. And when you first come down, you can see your virtual machines, these instances groups that I mentioned. You can play with disks, and snapshots, and all this other stuff. We're going to spend just a couple of minutes looking at this. So we can make an instance. We can pick which part of the world it's in– data centers in Asia, Europe, the US.

We've got a whole lists of things coming online this year, more in Europe, more in Asia, Australia, and more places. So I can go ahead and pick a location. I can pick a kind of preset shape. But I can also kind of drag and drop. OK, I'd like a machine with more CPU than memory, or more memory than CPU. I can pick a particular number for no good reason, and make this very awkwardly-shaped machine. Maybe I'll name it answer, and do that. We have a bunch of maintained by us images that have software pre-installed to do updates of the OS in the background, and connect to the cloud a little bit easier, so that the security tokens are available to you, and things like that. So these are all here. You can change the size of the boot disk there. And then you just hit go. So this is now being created off in Google Cloud. So we've said we want this much space. We want it to be running this disk. And this web UI uses the HTTP REST API, the same API that the command line tools use, and that you can also use from your applications directly, if you like.

So this usually takes about 30 seconds. There it is. It's up. And we'll click my favorite button, which is SSH. And since I'm already logged in on the web with OAuth, Google Cloud knows who I am. We can do– kind of pre-populate some SSH keys, and SSH directly from the web, you're on a Chromebook or wherever else. I think I'm going to have to push questions to the end. I apologize. And we're on a real computer. And there we go. So that's end of that little quick whirlwind demo. But hopefully, that gives you a feel of what Compute Engine looks like, and how quickly it reacts. So why might you choose this? Consistency– so this is kind of actually true across Google Cloud. We are very concerned about our systems working well all the time. And when you have distributed systems, the one way you do that is getting your long tail latency down low. And you want very consistent performance. So if you do your load testing with 10 computers on one day, and a week later, you run them again, you should see almost exactly the same performance.

Choose the right VM size you want. We can actually resize disks that are attached to running machines. And then you can go in and run the commands so your file system can actually see it. And I'll bet almost everybody in the room has run out of disk before on a critical machine. So that's super useful. On the billing end, we try to make this really, really easy to think about. There's an entire talk on billing that I'd like to point you at. But we're trying to keep it really simple. Basically, if you use it more, you get a bigger discount. That's the fundamentals there. So if you use a certain machine shape for a whole month, you automatically get a big chunk of discount– 30% to 40%. If you have batch jobs, you can use preemptable machines. And they are far, far less money than the actual regular machines. Then they, actually, are automatically shut down at 24 hours. And they could be shut down at any point. That's what the preemptable means. And then we bill per minute– so a minimum of 10 minutes.

And if you run it for 12 minutes, you pay for 12 minutes of that computer. So if you want to make something faster, you can. And then I just want to kind of highlight that this architecture is what most of us are used to. It's a really good fit for most existing systems. So that's Compute Engine. We have multiple talks today. Or you can check these out online– or and tomorrow throughout the week. And you can check these out online later. SQL Server on Compute Engine, more Windows overall things, how to kind of scale really big, and do updates and things with the managed instance groups, saving money, which is the billing talk, and more batch stuff. So check those out for more details. And we'll move up one layer of the stack. So now we're going to move to Container Engine, which is hosted Kubernetes, which for running containerized applications. So how many people here are using containers now in some form? OK, big chunk, like, what, 75%, 80% of the room. And then I'm just going to assume everyone's interested, because this is my talk.

So containers are exciting for a bunch of reasons. And to just highlight a few things very quickly, you get isolation. You get repeatability. You can bring your same work into different environments, and have it behave the same. As a developer, I think of it like solving the, worked on my machine, problem. And that consistency is really valuable. You end up wanting to use a lot of them. And you want to use them on a lot of machines. And that's where Kubernetes comes in. And Kubernetes is an open source project that was started by Google, and very quickly, moved into the open. This has been built by a community of people, including Google, and many, many other companies and individuals. It is inspired by some patterns that we know work on running lots of containers at scale, but informed by that community of people who are trying to use it in places that aren't Google. Sometimes, have our own look at things. So that just is a fantastic place to be. It's already very mature.

It can scale up to you, I think, with the 1.6 they're hitting the SLAs at 5,000 node clusters. You may have seen the Pokemon Go news, that sort of thing. That's all on Kubernetes. And it really lets you think about applications, not specific computers. And the mental model I like to use for this is think about it as like a white board, right? When you talk to your colleagues, you're usually drawing lines and boxes of how the system– what pieces there are, how they talk to each other, and what the data flows look like. That's how you talk to Kubernetes, as well. So when you configure Kubernetes, you say, I want to have 10 web front ends. And they should be named Foo. And I want to have these five back end processors. And they should be able to find the database at this name. And you can even have kind of proxies for things that are outside of your cluster that are named. And they can all find each other the same way. So you basically, when you're thinking about your systems in Kubernetes, you're thinking about the logical infrastructure, how the pieces connect to each other.

And that is really powerful. So what are the programs? How are they connected? Where do they store their information? Container Engine is hosted Kubernetes. So there's two parts to Kubernetes. You've got to have a cluster, and have it up and running. And then you use the cluster. And Container Engine is focused on just solving this problem for you of keeping the cluster running, and updated, and happy, changing its size as your load changes, that sort of thing. So there are a few constraints here. It is a container first system. So you need to have your software in containers. And there are some architectural constraints. Like, it's designed for most of the processes to come and go over time. There's some tools in new releases for handling things that need very specific state, that need to a disk available to them wherever they move. But if you have an existing system, you're probably going to need to take a bit of time, and think about your architecture, and how it maps with containers, and this sort of thing.

It's a really good fit for systems that need to run in lots of different environments. So you can think at the logical level, and then deploy this using the same configuration on different clouds, on your own machines, in dev test prod environments, all of these different things. And it gives you a lot of portability of entire workloads, whole systems. That's really powerful. It's designed for containers up front. And I will say, it's a good fit. But this is also a little bit constraint-y. You need to have good communication across your organization with your teams. Because these containers are the kind of unit of deployment. This is the process, and all of its configuration, that sort of thing. So your dev team, and your ops team, and your security teams, they actually all need to be able to make changes to these. And so hopefully, there's a build environment. And hopefully, they have good communication. So that's a place where it's a good fit, which implies you probably want a good build environment, some sort of continuous integration, continuous deployment, perhaps, that sort of thing.

And it works with layer 3 networks and above, so you can host whatever you want if the pieces talk to each other. So a quick demo on this note. So now we're in the Container Engine portion of the web UI. And in here, I've actually already created cluster, as you do on cooking shows and demos. It takes about five minutes to start of cluster, usually. And this cluster, there's a bunch of settings and things we can poke around at. But one thing I wanted to highlight is this is just using a managed instance group from Compute Engine. And these are the VMs under the covers. So Kubernetes is actually hitting the same API as a Compute Engine that you could hit if you want to do your own orchestration stuff. And the auto scaling works via that, and the like. So this is the open source dashboard for Kubernetes. And we can see that it's actually got– the same nodes are listed there. I've gone ahead and created a thing called a service, which is just basically a load balancer for the cluster for this particular app that I'm going to deploy.

And it's called nginx. And it's on a public IP address if anybody can type really quickly. But there's nothing there. It doesn't go, because there's no software running. We can see that over here. So let's close that up. And there's a command line tool called cube control that talks to its REST APIs. And we can run. There's a little bit of shorthand if you just want to run one image. So I'm going to use that. I'm going to call it nginx, which is– you may of may not have heard of– it's a very, very popular web server. And it's based on an image that is called nginx. And this is a Docker image curated by the nginx folks that we're pointing out here. OK, what did it do there? That was fast. Thw And it's already up. This is deployed. And if we come back over here to services, click on this, we get the happy default nginx screen. So that's kind of awesome. Just for fun– so we have one of these running right now. So there's a bunch of things that happened here.

And I'm going to refer you to an introduction to Kubernetes talk to go through what these concepts all are. But basically, I said, I want to run this image. And it kind of patched it up in the management abstractions that Kubernetes uses. So it puts the containers in a pod. And that's what gets scheduled. And then we have these replica sets, which are the templates, and how many of the pods should be running. And a deployment lets you roll forward and backward among these things. So we have, by default, just one of one. And so I can come back over here, and I can say, can you control a scale deployment nginx. And I want to have, let's say, 12 replicas. And it says, OK, scaled, baby. And we come back over here. And 11 of 12 of those are running. And refresh again, and 12 of 12 are running. And one of those are running for a minute. The other ones are six seconds. So you can very quickly respond to new needs in your system. And this is very, very high level, but just kind of to get a feel of what it might be like to use Kubernetes.

And we have great talks. So today, right for lunch, from Kelsey Hightower, I believe, is a nice introduction to containers. Oh, no, sorry. That's the second one. So 2:40 is Kelsey's. There's an introduction to Kubernetes at 1:00– or whatever the times have turned into after lunch. It might be that. Or it might be a little later. And so check these out, either today in person, or online later. And now we move up one layer to App Engine. And now we're talking code first. The abstraction that you use when you're talking to App Engine is like, I have my source code. And the idea with App Engine, the goal from the beginning, is let developers focus on their code, and have the infrastructure handle the rest. A Little bit snarky, we'll say it's serverless before it was cool. But it started in 2008 with this trade off. If you write it this way, then we'll scale it for you. And there were some constraints about how you had to shape your applications, what APIs you could use to get that automatic scaling.

We have a new flexible runtime environment that is very much informed by the modern container world. So it is Docker containers under the covers. And therefore, you can run any application that will run in a Docker container. It is still web-focused. So it's primarily geared towards things that are HTTP requests responses working through. We have run times that we maintain for these languages listed here. But also, if you can run something that listens to HTTP be in a Docker container, you can deploy that in whatever language you have, whatever tools you use currently. Or something you've got set up for another environment, you can use it here. So that's the high level thing. You, when you're working with it, you think about code. You think about the kind of HTTP requests responses. And then you might– this isn't quite core. But you think about like, which version is served in production right now, and like, roll forward and back, and that sort of thing. Constraints-wise, the kind of standard run times that we've had forever and we're going to keep working with, we just updated Java, continuing there.

But we have run times for Python, Java, PHP, and Go. These are a very constrained, fixed run times. So you can't add new binaries to it, for example. In return, you get this very fast performance out of it. The flexible run times, they have whatever constraints are inherent in Docker. It's kind of like HTTP focused in this context. And the way they're implemented right today might not be the best fit for really low traffic sites. We keep two VMs running under the covers, so that there's always something going there. So if you have really low traffic, your end up paying for two VMs. And that's not perfect in that scenario. There's work going on there. But where things stand today, there's that. All of App Engine is a good fit for apps that are primarily HTTP request response, that are web-focused, that are developer heavy. You may scale to high traffic. You may seen the snapshot kind of things. Santa Tracker from Google is run an App Engine, whole bunch of stuff.

I think we're doing 100 billion App Engine requests per day. There's a lot of applications running on App Engine. So what that might look like in practice, I have another app deployed, as you might guess. This is the flexible run times. It is an app to show you pictures of fruit. This is a very highly demanded application, so I had write it. We can see, at a high level, you have these kind of services. So that's one portion of your application. In this case, it's the default version. So it's at root. And if I click on this link, it'll take me to the photo of the thing. And we have some lemons. And I can refresh that over and over. And I will get lemons all day. And you know, maybe we don't want lemons. I got some feedback that maybe life and lemons is not the best thing. So we've deployed some other versions. So we can go for cherry. And the other versions, they're currently not serving any traffic publicly. But we can still go for test, or verification, or whatever.

We can go to a sub-domain and hit that version directly, and see that there. Oh, we get cherries on this version. So we can do apples. Or probably, durian is where we want to be, right? How many feel like durian? Oh, we got one. OK, maybe durian isn't the most popular in this room. But we've gotten requests for durian. And what we're going to do is migrate all of the public traffic to this version of the app. And then we come back over here. I'll click here to make sure it's real. That version is actually serving all of our traffic. So then we've had the public moved over to that. If we needed to roll back, we can just do the version back, as well. We can do more complex traffic splitting. We can say we want to give, actually, lemon most of the traffic. But we want to actually give durian to 15% of the people who come, something like that. So you can do that sort of thing as well at a high level. And of course, you get tons of stats. This app, as you can imagine, isn't getting a whole lot of traffic.

But you'll get nice stats for how much traffic you're getting, latency, all sorts of different metrics about your application, full logs, and that sort of thing. So that's what that looks like. So why might you choose App Engine? To focus on your code, and have that scale, and go. It is very much geared towards web workloads. If that's where you are, it's going to be like a good fit. The new flexible run times are very portable. So you can take these Docker containers that are produced by this system and run them other places. Or you can take container images that you've preset elsewhere and run them in flex. It is a fully managed environment. But it is also running on the same infrastructure. So from the flexible environments, you can actually, what we call, kind of break glass. You can go in SSH into the machine, and use your regular debugging tools to investigate some situation that's come up. And then you just remove that VM from rotation. And it makes a new one.

And things are back the way they were before you started poking around. But you've been able to investigate using the tools you're familiar with and know well, and a hundred billion requests a day. So a lot more talks on this today, including .NET running .NET containers on Google Cloud. Scaling things, a talking geared towards the Ruby world, and how this works really, really well on Flex. If you were coming from Python or other languages, actually, that talk will also be pretty relevant, how the budgeting works, and that sort of thing. And the demo that I barely skimmed the top of, if you want to see more about that, the talk list at the bottom, I swiped that demo from Justin Beckwith. So you could see the full version there. And he'll go into more detail. OK, up one more level in the stack, cloud functions. So this is just– if you could imagine just having a function in the cloud that does work for you. There's so many different APIs on the internet. Most of them are available over HTTP.

And we start needing to glue them together, and figure out how to connect them, and either augment our existing systems, or in some cases, actually build systems out of connecting the pieces together. And I'm particularly excited here. Because I think this can allow people to kind of go a step beyond what we normally think about as our current primary developer IT ops audience, people inside of organizations, automating things, gluing things together, doing data transformations, and things like that. It is primarily event driven, so either like an HTTP request comes in, or a new object is added to a Cloud Storage bucket, and a notification happens. Or we have this thing called Cloud Pub/Sub, which is a message bus-like thing in cloud. Did you know we have this thing that is both high throughput and durable for all of your messages? Check it out. It's awesome. And for my biases to show, basically, I think Pub/Sub and Cloud Storage are APIs that nearly every op should investigate.

Check them out. It is very much serverless. I put it in quotes because there's computers down underneath. But from your perspective, you have a function. You write the code. You push that up. And it gets run. Pay only for what you use. The run time is currently Node.js. So you can take these same functions and run them in other environments, as well. So if you want to run the same implementation, you can run it on your own Machine. You could run other places. So as the user of these– usually the developer– you think about events, and you think about, so what happens in the system, and then what you want to do to transform that, what your function does. And that's almost it. Constraints, today it's JavaScript on node. So that's the language we get. You are thinking about things at the function level. So I think of this more in terms of like, as your system gets larger and larger, there are some cognitive overlap– you know, [INAUDIBLE] to kind of think about. And the system must work through events.

It is almost pure surrealist promise. You just take this function. And we run it for you. And they scale incredibly high. We've got people doing IOT workload handling, where they have devices in hundreds of thousands of different locations all pushing their data up. And the same function definitions scales up and down, depending upon the load there. If you are using Pub/Sub and Storage, it's a really, really good fit. If you've got some kind of somewhat lightweight ETL data transformations, if you've got some JSON that comes in some format, and you tweak it a bit for some other system, super good fit. Or just in general, I like to think it like, it's the glue for all of these Cloud HTTP Functions. So is internet duct tape or glue. Put all the things together. Demo here is more of kind of like a tour. This is the Cloud Functions portion of the web UI. Just to kind of pick on HelloWorld, as one might do, we again, get a bunch of stats, information about how this thing's working.

The trigger for this is an HTTP endpoint. So you can do a get or post request against this. If I do that, I get some text back. No message to find. Where did that come from? We can also see the source code. This is a very, very simple function that is looking for JSON Dock to come in, and to see if it has a message key, and then do something. If that doesn't happen, we get the message that we just saw. So let's try to do something closer to what the function expects. So I'll go ahead and paste that in. Do that. And we test the function. And we get, basically, log output, in this case. But it gives you a sense of both how quickly the functions execute, a little bit of play environment. And you can connect almost anything together this way. And this environment will also let you see the actual console log output. So you can see what came out of your logging as you go– so just a quick feel of Functions. So with Functions, you don't even have to think about servers at all.

You purely have the event that comes in, what you do with it, move on. You pay only for what you use. Don't need to think about the big architecture pieces. And it is very straightforward for developers to reason about in the local. You just have your inputs. And then you have some side effects, some outputs. And you go. As everbody knows, once you have a lot of those, there's complexities. But the model, while you're working on Functions, is very, very clean. To learn more about this, we have a talk specifically on serverless architectures, and how to think about them, and where they run well. It's mostly around Functions. Later today– or two of them, actually– today and tomorrow. The second one is actually where I– head this way. And actually, that's not the demo there. So anyway, apologies. And now we get to this kind of– so we've done the run through. Did we find a good fit for folks as we were walking through this? I think, for some folks here, one or two of those things jumped out as, OK, that's the thing I should look into next.

For other folks, it's not so clear. I'm still kind of confused. Or maybe I want to use multiple. And it does depend. So here's a few more directions to think about this from. So the abstraction level is kind of the structure of the talk. We're looking at different ways to think about an offer rate on your code. Also, there are just sort of technical requirements. So you might need certain network protocols. You might need certain other things. That might change your decision, and just push you directly into one answer, or a subset of answers. And there's also, what is your team, and what does your organization like? If your entire team is very proficient in a particular programming language, if your company has made some decisions about where they want to focus languages, or what's the future of technology the company, that also may affect where you decide to go for these. Because many use cases could work in one or two of these. So on abstractions, just kind of collecting things from throughout the talk, for Cloud Functions, you're thinking about mostly events and functions.

App Engine is your code and the HTTP interactions. This is actually kind of the summary that talk, I guess. So we'll just pause here for a moment. All the phones come out. And Container Engine is about applications, whole applications, and the logical architecture of how the pieces connect to each other, and being able to run those in multiple environments. And Compute Engine is your virtualized hardware. You think about the actual machines you've got there. So that's abstraction. Technical-wise, I think what tends to happen is tech constraints will kind of pull you further down the layer of abstractions. And a couple of examples to talk about this. So Cloud Functions has particular languages it works with right now, particularly, in what kind of shape of things. If you need more than that, you're going to be in App Engine or that space for sure. Depending upon what language, whether or not you're kind of web facing, you might actually come down a layer beyond that.

If you need to have hybrid portability, if you're doing protocols beyond kind of standard web protocols, you're going to be in leasing container, Compute Engine kind of space. And then if you need like a very specific kernel, you're running Windows today, you need certain software licensing things, you want to own all of the orchestration yourself, you might be down in Compute Engine. So the technical situation that you're in with the problems you're trying to solve may kind of push you in one place or another. And then your team– at a very high level, the higher level abstractions are a little bit more dev focused. And as you go down, they tend to be a bit more ops focused. Obviously there's a lot of overlap between that generalization. But if you have a team that's entirely made up of developers, you're going to be happier at higher levels of abstraction. And if you have very specific operations needs, those particular chosen paths might not be the best fit for your app.

And then, I think I kind of hint at this in the Container Engine thing, but where is the future of your organization going? If you know you're all in on containers, that might also push you towards Container Engine, Kubernetes kind of world. So keep that in mind. What are your people like? Where is your organization going? And then, again, just to come back on– this is actually low risk. So we spent this whole time, like half an hour, talking about, here's how to make the decision. But it's actually a fairly low risk decision. And I'll try to convince you of that. So one, containers are really giving us a lot of flexibility here. So as an example, if you start in App Engine Flex, as a side effect of its normal operation, when you give it the code, it produces a Docker image. You can take that same Docker image, and you can run that in different environments. So you can run that on Kubernetes. And you can run that same image on Compute Engine. You can even run it outside Google Cloud, other places, depending on how many APIs you're using and the like.

There might be some latency effects there. But you can run these same containers kind of anywhere. So if you start at a high level of abstraction, it's very easy to kind of like bump down a level, or move down another level. So that's cool. If you have an existing system, it does take more work to move up a layer of abstraction. You're going to spend some time investing, doing some learning, that sort of thing. But you can definitely do that. So this isn't a final decision on where things actually run at all. And most systems in the real world run their code in multiple places. They might be mostly Compute Engine based with a dash of Functions, or primarily Function-based, but there is some extra work that they need to do in another environment. You might be all in on containers, but yeah, there is that one system that nobody knows anymore. We're just going to run that in the VM. Or whatever the situation is, it's very likely that you're going to have a mix of different pieces over time.

And that's normal, and probably healthy. If you think about, at a really kind of high level, even if they're not quite microservices, but you have different pieces of your application, you're going to run them where they're the best fit for. And so it's very common to see an API endpoint being an App Engine, where some data processing might live somewhere else. So that's the TL;DR. And we'll circle back around. The take home, for your colleagues and other folks, is if you are primarily thinking about events, kind of internet glue, HTTP duct tape, think Cloud Functions. If you primarily have code that is meant to be web-facing think App Engine. If you are primarily thinking containerized applications, think Kubernetes and Container Engine. And for everything else, for existing systems, start with Compute Engine. And think about where the right fits are for there. [MUSIC PLAYING]


Read the video

There are many different ways to think about running code these days. And the tradeoffs are different when you’re working with existing systems as opposed to designing an entirely new system. Google Cloud Platform (GCP) offers solid support for the full spectrum of compute models. Brian Dorsey helps you navigate the tradeoffs and decide which models are the best fit for your systems as well as how the models map to Google Cloud services — whether Compute Engine, Container Engine, App Engine and/or Cloud Functions.

Missed the conference? Watch all the talks here:
Watch more talks about Infrastructure & Operations here:

Comments to Deciding between Compute Engine, Container Engine, App Engine and more (Google Cloud Next ’17)

  • Amazing….

    Geovane NT March 17, 2017 8:16 pm Reply
  • Thank you Google!

    Sheldon Johnston Sr. March 18, 2017 2:39 am Reply

Leave a Comment

Your email address will not be published. Required fields are marked *

1Code.Blog - Your #1 Code Blog