Architecture & Operations

Editor's Notes

• #5: 1. “Cowboy devs” - “It’s hard when ppl don't follow protocol” - “when devs do something that impacts us w/out telling us” 2. “ideally devs would be on pager duty”: “Devs turn to ops when things break - a lot of time bc ops guys fix everything all the time, they know what every service did, know common problems you might have” 3. Interruption-driven lives: “difficult to manage work. we're constantly blowing deadlines. unexpected things come up” We are entering into a fundamentally new era of business, where people have to build new experiences and new capabilities that are driven by software in order to compete in the market. Competing in this service oriented world means moving fast with consistency and reliability. How will your enterprise Manage all the Test, Dev and QA environments Patch and Update Production Manage failures and usage spikes How do you support changes not only at the application level but on the middleware, os, platform? Those are the questions PCF is mainly intended to solve. By balancing Speed and operational excellence.
• #6: Take away: Left Silo: Silos & Right side: Dev + Operation work together. Livrer continuellement, non seulement le jour 1 mais egalement jour 2 et au dela.` 80% is resources is spend on day 2 and beyond.
• #7: 2. Remember the good old days when you had a separate chunk of plastic to take live video, make phone calls, listen to music, snap a picture with friends, get instant messages from co-workers, check the time and use that new fangled world wide web? Can you imagine swapping your smart phone for 8 pieces of gear that barely fit into a duffle bag? We are on the cusp of a similar transition in IT Operation. You shouldn’t need to work with different vendors to support your applications. You shouldn’t need a separate vendor for your middleware, load balancer, system provisioning and policy management. That’s the value proposition of PCF 3. No more Script/Templates 4. 5. Remediation: What happened if a application failed? What about a VM? PCF manages transformations between existing and desired system states, using immutable infrastructure. LOB care about Ops costing less, developer delivering faster. PCF is best positioned to respond to that requirement. The systems need to be able to change. Software needs to be updated. That’s what delivery means. Software also fails. The system needs to detect and recover from failure, while minimizing any impact. Capacity needs to be balanced against demand. Adding and removing capacity must become routine and trivial. Similar to other configuration tools you might be familiar with, BOSH is based on declarative idempotent resource abstractions. What do all those words mean? They mean that BOSH isn’t told what to do, BOSH is told what should be, and then does the right thing to make that be true. In BOSH these declarations abstract a service deployed as a distributed system, where servers are a lower level primitive in the service abstraction, and BOSH handles the orchestration with rolling no downtime upgrades and canary deployments out of the box.
• #8: Let talk a bit about the overall architecture of PCF
• #9: This is open source cloud foundry. Briefly describe each function Service broker provisions the logical instance and makes it available to a CF space.
• #24: Ops Manager at https://206.128.159.234. Credentials admin / Savvis11
• #38: Not doing this for one app. Doing this across the platform for all apps.
• #39: There is a hierarchy to isolate the tenants on a CF environment.
• #40: Take away: You can expose legacy middleware and as an Operator, you decide what service your developers consume.
• #41: admin / fd60669ba943bd852c55
• #42: Key take away: The self service concept is very powerful. Not only do you have access to the public offering from AppDirect (a Cloud Market place provider) but you can also define your own. For example you can decide to expose your own system to developer to consume, It can be an internal Oracle or DB2 database, a DB preloaded with data for testing purpose and so own. admin / fd60669ba943bd852c55
• #43: Key take away: The self service concept is very powerful. Not only do you have access to the public offering from AppDirect (a Cloud Market place provider) but you can also define your own. For example you can decide to expose your own system to developer to consume, It can be an internal Oracle or DB2 database, a DB preloaded with data for testing purpose and so own. admin / fd60669ba943bd852c55
• #44: Pre-requisite: Service broker already created: Connect as a cloud-developer and show the empty market place. Connect as a mobile-developer and show the empty market place Connect as an operator and create the Oracle service broker: cf create-service-broker myoracle user password <URL> Enable one plan for Cloud Team org Enable another plan for Mobile Team org. Connect back in the “Cloud Team space” and show the Cloud Plan is there and not the Mobile Plan: cf enable-service-access myoracle -p Cloud -o "Cloud Team" Connect back in the “Mobile Team” space and show the Mobile Plan is there and not the Cloud Plan: cf enable-service-access myoracle -p Mobile -o ”Mobile Team" Take away: You can expose legacy middleware and as an Operator, you decide what service your developers consume.
• #46: Needed a consistent way to interact with different IaaS providers. The outer layer is what operators work with, typically through Ops Manager or a command line.
• #50: Those are some benefits we get with BOSH
• #53: Traditional ways: Morgan for ((i=1;;i++)); do curl "http://cdeveloper. pcf.centurylinkcloud.com/ping"; echo ; sleep 1; done bundle exec rake package VERSION=2.6
• #57: Demo: cf nozzle
• #58: We provide a built-in log aggregation service, built-in APM metrics and utilization based auto-scaling so that you can monitor the health of your applications and scale out without human or 3rd party tool intervention. Also at Pivotal we understand that you have made lot of investment in log/monitoring visualization tools. Those can be leverage as well. Our solution Make every component transparent and monitorable. Built-in separation concern between Infrastructure, Middleware and App. Benefits Operator friendly. Quicker to isolate in which layer the problem occurred. Centralized end-to-end transparency for root cause analysis Elimination of environment drifts Quicker resolution time/shorter MTTR (Mean time to resolution)
• #74: Conclusion: This is why we see people who are operating the Pivotal Cloud Foundry platform spending a lot more time thinking strategically about which services they’d like to offer, how they’d like to scale the platform, where they want to deploy the platform, where certain applications should be run, rather than having to think about patching, compilation, integration, and other nuances etc
• #80: In both ‘service instance creation’ and ‘service binding creation’, org/space/plan identifiers are provided to the ‘service broker’ This allows the broker flexibility what to do
• #81: Fine grained, policy-based network access whitelists to restrict network traffic System defaults with additional policy mapped to groups of applications Network traffic auditing
• #82: Emphasize on the WHY/HOW/WHAT here.