Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Tech huddle paas_session
Similar to Tech huddle paas_session (20)
Recently uploaded
Recently uploaded (20)
Tech huddle paas_session
- 1. DevelopingonCloud Rob Edwards – Consulting Systems Engineer,Cloud &Data Centre Software @clijockey
- 2. Satya Nadella - Microsoft “Every Business will be a Software Business”
- 3. Speed of Applications Delivery is Critical
- 4. Building Applications BUY Commercial Off-the- Shelf Software (COTS) BUILD Traditional Architectures/Methods BUILD Modernise: “Cloud Ready” BUILD Cloud Native / Microservice Mostly Hidden / Irrelevant Our developers in our environment(s) (inc. contracted developers / ISVs) Integrated Infrastructure Cisco Validated Design, Blueprints, I&O Automation Integrated Infrastructure Automation, Orchestration, Self Service Integrated Infrastructure / Commodity / Programmable Infrastructure-as-a-Service Runtime Environments Application Framework / Programming Environment Integrated Infrastructure / Commodity / Programmable Infrastructure-as-a-Service Runtime Environments Application Framework / Programming Environment PLATFORM-as-a-SERVICE PLATFORM-as-a-SERVICE / Container STACK
- 5. Building Applications Mostly Hidden / Irrelevant Our developers in our environment(s) (inc. contracted developers / ISVs) Integrated Infrastructure Cisco Validated Design, Blueprints, I&O Automation Integrated Infrastructure Automation, Orchestration, Self Service Integrated Infrastructure / Commodity / Programmable Infrastructure-as-a-Service Runtime Environments Application Framework / Programming Environment Integrated Infrastructure / Commodity / Programmable Infrastructure-as-a-Service Runtime Environments Application Framework / Programming Environment PLATFORM-as-a-SERVICE PLATFORM-as-a-SERVICE / Container STACK Cloud Management Cloud Native App Development Platform Container Deployment and Automaton BUY Commercial Off-the- Shelf Software (COTS) BUILD Traditional Architectures/Methods BUILD Modernise: “Cloud Ready” BUILD Cloud Native / Microservice
- 6. Virtual Machines vs. Containers Server 1 HYPERVISOR GUEST OS BINS/LIBS APP 1 GUEST OS BINS/LIBS APP 2 VM1 VM2 Server 2 HOST OS BINS/LIBS APP 1 BINS/LIBS APP 2 CONTAINER ENGINE C1 C2 Runs Application on Virtual OS Decouple Application from Infra Environmental Consistency Density Boots in msec/sec Runs OS on Virtual Hardware Full OS in each VM Boots in sec/mins Dockerfile FROM unbuntu:14.04 RUN apt-get install –y-redis-server EXPOSE 6379 ENTRYPOINT [“usr/bin/redis-server”]
- 7. Virtual Machines Server 1 HYPERVISOR GUEST OS BINS/LIBS APP 1 GUEST OS BINS/LIBS APP 2 Server 2 HYPERVISOR GUEST OS BINS/LIBS APP 3 GUEST OS BINS/LIBS APP 4 VM1 VM2 VM3 VM4
- 8. Virtual Machines Server 1 HYPERVISOR GUEST OS BINS/LIBS APP 1 GUEST OS BINS/LIBS APP 2 Server 2 HYPERVISOR GUEST OS BINS/LIBS APP 3 GUEST OS BINS/LIBS APP 4 Server 3 HYPERVISOR GUEST OS BINS/LIBS APP 5 Shared Storage
- 9. Containers Immutable and Ephemeral Server 1 HOST OS BINS/LIBS APP 1 BINS/LIBS APP 2 Server 2 HOST OS BINS/LIBS APP 3 BINS/LIBS APP 4 Server 3 HOST OS Shared Storage CONTAINER ENGINE CONTAINER ENGINE CONTAINER ENGINE C1 C2 C3 C4 $ docker run -p 5000:5000 simple_flask:dockerfile python hello.py C5
- 10. Containers Immutable and Ephemeral Server 1 HOST OS BINS/LIBS APP 1 BINS/LIBS APP 2 Server 2 HOST OS BINS/LIBS APP 3 BINS/LIBS APP 4 Server 3 HOST OS Shared Storage CONTAINER ENGINE CONTAINER ENGINE CONTAINER ENGINE C1 C2 C3 C4 C5 C6
- 11. Containers Immutable and Ephemeral Server 1 HOST OS BINS/LIBS APP 1 BINS/LIBS APP 2 Server 2 HOST OS BINS/LIBS APP 3 BINS/LIBS APP 4 Server 3 HOST OS Shared Storage CONTAINER ENGINE CONTAINER ENGINE CONTAINER ENGINE C1 C2 C3 C4 C6 $ docker run -p 5000:5000 simple_flask:dockerfile python hello.py
- 12. Traditional Servers Describing the New World Cloud Infrastructure Containers Transient Containers Containers at Scale http://searchservervirtualization.techtarget.com/feature/Application-containers-continue-data-center-invasionhttp://www.cloudcomputingexpo.com/node/3293710
- 13. Why “Cloudify “Apps BUILD Modernise: “Cloud Ready” BUILD Cloud Native / Microservice BUY Commercial Off-the- Shelf Software (COTS) BUILD Traditional Architectures/Methods Source: Forester June 2015 20% “Elastic” Apps redeploy Apps “as-is” 70% Lift and Shift Apps refactoring
- 14. Modernise: ‘Cloud-ready’ Re-architect + re-package? Application Framework Runtime Platform Infrastructure Automation Infrastructure Dev IT Ops IT Ops IT Ops
- 15. Source: Forester June 2015
- 16. BUILD Cloud Native / Microservice Cloud Native & Microservices BUILD Modernise: “Cloud Ready” BUY Commercial Off-the- Shelf Software (COTS) BUILD Traditional Architectures/Methods DevOps Shared responsibility Common incentives, tools, process and culture CI/CD Release early and often Higher Quality of Code Microservices Loosely coupled components Automated deploy without waiting on individual components CLOUDNATIVE
- 17. Platform-as-a-Service - Common Functions Programming Environment (Native or IDE Plugin) Service Brokering – Shared Routing Tier Managed File Transfer and Artifact Distribution Dynamic Provisioning - Placement Register message queuing Fault Tolerance and Automated Recovery Dynamic Provisioning - Scaling Dynamic Provisioning – HA Logging Metering Health - Performance Monitoring Authentication and End User Onboarding Dynamic Provisioning – ‘Sharding’ Data Externalisation – Bind Apps with Data Services Automate Load Balancing and DNS Runtime Sandboxes and Isolation Workflow Engine Deployment Templates Map session state to distributed cache IaaS Integration
- 18. The Perfect Dev Experience? $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ Production (or Testing area)My Branch My Branch My Branch Make sure I/we haven’t messed up. If OK, put it out there & keep it working. Performance Information DEV
- 19. Source: Forester June 2015
- 20. Containers at Scale Infrastructure-as-a-Service ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service MARATHON Leader MARATHON Secondary MARATHON Secondary CONSUL Agent CONSUL Agent CONSUL Agent CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER MESOS Master MESOS Master MESOS Master MESOS Master CONSUL Agent DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH
- 21. Containers at Scale Infrastructure-as-a-Service ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service MARATHON Leader MARATHON Secondary MARATHON Secondary CONSUL Agent CONSUL Agent CONSUL Agent CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER MESOS Master MESOS Master MESOS Master MESOS Master CONSUL Agent DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH CONTROL NODE 1 CONTROL NODE 2 CONTROL NODE 3 WORKER NODE 3 WORKER NODE 1 WORKER NODE 2
- 22. Containers at Scale Infrastructure-as-a-Service ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service MARATHON Leader MARATHON Secondary MARATHON Secondary CONSUL Agent CONSUL Agent CONSUL Agent CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER MESOS Master MESOS Master MESOS Master MESOS Master CONSUL Agent DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH CONTROL NODE 1 CONTROL NODE 2 CONTROL NODE 3 WORKER NODE 3 WORKER NODE 1 WORKER NODE 2 What about: • Initial host deployment and registry? • External-to-[new] services comms and records? • Service-to-Service comms? • Log collection, forwarding, and analysis? • Storage for ‘statefulness’? • Virtual networking? • Task scheduling? • API management?
- 23. • ALL THE COMPONENTS FOR YOUR MICROSERVICES PLATFORM • OPEN SOURCE • CLOUD AGNOSTIC.
- 24. PaaS vs. Container Stacks The lines are blurring Programming Environment (Native or IDE Plugin) Service Brokering – Shared Routing Tier Managed File Transfer and Artifact Distribution Dynamic Provisioning - Placement Register message queuing Fault Tolerance and Automated Recovery Dynamic Provisioning - Scaling Dynamic Provisioning – HA Logging Metering Health - Performance Monitoring Authentication and End User Onboarding Dynamic Provisioning – ‘Sharding’ Data Externalisation – Bind Apps with Data Services Automate Load Balancing and DNS Runtime Sandboxes and Isolation Workflow Engine Deployment Templates Map session state to distributed cache IaaS Integration
- 25. Source: Forester June 2015
- 26. • Platform for cloud native development. • Developer/Operations friendly. • Easy-to-adopt, easy-to-use. • Builds a ‘Developer-Experience / PaaS layer’ on top of our Mantl • An end to end, integrated stack for running container workloads. Including Deployment automation & assurance • Designed to grow into a platform for application and data services.
- 27. SHARED STORAGE: (EMC, NetApp, IBM, HDS, Nimble…) CONFIGURATION MANAGEMENT: Puppet, Chef, Ansible BUY Commercial Off-the- Shelf Software (COTS) BUILD Traditional Architectures/Methods BUILD Modernise: “Cloud Ready” BUILD Cloud Native / Microservice METAPOD Enterprise Cloud Suite / UCSD APPLICATION CENTRIC INFRASTRUCTURE (ACI) UNIFIED COMPUTE SYSTEM (UCS)
- 28. More Information MANTL: mantl.io Shipped: ciscoshipped.io Microservices: martinfowler. com/articles/microservices.html Applications & Microservices with Docker & Containers - thenewstack.io DevOps: The Project Phoenix book More Information
Editor's Notes
- Today talked about IaaS and how it enables easier consumption of infrastructure resources Flexibility and more on-demand characteristics Build, Ship, Run Not sure what panto character I am!!! Sure wont answer all your question today but the idea is to make you aware of things that Cisco are doing that you might not be aware off. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ speed up delivery and deployment of applications. The current process is time consuming and has many processes that are manual and laborious. For example – currently it is time consuming for application owners to get application single sign on for external facing applications The IT team is looking to drive higher value service offerings to the business and provide these services at the greatest cost/value ratio as possible where auditing and asset protection is critical Key Value Themes: Create Services that allow for more agility and innovation which align to security / auditing and operating Faster SDLC Time to market Limiting project resource-management bottlenecks Authorisation services Know Me project – build applications that leverage the understanding of your clients Reduce cost of IT Services Higher Data Centre utilisation Hybrid Cloud Reduce management costs of application portfolio Provide world class IT services to the BUs and drive innovation Leverage current investments and work with existing and new applications This ‘win-win’ helps by: Removing all friction of consuming IT from the developer, incentivising them to align with consuming IT in a compliant way Reducing the prevalence of “shadow IT” by offering IT in the way a developer might consume in public cloud Enabling IT to be a broker to the public cloud by leveraging hybrid capabilities Ensuring architecture and maintenance consistency across the application portfolio Providing a standardised architecture and runtime pattern which exposes developer services and APIs which can reduce development times and create more value in the SDLC Understanding the IT as a Service theme is important in connecting with the higher order strategic benefits of Apprenda
- All about the apps!! Today talked about IaaS and how it enables easier consumption of infrastructure resources Flexibility and more on-demand characteristics Build, Ship, Run
- COTS Based on validated & reference designs Relationship between development and ops is an instructions document Detailed instructions on getting it deployed (type of servers, virtual appliances etc.) HA/resliliance comes from the infrastructure and always up and running TRADITIONAL Apps developed in house developers hand off to operations operations support with closer links to devs Adopted more automation (ECS, config mgmt tools, CliQr) close links to infra and app mgt. Start to publisise services transactional relationship Self service portals being the handover point between teams MODERNISE Move to providing consistent, repeatable environment Closer work with operations and development teams PaaS sit on top of it More abstraction of the underlying resources CLOUD NATIVE Evolution of PaaS Even closer relationships with teams and emergence of container stacks Removes the friction of consuming IT/infra for the developer Enable better hybrid cloud capabilities Start to offer public cloud like services locally ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ The aim of this slide is to account for the Top 10 dev languages – what’s popular, what’s universally used vs. used in one type of approach, what’s ‘new vs. old’, when it comes to PaaS, what do the language frameworks imply a focus on from a Dev/software architecture pov. Notes. Python, JS, Perl, Ruby = scripting languages in the main Ruby onRails A web framework written in the Ruby Node.js JavaScript runtime built on Chrome's V8 JavaScript engine. COTS often = Client-Server Monolith (1 instance-to-many in same tenant) – 3-tier? - Windows or Linux Traditional often = Client-Server Monolith with Waterfall dev/deployments and clear line between Dev and Ops – 3-tier? – Windows or Linux Modernise often = Move towards DevOps, Move towards CI/CD/Agile, Add SaaS front-end, Rebuild elements of the App, Add Service APs, Add service message queue capability for distribution, look at different storage techniques, add support for ephemeral/immutable instances, etc. – More Linux, Windows if in a Windows PaaS (Azure, Apprenda) Cloud-native = Agile/DevOps, CI/CD, Microservices architecture built using languages that are shown (Go, Scala, etc. rising), Separate data, business logic and user interfaces, true IaaS and Infrastructure Programmability, possibly PaaS but likely Container Stack, etc. - Mostly Linux today but MS filling the gap The choice of languages reflect the above COTS Client software is main concern. Looking for a HA foundation with validated designs for applications. Cater for Test/Prod. Traditional Similar to COTS but efforts around the Ops to Dev ‘interface’ offer value. Traditional integrated infrastructure + tooling (UCS Director/ECS, vRealize, HP, etc.) Modernise + Cloud-native Different territory and lots of value from PaaS + [purple box]. PaaS doesn’t offer much in Build-Traditional but often talked about in that area (in a move to PaaS as-is?) capacity… PaaS Programming Environment inc. Dev tools Runtime Environment Runtime (DB, Web, etc.), middleware, and OS Dynamic provisioning Virtual, BM, and Container machine management Artifact distribution Load balancing Fault tolerance Messaging bus System monitoring Logging Metering Identity “PaaS solutions provide support for both the development and deployment of software application in the cloud.” “While one-to-one mappings of software from on-premise to cloud platforms are possible, statelessness and data externalisation from stateful sessions and applications emerge as solutions if cloud benefits such as elasticity and performance are aimed at.” “PaaS Migration is the process of moving from the use of one software operating and deployment environment to another environment, e.g. from an on-premise solution to the cloud” “Statelessness is a requirement for VMs and applications to be deployable without data. As a consequence, data externalisation is required to prepare for scale-out, which necessitates externalisation for an efficient management” of elasticity requirements.“Customers do not manage their virtual machines, but are concerned with middleware components, their development and deployment. They develop and deploy applications within an existing API or programing language. PaaS Migration is the process of moving from the use of one software development and deployment environment to another environment.” “Two classical software architecture concerns need to be embraced by a PaaS architecture migration process solution: architecture re-engineering, i.e. the adaptation and modification of a software solution to meet the requirements of elastic and resilient cloud provisioning, architecture ageing, i.e. the validation and correction of programming and data aspects aiming at incorrect and outdated structures. Migration Techniques: Direct deployment to PaaS with limited changes (either the entire application or part of it) Immediate pay-per-usage and flexibility from provider pov (no good for Enterprise?) Deployment on PaaS with some level of architectural and/or design transformation Programming Models for Stateless Programming elasticity (scale out, run anywhere) and scalability gains Databases for State Management elasticity and scalability gains Data Externalisation for Resiliency resiliency gains In case of PaaS, the consumer controls software deployment and configuration settings whereas the provider provides the application runtime environment, development life cycle support tools and other services that are required to host the consumer's application. PaaS: limited interoperability and lack of common terminology Fallacies + Co-location of the application layers and components Resilience, low latency, and high bandwidth connectivity between layers Applications disposition for vertical scaling, considering the underutilized infrastructure in traditional data centers Performance optimization approach, based on application deployment platform tuning, that relies on fine-grained control over the deployment platform Use of multiple technologies and frameworks, many of which may be non-standard Dependence on enterprise level shared services related to security, directory services, data management and so on Complex application integration scenarios with reliance on multiple architectural patterns Application design patterns (for example, sticky session, synchronous v/s asynchronous communication) Architectural patterns needing heavy data traffic within the WAN PaaS provider should support technologies such as the enterprise service bus, message oriented middleware, managed file transfer
- What we have with virtual machines today; VM separate the operating systems from the underlying hardware it runs on if you want multiple applications you will have multiple virtual machines each VM has a full operating system application deployed on top of the OS and the required libraries and binary's installed can be big and hinders portability Hypervisor level isolations an also an OS per application Benefit is you can run multiple operating systems on the same hypervisor Also overhead of multiple servers Boots in minutes If you compare and contrast to containers (very fast paced technology) – really 2013/2014 made appearance with Docker Separates applications from the underlying operating system that it runs on extremely fast and portable for applications concept been around for a long time uses features in the Linux Kernal (CGroups, namespaces, network space) Docker made it easy and popular when came around around 2 years ago have a single operating systems applications are isolated within the OS user container object each container is isolated from each other (similar to logical partitions) minimise the overhead of having multiple OS makes applications portable can develop on laptop and then move to infrastructure easliy (it’s actually the same container) all it needs to run is in the container removes dependency hell benefits scalability (really small) portable density (can put more on machines) drastically reduces the development lifecycle no longer tided to the env under the app really enabling mincroservices
- Based on the time it takes to get a VM up and running with the correct libraries and applications installed (even with automation) we look to keep them up and running as much as possible by building in HA capabilities into the infrastructure. If upgrades are needed then the existing VM would be fed and waters and an upgrade process followed.
- Should a problem occur in the infrastructure mechanisms are in place to migrate the workload to another part of the infrastructure. This is usually transparent to the application and the application doesn't’t actually give any thoughts to to HA. This has been challenging with public cloud providers in that parts of the infrastructure can disapear with little or no notice and it may not automatically move instances around. As a result application developers started to add logic into the application and its management so that should something happen it would would take care of HA rather than relying on the infrastructure. For scale will make VM bigger rather than depoying a new server
- Now if we look at the way we work with containers a different approach is taken. If we use the same scenario of wanting to upgrade an application to support a new feature rather than creating a release window and working out how to upgrade the application we just deploy new tested container to replace the old one and destroy the old one. Thing of the value of this sort of thing when it comes to testing code, you can very quickly test features as you go and destroy the test environment rather than spending all your time manipulating VMs or spinning up new VM for testing purposes. For scale just deploy a new container and add to the service
- This new world has been described in a number of different ways on the Internet and by the pionears of DevOps http://www.cloudcomputingexpo.com/node/3293710 http://searchservervirtualization.techtarget.com/feature/Application-containers-continue-data-center-invasion
- Cant just take a VM and put in the cloud need to make app cloud ready Why? (story for each) Elasticity/scalability Location independence Best location at a given time Speed and time to market of a service Application accessibility Flexibility Pay for what you use Considerations Latency – often more variable latency Noisy neighbors Applications can be very chatty App dependencies on static mappings Pubic in nature (security profile is different – ops often take care of it) Deployment of applications should be automated (not next next next GUI installs) Location of resources Session state and caches ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ LIFT AND SHIFT 70% Redeploy Apps “As-is” Simple & Quick Low- initial cost Low elasticity ELASTIC 20% Load-balance, add OSS infrastructure Let provider auto-scale Some refactoring OPEX savings CLOUD NATIVE 10% Designed with the Internet as the OS Service Composition Designed for failure CI/CD ICONS Scalability/Elasticity (only the components that need to), Place app anywhere you want based on ‘best fit’ criteria, Reduce costs, Speed/Agility/Time-to-market, Deal with distribution of services and dependencies (from multi-sourcing/cloud model for many apps inc. SaaS consumption). Address identity management across systems, Make the App accessible in a SaaS fashion (Public/no VPN) + add multi-tenancy to app, Independence (not nailing colours to mast/lock-in), Maximise asset utilisation – only pay for use/need at App level. Attracting talent/move with the times, Putting the business’ resources in the right places – most value, Add continuity capabilities, Gain visibility – performance, compliance, and metering, App architecture changes can aid resilience of app.
- CliQR – Application defined management platform Platform to model, deploy & manage clouds, applications Multi-cloud Model what an application should looks like, a blueprint and build policy & governance around it Pick the best cloud & 1 click deploy Visibility and control of cloud usage Policy Finance controls Usage metering governance Application migration and management Common functions of a PaaS platform and environment to allow developers to build applications Runtimes environments for various languages Scaling Logging Visibility and health of the app Show back Security Service setup Helps address previous problems we have mentioned ----------------------------------------------------------------------------------------------------------- Pivotal + OpenShift Newer practices and languages Modernisation is expected Apprenda New and Old Port apps as-is and/or modernise A Virtual Machine centric world The “Software-defined Data Centre” isn’t enough here infra inefficiencies + gap between apps and infra CliQr = push away from scripting and workflows/orchestration to ‘Application defined, declarative types of control’ Average = 4 Cloud Platforms. 1 in 8 orgs = 7+ CliQr video here You want to SaaS-ify your app and/or move it to a Cloud platform – your own (and it *might* move to another) or you’re moving straight out to a Provider’s/Public cloud now…Tell a story here: Moving your applications to ‘cloud’ can be looked upon in the following three ways: Rewrite the application to exploit the cloud features Replace the application with a SaaS equivalent Relocate the application to the cloud environment 1 and 3 are closely tied as far as a steps are concerned with 3 being most prevalent… Considerations: Cost of different hosting options – visibility and comparison needed Technical offerings of different hosting options – visibility and filtering of candidates Different latencies introduced by Cloud (i.e. the app or a part of it moves somewhere out on the internet off a LAN) external dependencies? (e.g. AD/LDAP or SQL DB) Separation of App from its data (data externalisation) to keep it portable Multi-tenant SaaS HTTP front-end Refactor? “backwards-compatible” PaaS means developers can reuse languages, frameworks e.g. Apprenda Revise? Dev project modify or extend the existing code base to support legacy modernisation requirements, then use rehost or refactor options to deploy to cloud Rewrite? Rebuild the solution on PaaS, discard code for an existing application and re-architect the application Another goal is to expand the ways that users can access Adatum's applications. Currently, applications are only accessible from the intranet. Applications that are located in the public cloud are, by definition, available over the Internet. However, the public cloud also raises questions about authentication. Many of Adatum's applications use Windows authentication so that users aren't required to enter application-specific credentials. Adatum is concerned that its users would need special credentials for each application in the public cloud. A third goal is that at least some of Adatum's applications should be portable. Portability means that the application can be moved back and forth between a hosted data center and an on-premises data center without any modifications to the application's code or its operations. If both options are available, the risks that Adatum incurs if it does use the cloud are reduced. In addition to its concerns about security, Adatum has two other issues. First, it would like to avoid a massive retraining program for its IT staff. Second, very few of Adatum's applications are truly isolated from other systems. Most have various dependencies. Adatum has put a great of deal effort into integrating its systems, even if not all of them operate on the same platform. It is unsure how these dependencies affect operations if some systems are moved to the public cloud.
- Build applications with cloud in mind Green field apps Follows 3 movements DevOps CI/CD Microservices Common theme is; build depoy run Much closer to business demand speed agility pay for what use Automation is critical Consisitancy between dev environments and production environments
- “PaaS Migration is the process of moving from the use of one software operating and deployment environment to another environment, e.g. from an on-premise solution to the cloud” “Statelessness is a requirement for VMs and applications to be deployable without data. As a consequence, data externalisation is required to prepare for scale-out, which necessitates externalisation for an efficient management” of elasticity requirements.“Customers do not manage their virtual machines, but are concerned with middleware components, their development and deployment. They develop and deploy applications within an existing API or programing language. PaaS Migration is the process of moving from the use of one software development and deployment environment to another environment.” “Two classical software architecture concerns need to be embraced by a PaaS architecture migration process solution: architecture re-engineering, i.e. the adaptation and modification of a software solution to meet the requirements of elastic and resilient cloud provisioning, architecture ageing, i.e. the validation and correction of programming and data aspects aiming at incorrect and outdated structures. Migration Techniques: Direct deployment to PaaS with limited changes (either the entire application or part of it) Immediate pay-per-usage and flexibility from provider pov (no good for Enterprise?) Deployment on PaaS with some level of architectural and/or design transformation Programming Models for Stateless Programming elasticity (scale out, run anywhere) and scalability gains Databases for State Management elasticity and scalability gains Data Externalisation for Resiliency resiliency gains In case of PaaS, the consumer controls software deployment and configuration settings whereas the provider provides the application runtime environment, development life cycle support tools and other services that are required to host the consumer's application. PaaS: limited interoperability and lack of common terminology Fallacies + Co-location of the application layers and components Resilience, low latency, and high bandwidth connectivity between layers Applications disposition for vertical scaling, considering the underutilized infrastructure in traditional data centers Performance optimization approach, based on application deployment platform tuning, that relies on fine-grained control over the deployment platform Use of multiple technologies and frameworks, many of which may be non-standard Dependence on enterprise level shared services related to security, directory services, data management and so on Complex application integration scenarios with reliance on multiple architectural patterns Application design patterns (for example, sticky session, synchronous v/s asynchronous communication) Architectural patterns needing heavy data traffic within the WAN “continuous delivery and horizontal architectures” “provision and bind web and mobile apps with leading platform and data services such as Jenkins, MongoDB, Hadoop, etc.” HA Desired State vs. Actual State tracking New instances if not matching. Restart VMs. Scale into different AZs. “development and test to staging and production environments with no changes.” uses common computing resources including hardware, operating system, software (i.e. application code), and a single underlying database with a shared schema to support multiple customers simultaneously Isolation i.e. Dev - Test - Prod
- Keep it working auto-scale, economically Microservice = only scale the bit that needs to scale…
- MANTL: Under the Covers Open source infrastructure agnostic container stack Deploys to metal, AWS EC2, GCE, DigitalOcean, OpenStack, VMware, etc. Easy to deploy Support emerging workloads Batteries included: built-in security, logging, HA, scheduling, service discovery Integrates Mesos + HashiCorp Consul Deployment automation via Ansible Works out of the box w/ LogStash, collectd, Docker, Calico, GlusterFS, etc. Developed on GitHub w/ over 1800 stars, 200 forks, 50 contributors Added Kubernetes support (Kubernetes + Mesos) Service discovery allows network communication between services. It is an essential configuration step when you wish to run an application distributed across a data center. All agents can run the DNS or HTTP interfaces, and are responsible for running checks and keeping services in sync. Client - forwards all RPCs to a server. Performs health checks against services and gossips health state changes. Server – responds to RPC requests. Exchanges WAN gossip with + forwards queries to other DCs. Example: graphite.consul.service Returns a random IP of a live graphite relay node New nodes? Register them with Consul and they automatically appear in the list the next time a client resolves that hostname. You can place Consul “behind” internal DNS servers and forward all requests for the “consul” domain name to a consul agent running on the DNS servers or you can route all DNS requests to the local Consul agent running on each node and have it forward everything “non-Consul” to the DNS servers Consul holds the location (URI) and health of every service on every host, and makes this data available via multiple channels, such as a REST API and GUI. The API also lets you make complex queries and get the service data segment you’re interested in. For example: Get me all the addresses of all instances of service ‘X’ from Datacenter ‘Y’ in ‘staging env’ (tag). dnsmasq = Get containers to talk with each another using their names, easily allowing for IP address changes (containers have different IP addresses on start) Logstash = Forward logs GlusterFS Scalable network filesystem “FUSE” mount 3 copies across distributed filesystem Dedicated containers/nodes? Vault for managing secrets Mesos = efficient resource isolation and sharing across distributed services Efficient and flexible use of resources mesos-consul populating Consul service discovery with Mesos tasks Mesos-consul automatically registers/deregisters services run as Mesos tasks This means if you have a Mesos task called TechHuddle, this program will register the application in Consul, and it will be exposed via DNS as techhuddle.service.consul also does Mesos leader discovery, so that leader.mesos.service.consul will point to the current leader Mantl API easily install supported Mesos frameworks on Mantl (DCOS https://github.com/mesosphere/universe) Mantl UI a beautiful administrative interface to Mantl NGINX front-end (proxying) Kong for managing APIs
- MANTL: Under the Covers Open source infrastructure agnostic container stack Deploys to metal, AWS EC2, GCE, DigitalOcean, OpenStack, VMware, etc. Easy to deploy Support emerging workloads Batteries included: built-in security, logging, HA, scheduling, service discovery Integrates Mesos + HashiCorp Consul Deployment automation via Ansible Works out of the box w/ LogStash, collectd, Docker, Calico, GlusterFS, etc. Developed on GitHub w/ over 1800 stars, 200 forks, 50 contributors Added Kubernetes support (Kubernetes + Mesos) Service discovery allows network communication between services. It is an essential configuration step when you wish to run an application distributed across a data center. All agents can run the DNS or HTTP interfaces, and are responsible for running checks and keeping services in sync. Client - forwards all RPCs to a server. Performs health checks against services and gossips health state changes. Server – responds to RPC requests. Exchanges WAN gossip with + forwards queries to other DCs. Example: graphite.consul.service Returns a random IP of a live graphite relay node New nodes? Register them with Consul and they automatically appear in the list the next time a client resolves that hostname. You can place Consul “behind” internal DNS servers and forward all requests for the “consul” domain name to a consul agent running on the DNS servers or you can route all DNS requests to the local Consul agent running on each node and have it forward everything “non-Consul” to the DNS servers Consul holds the location (URI) and health of every service on every host, and makes this data available via multiple channels, such as a REST API and GUI. The API also lets you make complex queries and get the service data segment you’re interested in. For example: Get me all the addresses of all instances of service ‘X’ from Datacenter ‘Y’ in ‘staging env’ (tag). dnsmasq = Get containers to talk with each another using their names, easily allowing for IP address changes (containers have different IP addresses on start) Logstash = Forward logs GlusterFS Scalable network filesystem “FUSE” mount 3 copies across distributed filesystem Dedicated containers/nodes? Vault for managing secrets Mesos = efficient resource isolation and sharing across distributed services Efficient and flexible use of resources mesos-consul populating Consul service discovery with Mesos tasks Mesos-consul automatically registers/deregisters services run as Mesos tasks This means if you have a Mesos task called TechHuddle, this program will register the application in Consul, and it will be exposed via DNS as techhuddle.service.consul also does Mesos leader discovery, so that leader.mesos.service.consul will point to the current leader Mantl API easily install supported Mesos frameworks on Mantl (DCOS https://github.com/mesosphere/universe) Mantl UI a beautiful administrative interface to Mantl NGINX front-end (proxying) Kong for managing APIs
- How does Shipped use Mantl? Shipped is purpose built to make deploying docker applications super easy, so Mantl was built alongside it to make hosting these applications easy. Shipped actually runs itself alongside other tenant applications on Mesos workers. Shipped allows developers to build their application into a docker image. Once you have a containerized app, you can deploy with the push of a button. Behind the scenes, this goes something like this: POST a request to Marathon that starts at least one new task with the docker container. We include some special environment variables that are consulted by HAProxy-Consul later to get hostnames correct. Marathon-Consul watches the Marathon event bus to update Consul with the running services and the ports they started on. HAProxy-Consul re-writes the HAProxy configuration to route hostnames to the correct containers (for now this is a round-robin setup). All the worker nodes run Logstash. It slurps up Mesos logs and output from each container’s stdout/err and forwards them on to Elastic Search. This allows us to make deployment failures. It also gathers logs from every container and makes them available in the management dashboard CAdvisor collects metrics from each container and sends them to Elastic Search for later consumption.
- What could it look like in a very simple format architecture…
- Why Mantl: Deploy Containers in Production at Scale Curated stack saves time on design and deployment 100% Open sourced tools – no vendor lock in Low cost of entry Add holder for videos