 And how are we going to get started with Node? What are some best practices? What are some of the ways Node is kind of different than maybe what you're used to for other technology stacks inside of Cloud Foundry? So first of all, who am I? So my name is Joe Doyle, Solutions Architect Manager at NodeSource. We are a Gold member inside the NodeJS Foundation. I am a longtime NodeJS developer before there was a Node Foundation. I'm also a co-organizer for the SF Node Meetup. So if you live in the Bay Area and should Node, we meet on the first Thursday of every month. In addition, I like to reach out where I can to help new developers kind of enter the NodeJS community. So I'm a mentor at Node School Oakland, which is an opportunity for folks that are new to JavaScript, new to Node, basically come get one-on-one mentoring, learning how to use the platform. In addition, one of the slides Mark highlighted was that crazy large spike in NodeJS contributors. I also help out with something called NodeJS Code and Learn, which is really a program meant to help first-time contributors to the NodeJS project make their first commit to the core. Also, I'm a Windows advocate using a Mac today, but I started my NodeJS journey on Windows and I have a very long Windows background, so I love to see Microsoft is involved in not only NodeJS but also the Cloud Foundry Foundation. And you can pretty much find me everywhere as Joe Doyle 23 on the internet. Unfortunately, I have a super common name ranging from Olympic swimmers to congressmen to professional photographers, so the 23, unfortunately, is very important. So getting started. A lot of folks raised their hand when they talked about who is using Node and a lot of folks raised their hand saying who's using other technologies such as Java. One of the things that Mark really kind of highlighted is Node is pretty much everywhere now. Most Fortune 500 companies have NodeJS running in production or have plans to do so very shortly. And a lot of what we kind of talked about, we had better numbers, but really a lot of companies are seeing developer satisfaction, developer productivity be really a strong benefit to why they want to bring NodeJS into their environment in the first place. As a lot of that might be attributed to the rise in single page applications on the web front end, we're getting more and more JavaScript experience. So now being able to leverage those same resources and writing the same server side application is turning out to be a huge benefit for companies as they move forward in adopting JavaScript in the front end and the back end. In addition, we kind of talked a little bit about the rise in serverless. NodeJS is really a high throughput system while at the same time consuming far less resources than a lot of previous stacks that companies are used to. So this really allows you to kind of operate Node in a very different way than you would approach your Java or .NET stacks because of that low resource utilization while getting up to a 20x performance increase for certain types of traffic. Finally, as Mark mentioned, NodeJS is everywhere. 8 million users worldwide, the MPM package ecosystem is over 410,000 packages and growing. So it's really, there's a huge community, lots of resources, and everyone's very highly engaged in making sure that NodeJS in general is successful. So now we come to where we want to talk about today, NodeJS on Cloud Foundry. So one of the great benefits to NodeJS is that low resource utilization. So when we start to look at matching up with Cloud Foundry, that really starts to speak to some of Node's strong suits. Because we're using less resources than traditional stacks, it's usually easier to kind of get more efficiency out of your already provisioned Cloud Foundry stack by leveraging micro-services. All your Node instances are going to take less memory, less CPU, so we can start to have more of these micro-services all on the same hardware. And that's something that we see time to time again. As Mark mentioned, we have quotes from Netflix and Capital One. A lot of these folks were started before NodeJS became mainstream. They had a Java base, and now they're moving to Node, being able to get even faster throughput, end up using less resources with physical hardware. Horizontally scaling your application is one of the great benefits of Cloud Foundry. We can kind of scale up, scale down as we see our load is increasing, our demand is changing. And that really speaks to the sweet spot of NodeJS. It's very quick to start up, very easy to design your applications in a way that is meant for horizontal scaling. So as you're prototyping your app, maybe you only need three instances. But as you're getting ready to go to production, you can scale up to 20. Maybe you're a startup, and you just got hit on Hacker News, and now you need to scale up to 100. Cloud Foundry makes that real easy, and that kind of works in with the design principles of NodeJS. In addition, NodeJS has also kind of came around the same time folks started talking about the 12-factor application, doing best practices around ways to easily manage configuration, making sure that we're managing state in a way that scales appropriately as we're getting to large enterprise applications. Additionally, as we talked about, we are officially supported at BuildPak inside of Cloud Foundry. So NodeJS is a first-class citizen. As you download the open source Pivotal version of Cloud Foundry, Node is there and ready to go without you having to do a lot of extra work. And an important thing that's kind of shifting inside of many of the platforms that exist today for enterprise applications is Node is really aligned well with containerization patterns that we're seeing, ranging from Docker to Kubernetes, running on the Run-C engine itself. It really just kind of speaks to that community, and in the Docker world has already been very widely adopted as a very popular runtime in general. So let's talk about the NodeJS BuildPak. That's really our entry point into the Cloud Foundry environment. For folks that are familiar with Cloud Foundry, BuildPaks are not really anything new. If you've worked with Heroku, the same kind of BuildPak concept flows right through to Cloud Foundry. And because we're a system BuildPak, as we talked about, this really helps to lower the barrier to entry of trying to get started with NodeJS on Cloud Foundry. So as you may be bringing new applications on board, really you just follow a lot of the same best practices that you're used to. Only now, because we're running a NodeJS application, we get the leverage Cloud Foundry's built-in capabilities to detect that we're running Node. So first and foremost, traditionally with NodeJS applications, we have a special file called package.json. This is our manifest for the application. It helps tie in the NodeJS dependencies that we are bringing in from the MPM ecosystem, as well as any private modules we might have developed ourselves, and really kind of controls the structure of what are we bringing into our application. When Cloud Foundry sees this package.json, it is going to automatically assume that you are running a NodeJS application, and it will automatically then assume it should be using the NodeJS BuildPak. This is great because this keeps our deployment automated and simple, just like we expect for any other language that we're running on Cloud Foundry. There is a little thing we need to be aware of, though, is the BuildPak really locks us down to the version of Node that we're allowed to actually deploy with. Node actually has a relatively aggressive release schedule when it comes to point releases and minor releases. That's tried to be, we minify that when it comes to the LTS side of things. But if you're a company looking to be aggressive on staying up to the latest and greatest version of Node, your BuildPak kind of needs to match that. So as an example, as you can see, one of the versions of the BuildPak that comes with the local PCF Dev that we'll kind of talk about and do a demo with is really locked down to these specific versions of Node. And if you're someone who keeps up on Node, you realize that not all of those are the most up-to-date version. So while it's great that we are built in, you also have to be a little mindful as to what version of Node are you interested in running. Is it the latest version? And then you have to make sure you correlate that with your BuildPak version. The great news is, though, the BuildPak is open source and it is on GitHub. So it is inside the Cloud Foundry organization, and they actually do a very good job of keeping that up-to-date. The current version that was just released not too long ago actually does support Node version 8, which is brand new inside the Node community. So when we use our default BuildPak, Cloud Foundry is going to make some assumption for us if we are not already providing these details to override this. First and foremost, if we are not telling Cloud Foundry a specific version of Node to use, it's going to pick a default version that is assigned via the BuildPak. In the version that we kind of highlighted, that's 4.8.3. While that still is an LTS version of Node, so it is safe to use in production, you're going to get security updates, is ending its life cycle inside the LTS version. So it's starting to enter the maintenance mode, and we're starting to get six months of only security fixes before that's going to be deprecated, and we're going to recommend that you do not use Node 4 branch. In addition, some of the defaults are a little opposite for what a traditional Node.js application would require. Traditionally in Node, we don't need a lot of disk space, and we don't need a lot of memory. But the defaults are when you just push a Node.js application up, or it's going to allocate 256 megabytes of memory and 512 megabytes of disk. And we're also only going to get one instance. So really when it comes to starting to explore how Node should be deployed, we really want to adjust that expectation. The recommended Node.js line to use today is Node 6. It's going to have another 18 months of security and support, so that's really the safe one to make sure your application is run on today. But in addition, we probably want to flip some of these settings a little bit. So kind of an average recommendation that we have based on your typical Node.js application that we see are really give it half a gig of memory. Node.js doesn't use a lot of memory. It's kind of an anti-pattern. If you end up having an application that's pushing all the way up to the one and a half gig heap limit for Node, so really 512 meg is really kind of a common good spot to start off with your applications. 128 megabytes of disk is also kind of a good recommendation. Again, these are all things that need to be measured, but these are kind of more along the lines of what we see for a typical Node.js application and its requirements when starting to deploy and run in production. Most importantly, the biggest change from Java and .NET is that Node.js does not use threads. So instead of having lots of threads inside of our application and having that be the main way that we handle lots of traffic, instead Node.js is actually executing your code single threaded. Now, it's doing that asynchronously, so we actually can still do a lot of traffic with that single thread, but because it still is a single thread, we need to safeguard that thread. And the way we do that with Node is we scale out horizontally. Instead of running one instance of your application on a very large box and then you replicate that, instead you run lots of instances of your Node.js application across however many boxes you like. It can be several on the same box, one on the very small box, but then we scale that out horizontally and put a load balancer in front of that. That way if a Node.js application has one of the process die, we still are load balanced across the many of them. And for a lot of folks, that's a very different paradigm shift when it comes to doing high traffic sites coming from a more traditional stack like Java and .NET and then starting to introduce Node.js into their application. They often expect that they just need one instance on their server with eight cores and 24 gig of memory and yeah, let's hit 10,000 concurrent connections. But unfortunately that's not really the case of how Node scales. So some quick tips to get started. Most of your Node.js applications are going to be listening on a port. We talked about the main use cases are for front end, API, mobile services, things that are going to be handling traffic from the outside world. And Cloud Foundry really makes this easy for us because often in Node.js applications it's the best practice to accept the listening port for your application on the port environment variable. And by maintaining that same best practice, Cloud Foundry is going to do the exact same thing for you. So as you deploy your Node.js application, it's going to land somewhere inside your Cloud Foundry cluster and it's going to just assign a port so that it can control that mapping and make it available to the outside world for you, all the great automation that Cloud Foundry does. So by continuing that best practice of using the port, your server will automatically listen to the right port inside of Cloud Foundry, automatically be mapped in just as you would expect for any other language. Another common question, and this kind of is a deployment question new folks to Node have all the time. We have this folder called Node underscore modules. And this is really where we install all the modules for the project. It's always local to the source code of your project. And the question is always, do I bundle that with my application to deploy it? Do I make it part of a deploy step to run my NPM install? What do I do? How do I manage that? And the great thing is because the BuildPack is really written by NodeJS experts, Cloud Foundry has done a great job of really following NodeJS best practices, you don't need to worry about that. Cloud Foundry BuildPack will automatically do the NPM install for you, which means that if you have any native modules, they're going to be already set for the Linux version that's running inside of Cloud Foundry. Everything is just going to work and be automated for you. So you don't need to worry about packaging those up. You don't need to worry about operating system specific settings or anything along those lines. The BuildPack will do all the right steps to make sure your NodeJS applications is brought up into the Cloud. Finally, for folks that are experienced with Cloud Foundry, you're probably familiar with these two environment variables we have, VCAP services and VCAP application. Really, these are the same in Node as they are for any other language. This is how Cloud Foundry is telling us about the environment that our application is spinning up in. And really, there's not much change. Node still needs to use those same things. These are valuable information about the specific instance of the application. What are the services that are being made available to me and how do I connect to them? So it's still important to be able to leverage those as we go. With Node, though, we actually have a nice little helper, right? The great thing about the NodeJS community is that if there's a problem, somebody has probably already made at least one package to help solve that problem for you. One of my coworkers, Patrick Mueller, actually has a package called CFN on NPM. And what it does is it reparses the VCAP services and VCAP application for you so that you have a nice and easy to use object that represents all the values being supplied to you from Cloud Foundry. The best part of this is that, as we saw on one of Mark's slides, most people aren't doing development by doing their code, pushing to Cloud Foundry, seeing how it works. Instead, they want to run their application on their local machine, quicker feedback group, right? Node runs great on your machine. So one of the things that the CFN package does for us is to allow us to provide sane defaults so that, even though our application is going to end up living in Cloud Foundry, we're going to need to know about these services, the application-specific details of our installation. When we're running locally, it's going to provide sane defaults so that we just don't blow up and melt down going, oh, well, we don't have a Redis server, we don't know what port. That way, we still have that nice development cycle of being able to code locally on your machine, fire up Node on your local machine, test it out, the things look good, commit, push the CI, and let the system flow. So now we're ready to go, right? What do we need to do? We've got a Node.js application, we've figured out that we're going to be in Cloud Foundry. There are a few things that start to change a little bit from a default Node.js application to one that we're trying to prepare for Cloud Foundry. First and foremost, this is a snippet inside of our package JSON. As you mentioned, this is the manifest that we have for our application, all the dependencies for runtime as well as for development time. And we have a special section right in the middle called engines, and we see we have a subvalue called Node. This is something that I believe started with Heroku back in the day, and this allows your infrastructure to query this package JSON and let your application tell it what the best version of Node we should be running. So this is the way that Cloud Foundry build pack will do its best to respect that version request. As we mentioned, the build pack is limited to the versions that we have available, but if you have one inside of this format, it will do its best to respect that. In addition, we still get to also leverage some of the common things that we're used to for Cloud Foundry. So we still also will have a manifest YAML file that allows us to control how is our application going to be deployed? What are the resources that we need? How many instances do we need? And so this is kind of a quick little snippet of it. We can see we also have environment variables that we wanna make sure we pass down into Cloud Foundry that are available for our application. Again, this is standard Cloud Foundry. There's nothing really specific about it, except for the idea we wanna make sure that we're using the right memory and disk utilization as well as we have more than one instance in case our application runs into problems. So real quick, we'll jump in and do a real quick push, just to highlight how simple this is, if we can actually get there. So I have a simple Node.js application and someday, as we mentioned, we are gonna figure out how to do projectors in an easy way and it's gonna be magical. So I have a really simple Node.js application already set up. Basically, it's using all the settings that we just showed inside of our environment. So the great thing about Cloud Foundry, CF push and away we go. So as we can see, CF push is loading up. It's doing all the work it needs to do to package up our application, send it into Cloud Foundry and then from here we can see it's doing a check for our build packs. I have already manually updated to the latest build pack so that I can support 6.10 and it appears to be downloading it again. So our build's exceeded. As you can see here in the middle, it was kind of a whole bunch of lines and they kind of have Node modules in it. That's actually Cloud Foundry going ahead and installing our modules for us to make sure that everything is included in our production dependencies is there. And sure enough, we see we've got our three applications running. So if we jump back over to our UI, we can see we have our CF demo app running. We've got three instances and sure enough everything has been respected about our manifest YAML. If we go through and take a look at one of our routes, we can actually see we are running in Cloud Foundry. Not only that, but I added a fun little trick. We have the host as Cloud Foundry reports it to us and so I said we should have three instances of that. So if I go ahead and refresh, you'll notice that good of our host is changing. So not only did Cloud Foundry deploy our application for us, it's also automatically load balancing which is exactly what we want for a Node.js application. So there's another alternative that's starting to become more popular in the Cloud Foundry ecosystem and something that exists today but not quite as first class citizen. We're hearing more about it when we talk about Garden with Run C and being able to take advantage of Docker containers and bring those images into Cloud Foundry and run that way. So some of the benefits that we get, everything is bundled together. It's kind of one blob that represents your application. It can be pushed around anywhere it needs to be. We can choose the version of Node we want regardless of whatever build pack we have installed onto the system. It's also then portable across systems. We can run this container inside of Cloud Foundry. We can run it inside of Kubernetes. I can run it on my local Mac with Docker for Windows or Docker for Mac. It's all kind of there for us making it really simple to have that build artifact kind of locked in place easy to test anywhere. We also are able to then leverage the large ecosystem of pre-existing Docker containers that exist much like Node.js where if there's a problem there's probably an NPM package that solves it. If there is a piece of software out there that has terrible configuration settings and you need to read four blog posts to figure that out there's probably a Docker image that already is set up and lets you do that software without any headache at all. So the best part is on new versions of Cloud Foundry this is already built in. It's just not turned on. A lot of what was talked about in some of the keynotes security is a really important aspect of Cloud Foundry. And while Docker is in use in a lot of production environments there are often a lot of questions around how secure is Docker? What are the edge cases we need to worry about? So Cloud Foundry is taking a responsible approach to make sure that as this new derivative of running containers inside of Cloud Foundry that everything is secure, everything is done correctly. So all we need to do is if you're an administrator inside of your environment you can enable the feature flag for Diego underscore Docker and then step three is profit, right? Now we can use Docker. Unfortunately there are some things we need to be aware of. First and foremost these Docker images are not pre-baked in build packs. They're not already sitting on a system somewhere. Basically your Cloud Foundry environment needs to go and get those images to bring them in to be able to run them. And there are some caveats around that that can make things difficult. So first and foremost it needs to be an accessible registry and it has to have a valid SSL certificate. So the good news is Docker Hub is the main central repository for Docker images but that also assumes that you are allowing internet access from your Cloud Foundry environment. And based on our experience at NodeSource that is not always the common case. So that's kind of a little roadblock. But Docker allows you to host your own repository inside your own firewall, inside your environment. The problem then is you need to make sure you have a valid SSL certificate as far as your cluster considers. So that means you need to run some form of PKI inside being able to manage those certificates and already have a way to trust a certificate that you generate and hand out. Again, these are difficulties only because Docker is trying to figure out security. These are best practices that Cloud Foundry is following. So they are doing the right thing. It's kind of hard to make Docker catch up all the time but they're doing a good job of getting there. And finally, as we mentioned, this feature flag needs to be turned on by an administrator. Also from our experience, the folks that are building the applications never have this right to turn on this permission. The administration of the cluster and then the ability to push applications are usually very well-controlled, well-separated roles of responsibility. So it'd be something you would need to work with your own operations folks to be able to test this out. The fun thing is we still do an almost identical deployment. We can still do CF push with our application. The only difference is we have a new flag dash dash Docker image, which allows us to specify what image is going to be used for our application. This can be any Docker image that exists. It can be your own Node.js application that you've just created and bundled up. It can be any sort of project that exists out there. Maybe you want to use Redis. Maybe you have some form of MySQL or Graphics Magic packaged up in an image. Really doesn't matter. The most exciting part of this is that the manifest.yaml is going to be respected. If you run the CF push in a directory with the manifest for your application. So even though we kind of have changed where the source comes from, we still are able to leverage the same kind of infrastructure tooling around how do we describe the resource utilization? How many instances do we need for each application? And of course, we can go take a look at that and see what it looks like. As soon as my screen catches up, we'll try the quicker of those two suggestions. Okay. So as we can see, trying to make this more visible, we get to use our same CF push command. I gave it a little bit different name. But this is a pre-built command. This image is actually live and available. So if you go to dockerhub.nodesource.cfdemo, you can actually play with this image itself. It's not very exciting. But we go through, we see a very similar process. Cloud Foundry is going through allocating our application, making sure that if there's a previous version, we're overwriting that as needed. And we go through, I've already kind of cheated for make sure the demo guides don't frown on me and the image is already inside of my Cloud Foundry environment. So as we see right away, we're spinning up our three instances, just as our YAML manifest requested. If we jump back to here, we can see our CF demo Docker instance is now running. We have our three instances, and if we go to our route, we see our happy bender just as we expect. And again, we refresh, we're automatically getting our load balancing and away we go. So this portion isn't necessarily Node.js specific, but what you end up finding inside of the Node.js community is as Mark mentioned, Docker and containerization is really a paradigm that fits well with Node.js and how Node.js applications are designed to be stateless and make it easy to scale horizontally. So containers are just kind of one of those ways that helps assist that, which is why we really, we mentioned it. So jumping back, so that's what we have for today. So thank you very much. Do we have time for questions? Yep. You were describing how to push a container. I was wondering if it's, when you're running an application in a container, it's kind of a long running process, if you will. So is it possible to control from Cloud Foundry or from launch from an application, a container? They said you have an application running already in Cloud Foundry, and from there you want to launch a container. It's kind of a interfacing with the container. So I haven't, I'm warning Cloud Foundry myself as we go through, and there's not a lot of information about some of the specifics around some of the running Docker images inside of Cloud Foundry. That's something that is expanding and growing inside the Cloud Foundry ecosystem. And there may be someone in the room that might have a better answer for that than I do today. Thank you. 12-factor app. In Java, what happens in the, because we are working with both Java and Node.js, in Java every vendor has some sample 12-factor application. Can you suggest something for the Node.js that you suggest that we can look into a 12-factor, a 12-factor application, a URL or a GitHub URL or something of that sort? Sure. I actually don't have any off the top of my head. I'm sure Google will probably be a better suggestion. It is a common practice to maybe not necessarily follow every step, but the majority of the 12 steps around the way configuration is broken out, environment variables and all those types of things. So I don't have a great answer for a specific example, but I'm sure we could Google one and find a really good example. Okay, thank you very much, Joe. All right, thank you.