�ݺ�ߣ

Editor's Notes

1. Innovation relies on speed to execute. How fast does it take an application developer to take their code and push it to production?
2. Typically developers will go to IT for a particular service. IT will go through their processes to spin up those resources. We all know that processes take time. Developers get frustrated when they have to wait. So they go to an external service and that makes IT sad.
3. We must give developers the speed they need in a much faster amount of time. And wrapping it all off with a bow is exactly what we need to accomplish
4. Whether you are using vSphere, vCAC, vCloud Hybrid Service, OpenStack, or Amazon’s Elastic Compute Service, there is one thing they all have in common. Each of these services spins up Virtual Machines to run code. Depending on the type of application, this virtual machine could be classified as a pet or as cattle. No matter what, IT is responsible for: getting the code on these VMs (whether it’s automated or manual) The interdependencies of the operating system and setting up the application environment. This can be manual or automated through configuration management such as chef, puppet, or ansible. The time it takes to build this orchestration to make an automated IaaS system. And the time it takes to maintain all of this. The operational status of any VM is important because it could mean curtains for an application. And the sheer volume of virtual machines to manage. Think if you had a development initiative that will end up creating 100 different scalable Web Apps. If each of those apps followed the three tier model (and that’s without scaling) we are starting off with 300 new VMs to manage. IaaS may not really be the answer
5. So what’s another answer? A developer has been working furiously on his code and he’s got a completely working development environment on his laptop. It’s go time. How do we get this code to production faster? IT has been hearing good things about Cloud Foundry and decides to spin up an instance. IT tells the developer to install CFtools (cloud foundry tools) and from the application working folder, do a cf push. His laptop connects to the Cloud Foundry instance and begins building out the environment. Deploying the code using the language build pack, creating and configuring a database, and spinning up a container to run the application. After everything is running, a confirmation message is displayed on the developers console that they can access the application at myapp.mycompany.local. Sure enough, the developer can go to the web address and see his application. Awesome, well what about scale? Do we have to figure out how to build orchestration tasks to deploy multiple instances behind a load balancer? Nope. Lets change our cf push to 4 instances. This will communicate with the Cloud Foundry instance and scale up the application to 4 instances. The built-in load balancer and router will be responsible for configuring everything and accessing myapp.mycompany.local is always available. This is what I call The Power of Platform as a Service.
6. So what happened here. No Virtual Machine was deployed during this entire process. You know what that means when you don’t have to worry about VM? Less things for operations to think about It also means that you never have to worry about an Operating System and application dependencies. Does the app need Windows? Ubuntu? RHEL? CentOS? It doesn’t matter. This also means you don’t have to ever worry about patch Tuesday or running apt-get update or yum update to keep security patches continually installed. I know all of us have a Windows NT server sitting somewhere. Never worry about performing an operating system upgrade because something is no longer in support Our developer never had to go to a portal and order a virtual machine and wait for it to be provisioned to run his code. This means you don’t need to worry about heavy orchestration tasks to make a server ready to accept a type of application All of this means less complexity in getting applications from the developer to actually running on the network More time can be spent on building the applications instead of building the environments where these applications will run Scaling the application is done through spinning up instances horizontally and increasing the amount of RAM required for each container vertically. Databases can also be scaled vertically through the application manifests It’s inheritably multi-tenant by using containers to create separation. Today it’s warden, tomorrow it’s docker. Our developer has full control of how his application runs through application manifests that tell how the application can scale VMs will use CPU and RAM for the OS even if the application is sitting idle. Now that we’re using containers, more and more applications can be crammed into our DEAs (distributed execution agents) where the containers run. The Cloud Foundry platform easily scales through a BOSH manifest