LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
PROBLEM:When building/running on-prem apps, you require hardware, OS, db, middleware, web servers, and custom software. ; Devs need to partner with infra with separate teams of network, db, testing, system management staff; Changes to software force us to do the whole cycle again; Problem areas: speed, agility, complexity ; acquiring environments ; continuous delivery; changing resource allocation; tightly coupled apps; separation of duties (devs doing infra, navigating the org); All those people have necessary contributions, but should infrastructure and app services play such a key role during app dev?
WHERE YOU WANT TO BE:Want to hit a point where building/changing an app doesn’t require engaging 12 different teams and having each team’s responsibilities bleed into another’s
WHAT IS IT:Definition: model of cloud computing where consumers leverage abstracted web platforms and have limited (no) visibility to infrastructure provider takes care of physical hardware, network, storage; delivers services like upgrades, maintenance, versioning, DR;SaaS = share apps, whole stack managed; IaaS = share infra, infra managed and user manages platform and apps; PaaS = share middleware, infra and platform managed and user manages apps; PaaS implements core app infra capabilities (middleware) found in on-prem app servers, integration platforms, BPM suites, DBMSs, portals and dev tools; present programming models and processing capabilities similar to on-premises solutions, but through cloud-specialized internal foundation; Get OS, runtimes, middleware, network, storage, servers all managed; provider takes responsibility for running the software stack (management, scale, provisioning, upgrades); key difference: elastic use, scale on demand, multi-tenancy, and self-service admin, use-based billing;
PAASBENEFITS: rapid provisioning – developers don’t request environments, they just push; clear sep of duties – infrastructure is not exposed to dev; dev couldn’t open ports, set DR strategy, etc; architect composite apps easier – combine application services in whatever way needed without separately engaging/negotiating with each provider (e.g. identity, integration, web); access to latest frameworks (public PaaS) – no waiting for internal teams to update platform versions, services; Operational benefits, developer benefits, cost benefits
DEMO:Data stored in Windows Azure Tables; Create Node.js app; create new directory on Windows File System; have npm, vmc installed; install express module; npm install express –g; create scaffolding; Express; update package.json to add dependencies for other modules; save, and do npm install to add new modules; create directory named "models" on file system; add new file named system.js; add js code; add controller named systemlist to routes directory; add js code; go to app.js file and add parameters for table storage; update index.jade; style the page; Run locally by doing “node app.js”; Visit http://127.0.0.1:1337 to see running application; See web request in command prompt; See that there is no data, add new row; View Azure Storage Explorer and see it there; Switch line in app.js to use Cloud Foundry-friendly port; Push to Cloud Foundry.com; vmc target api.cloudfoundry.com; vmc login --email XXXXX@YYYYY.com; vmc frameworks (we have ASP.NET at Tier 3); vmc runtimes ; vmc services (we have SQL Server at Tier 3); vmc push --runtime=node08; keep defaults; Change memory allocation; vmcmem <application name> 128; Change instance count; vmc instances <application name> 2; vmc stats <application name>;
RISKSlock in to unique (app) servicemost are public cloud and multi-tenantinsurmountable restrictions may not fit for a given app (see highly abstracted PaaS like Force.com)not a friendly destination for COTS appsmany PaaS platforms aren’t comprehensive replacements for each local application service
STRATEGIES / NEXT STEPS: have to change process, not just a technology problem; need: extreme automation, complete self-service, limited customization, SDLC support; fit for: public web properties; services that support COTS (web services, dashboards); internal custom web apps; mobile-friendly apps;
Platform-as-a-Service (PaaS) Overview
Innovation, not InfrastructureLeveraging PaaS for application delivery Richard Seroter Product Manager, Tier 3 @rseroter
Development and infrastructure teams often clash when building software.
Ideally, there is a clear separation of duties and clean handoffs.
Platform-as-a-Service (PaaS) is a cloud delivery model for applications composed of services managed by a 3rd party.
PaaS is about speed and agilitythrough standardized services.
Usage is growing, especially forpolyglot clouds, but some PaaSvendors have hedged bets and added IaaS services.
There is great diversity among the existing offerings. Force.com Heroku Cloud Foundry Google App Engine Windows AzureAbstraction AWS Danger Zone Portability