Conversations in the Cloud

Editor's Notes

• #6: Great articulation of how it’s not about the cloud: https://www-forbes-com.cdn.ampproject.org/c/s/www.forbes.com/sites/richkarlgaard/2017/08/08/how-michael-dell-reinvented-his-company/amp/
• #9: SRE = site reliability engineering
• #11: Along with predictability – standardization and consolidation
• #14: WISELY? = Add and accelerate revenue Lower TCO Futureproof, protect against lock-in and lock-out Standardize and consolidate, lest things get unwieldly and prevent 1-3
• #15: +3 clouds can also run *some* legacy applications
• #16: Article on DevNetOps https://thenewstack.io/end-network-automation-know-feel-fine/
• #18: Personally, I related to hybrid cloud like my credit cards. They give me the elasticity to buy whatever I need on credit margin rather than saving. It can be a lifesaver in an emergency. For a businesses, not buying, but rather investing, elasticity is crucial to business agility to seize a business opportunity.
• #19: On “YES! Security”… Gone are the notions that systems are secure because they are within the Enterprise walls. Public cloud companies have some of the best security talent on the planet. Just like private SecOps, it is dependent on how it’s used.
• #20: While you want to get as close as possible to parity, private and public clouds will not be homogenous in all respects, and actually this diversity, like in biology is a good protection in cases of failure. Eventually a private cloud or public cloud or a part of it may fail, and at that time it is very useful to be able to fail over to another cloud provided that there is capacity – not always possible if private clouds run at 100% capacity, but there are probably more than one public clouds out there suitable.
• #22: Common base: IaaS Build with OpenStack. Unified toolchain: Application and DevOps Stack: Applications : use OSS tools. Reliability: Use Terraform for IaC; Use hardware-independent BYO software-defined tools for networking, security and storage; Performance: use BYO software-defined tools. Policy: the same tools across clouds allow for harmonized policy. SPOG tools allow for unified policy and unified policy as code repositories can help manage it this way too. Management and self-service: incorporate a multi-cloud view like RightScale, CloudForms, StackDriver, Scalr, etc.
• #23: + dependencies, hardware, etc. etc. etc. *categories here are not exact Networking is almost irrelevant in the big picture of cloud. Software is the glue instead of people – focus on the software (the puzzle piece intersections) Focus on the big picture of how cloud and automation scales and improves applications for lines of business, thus adding biz value and agility A lot of pieces of software with the big picture changing fast… cloud is hard… we can help… Technology vendors and integrators as IT partners are important because the big picture is always changing with new innovations
• #24: Collapsible overlays means when the same SDN is stacked on top of itself like Contrail with OpenStack and Contrail again with Kubernetes. Also beware of non-functional requirement lock-in from IaaS or things that may be add functional difficulty in the IaaS model of the cloud vendor: e.g. transit VPCs in AWS
• #25: Collapsible overlays means when the same SDN is stacked on top of itself like Contrail with OpenStack and Contrail again with Kubernetes. Also beware of non-functional requirement lock-in from IaaS or things that may be add functional difficulty in the IaaS model of the cloud vendor: e.g. transit VPCs in AWS
• #27: Sometimes the journey to cloud can be so hasty that the good intentions for business speed, can lead to bad decisions. Summary article and podcast: https://www.linkedin.com/pulse/good-habits-make-multi-cloud-work-you-part-2-james-kelly/
• #30: Original use: http://www.zdnet.com/article/hadoop-creator-google-is-living-a-few-years-in-the-future-and-sending-the-rest-of-us-messages/
• #32: DevOps and CI/CD have gained popular adoption, but Google technology and practices like K8s and SRE are largely making this much easier than, for example, trying to follow in the footsteps of Netflix
• #33: CALMS adds Lean: think lean startup, MVP etc. You build it, you run it Development teams are responsible for operations workflows Infrastructure systems teams follow a development workflow This is not necessary for everyone to learn in depth, but anyone thinking about digital transformation should know “just enough” of this to stay relevant.
• #34: What you probably don’t need to know from a non-developer perspective for customer conversations: - Branching and reviewing techniques and tools - Release techniques like in-place, blue/green, canary - Immutable infrastructure
• #40: 1. Quick and clumsy; 2. Rushing into a bottleneck; 3. The micro-services bullets of an agile chamber
• #41: Small teams that don’t incur the n-squared collaboration overhead to highly like large teams (see Jeff Bezos’s 2-pizza rule) Clean interfaces created with APIs in this case isolate internal changes from the total system integration Innovation and Upgrade Velocity because teams can innovate in parallel and upgrade their component without affecting the whole system Reusable components that specialize in one task (like the Unix philosophy) are often reusable in many bigger solutions and help portability and avoid lock-in Scale out architectures are built on the divide and conquer premise that micro-services being all equally small and thin tasks can be replicated many times across many machines to meet elastic scale requirements instead of feeding a given task more memory and CPU and getting to get bulkier instances Fault tolerance comes from the scale out model whereby a micro-service replicated many times represents a function, and with the failure of any instance, the function as a whole is still up and running + others considerations: Dependency injection and service discovery
• #42: Out of the box and into the cloud Isolation: How can I jeep jobs from interfering with each other? Composition: How can I bundle dependent containers? Scheduling: Where should my job run? Lifecycle: How to keep my jobs running? Discovery: Where is my job now? Constituency: Who is part of my job? Scaling: Making my jobs bigger / smaller AAA (Authentication, Authorization, Access): Who can do what? Monitoring: What’s happening with my job now, previously? Health: How is my job feeling?
• #43: Mesosphere DCOS (Datacenter OS) runs on AWS but will on GPC and Azure soon as well. Kubernetes can be used as a scheduler component for Mesos/Mesosphere as well. Google Container Engine (GKE) is fully based on Kubernetes, but includes a lot more.
• #44: Applying the devops value of automation fully into the lower levels of infrastructure and high availability / reliability / security / performance More to learn here around MTTR and MTBF
• #45: For serverless, the infrastructure is only important if you own it, in which case it will matter a lot for the QoS and SLAs for apps. Instrumentation and DevOps tooling is still very immature in this area compared to micro-services as containers.
• #48: Consistency and correctness implied
• #49: API Archttecture = X aaS = everything is an API and service – generally composed of microservices X as Code = everything is programmable and everything follows sw dev patterns Continuous processes = everything is orchestrated on a pipeline for speed, consistency (quality) and instrumented for real-time continuous response and optimization Continuous integration > delivery > deployment > response Microservice = perfect match for nimble agile process where many step steps are favored
• #52: NRE of course drawing inspiration from SRE: Site reliability engineering