Downloaded 253 times
Uploaded byVMware Tanzu
The Cloud Native Journey
The document outlines the cloud-native journey emphasizing that delivering software is now essential for survival rather than a differentiator. It discusses the importance of continuous delivery and microservices architecture, highlighting the creation of reliable systems from unreliable components. Additionally, it critiques traditional approaches to platform development, advocating for simplicity and effective organizational structures to support modern software delivery.
More Related Content
![[CTO Night & Day 2019] グローバルのサービス展開に向けたマルチリージョンアーキテクチャ- #ctonight](https://cdn.slidesharecdn.com/ss_thumbnails/ctond2019morningsessionglobalarchitecture-191027185900-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to The Cloud Native Journey
The Cloud Native Journey
- 1. © Copyright 2015Pivotal. All rights reserved. 1 The Cloud Native Journey Matt Stine (@mstine) Consultant Engineer & Senior Product Manager
- 2. © Copyright 2015Pivotal. All rights reserved. 2 WARNING: This may end up being a bit stream of consciousness…
- 3. © Copyright 2015Pivotal. All rights reserved. My Cloud Native Journey 3 App Dev/Arch for 11 years CLOUD NATIVE LAND
- 4. © Copyright 2015Pivotal. All rights reserved. 4 I wrote a little cloud book… Available to you compliments of Pivotal! Get the FREE e-book at http://bit.ly/cloud-native-book!
- 5. © Copyright 2015Pivotal. All rights reserved. 5 “Software is Eating the World”
- 6. © Copyright 2015Pivotal. All rights reserved. 6 Gartner predicts that by 2020, 75 percent of application purchases supporting digital business will be "build," not "buy." http://www.gartner.com/newsroom/id/3119717
- 7. © Copyright 2015Pivotal. All rights reserved. 7 The ability to deliver software is no longer a differentiator.
- 8. © Copyright 2015Pivotal. All rights reserved. 8 It is a basic requirement for survival.
- 9. © Copyright 2015Pivotal. All rights reserved. 9 So what do the Cloud Natives do? $6B $50B $41B $25B $33.5B
- 10. © Copyright 2015Pivotal. All rights reserved. 10 SPEED UBIQUITY* SCALE SAFETY (MOBILE)
- 11. © Copyright 2015Pivotal. All rights reserved. 11 Continuous Delivery
- 12. © Copyright 2015Pivotal. All rights reserved. 12 Delivery Continuous
- 13. © Copyright 2015Pivotal. All rights reserved. 13 Day One Day Two and Beyond Deliver Continuously
- 14. © Copyright 2015Pivotal. All rights reserved. 14 Operations is the Secret Sauce
- 15. © Copyright 2015Pivotal. All rights reserved. Continuously Delivered Microservices 15 Loosely coupled service oriented architecture with bounded contexts If every service has to be updated in concert, it’s not loosely coupled! If you have to know about surrounding services you don’t have a bounded context.
- 16. © Copyright 2015Pivotal. All rights reserved. Without taking steps to ensure fault tolerance, 30 dependencies each with 99.99% uptime would result in 2+ hours downtime/month (99.99%30 = 99.7% uptime = 2+ hours downtime in a month). http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html
- 17. © Copyright 2015Pivotal. All rights reserved. 17 Build Reliable Systems from Unreliable Components
- 18. © Copyright 2015Pivotal. All rights reserved. 18
- 19. © Copyright 2015Pivotal. All rights reserved. 19
- 20. © Copyright 2015Pivotal. All rights reserved. Microservices The Old Way 20
- 21. © Copyright 2015Pivotal. All rights reserved. 21 Cloud Native is NOT: Configuring Infrastructure Orchestrating Containers Composing Distributed Systems Supporting Ad-Hoc General Purpose Automation
- 22. © Copyright 2015Pivotal. All rights reserved. 22 https://twitter.com/littleidea/status/626767188653797376
- 23. © Copyright 2015Pivotal. All rights reserved. 23 GREAT JOB PROVISIONING SERVERS THIS YEAR! …said no CIO ever.
- 24. © Copyright 2015Pivotal. All rights reserved. 24 And they’re not going to say that about containers either…
- 25. © Copyright 2015Pivotal. All rights reserved. 25
- 26. © Copyright 2015Pivotal. All rights reserved. 26
- 27. © Copyright 2015Pivotal. All rights reserved. 27 I’ve built homegrown application platforms twice: The first took three years before it saw a production application. The second took two years. Maybe if I do it just two more times…
- 28. © Copyright 2015Pivotal. All rights reserved. 28 I regret to inform you, but… You’re not that smart. You’re not different. You’re not special.
- 29. © Copyright 2015Pivotal. All rights reserved. 29 the ratio of app developers to platform developers at “web scale” companies
- 30. © Copyright 2015Pivotal. All rights reserved. 30 this was also true of the two platforms I helped build
- 31. © Copyright 2015Pivotal. All rights reserved. 31 UNDIFFERENTIATED HEAVY LIFTING
- 32. © Copyright 2015Pivotal. All rights reserved. 32
- 33. © Copyright 2015Pivotal. All rights reserved. 33 SIMPLE RULES COMPLEX BEHAVIOR EXPLICIT CONTRACTS COMMODITY COMPONENTS
- 34. © Copyright 2015Pivotal. All rights reserved. 34
- 35. © Copyright 2015Pivotal. All rights reserved. 35 SIMPLE RULES COMPLEX BEHAVIOR EXPLICIT CONTRACTS COMMODITY COMPONENTS Grab Dirt w/ Pheromone Build Bridge Attach to Ant on Edge 1000’s of Ants Hardwired into Brain Colonies, Bridges, Rafts
- 36. © Copyright 2015Pivotal. All rights reserved. 36 What if our platform worked this way?
- 37. © Copyright 2015Pivotal. All rights reserved. 37 3-5 Different Server Builds If your software doesn’t fit into one of these, your software is broken. Zero Deviation or Customization
- 38. © Copyright 2015Pivotal. All rights reserved. 38 PLATFORM IS OMAKASE
- 39. © Copyright 2015Pivotal. All rights reserved. SPRING BOOT 39 OMAKASE TWELVE FACTOR APPS http://start.spring.io
- 40. © Copyright 2015Pivotal. All rights reserved. SPRING CLOUD 40 http://cloud.spring.io https://network.pivotal.io/products/p-spring-cloud-services OMAKASE DISTRIBUTED SYSTEMS
- 41. © Copyright 2015Pivotal. All rights reserved. SPRING CLOUD DATA FLOW 41 OMAKASE BATCH AND STREAM DATA PROCESSING http://cloud.spring.io/spring-cloud-dataflow
- 42. © Copyright 2015Pivotal. All rights reserved. 42 http://spring.io/platform
- 43. © Copyright 2015Pivotal. All rights reserved. 43 PIVOTAL CLOUD FOUNDRY - OMAKASE RUNTIME PLATFORM
- 44. © Copyright 2015Pivotal. All rights reserved. OMAKASE APPLICATION METRICS
- 45. © Copyright 2015Pivotal. All rights reserved. OMAKASE CI/CD PIPELINES
- 46. © Copyright 2015Pivotal. All rights reserved. 46 If your software doesn’t fit into this platform, then your software is probably broken.
- 47. © Copyright 2015Pivotal. All rights reserved. 47 Polyglot Programming?
- 48. © Copyright 2015Pivotal. All rights reserved. 48 SIMPLE RULES COMPLEX BEHAVIOR EXPLICIT CONTRACTS COMMODITY COMPONENTS
- 49. © Copyright 2015Pivotal. All rights reserved. 49 Simple Rules Boot Property Resolution Boot Config Precedence Circuit Breaker FSM Eureka Cache Server Resolution Buildpack Detect/Compile/Upload Java BP Memory Heuristic LRP/Task Lifecycle Desired/Actual State Convergence STDOUT/ERR Log Aggregation Routing Table Maintenance
- 50. © Copyright 2015Pivotal. All rights reserved. 50 CONTRACTS
- 51. © Copyright 2015Pivotal. All rights reserved. Commodity Components? 51 THOUSANDS OF MICROSERVICES!
- 52. © Copyright 2015Pivotal. All rights reserved. 52 So what does a platform like this allow you to do?
- 53. © Copyright 2015Pivotal. All rights reserved. #1: Get your head around Conway’s Law. 53 Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. Melvyn Conway, 1967
- 54. © Copyright 2015Pivotal. All rights reserved. 54 #2: Invoke the Inverse Conway Maneuver
- 55. © Copyright 2015Pivotal. All rights reserved. #3: Start Delivering Business Capabilities 55 Product Mgr UX Dev QA DBA Sys Admin Net Admin Storage Admin BUSINESS CAPABILITY TEAMS BUILDING MICROSERVICES PLATFORM OPERATIONS TEAM Adapted from: http://www.slideshare.net/adriancockcroft/goto-berlin Self Service API
- 56. © Copyright 2015Pivotal. All rights reserved. 56 But what if I don’t have a platform like this? Probably going to make some things too complicated/hard… Probably going to need specialization at multiple levels of your architecture… Probably going to stay stuck in or rebuild your silos…
- 57. © Copyright 2015Pivotal. All rights reserved. 57 We need the platform to remind us: We’re not that smart. We’re not different. We’re not special.
- 58. © Copyright 2015Pivotal. All rights reserved. So we can get back to why we’re here… 58
- 59. © Copyright 2015Pivotal. All rights reserved. 59 Game On http://pivotal.io/cloud-native
Editor's Notes
- #2 Well good morning. Welcome to the Cloud Native Journey. I’m Matt Stine, and among other things I run product management for Spring Cloud on Cloud Foundry at Pivotal.
- #3 Just a warning up front - this may be a bit stream of consciousness. If you’ve read James Joyce’s A Portrait of the Artist as a Young Man, you know what I mean. If you haven’t, don’t worry. I promise it won’t hurt too badly.
- #4 Start by telling you about my cloud native journey. I spent my first 11 years as an application developer and later architect. Eventually I figured out it wasn’t just about cutting code, but the ability to deliver things and keep them running, and I got interested in DevOps. I had the benefit of not growing up around a strong operational discipline, so it forced me to feel the pain. Hired by VMware, presumably to do app dev consulting. Someone heard I could speak Puppet, and I ended up building a platform for 15 months. I then joined Cloud Foundry and spent 18 months helping customers succeed with our platform. Along the way I got sucked up into the microservices tornado. I’ve spent the last 8 months as part of the Spring team helping align both Spring and Cloud Foundry around the journey to Cloud Native Land.
- #5 Which incidentally I wrote a little book on, and we’re going to sign and give those away here in the Hang Space at 10 o’clock.
- #6 We started this journey a few years ago, when Marc Andreessen made the movement defining statement that “Software is Eating the World.” Well, that was a few years ago. It has now become absolutely clear that software has in fact eaten the world.
- #7 Gartner recently announced some very telling observations, including that 45% of surveyed IT organizations have prioritized app modernization, and predicting that by 2020, 75 percent of application purchases supporting digital business will be "build," not "buy."
- #8 What does this tell us but that the ability to deliver software is no longer a differentiator.
- #9 In fact, it is a basic requirement for survival. Companies that embrace cloud-native patterns of software delivery will survive; companies that don’t will not. The battle will be fought amongst the cloud-native companies, and their differentiators will be in the digital experiences they are able to create for their users.
- #10 So, if that’s true, what is it that the cloud natives do?
- #11 Well, in my quest to understand these companies and how they operate, I’ve identified four key patterns. Speed, safety, scale, and what I’m now calling “ubiquity.” I used to call this mobile, but what I’m really trying to highlight is the idea that anybody, anywhere, can at anytime interact with your services. Speed is obvious - we can innovate, experiment, deliver value quickly. Safety balances speed with the simultaneous ability to maintain stability, availability, and durability. And scale refers to our ability to elastically respond to changes in demand.
- #12 The cloud natives practice continuous delivery. Well what does that mean? It may help to invert the phrase.
- #13 Delivery Continuous. Or perhaps better.
- #14 Deliver Continuously. You see, it’s not enough to deploy something. That’s just Day One. You also have to deploy again, and again, and again. And when you do that, you can’t break stuff. That’s day two…and beyond.
- #15 So operational discipline is key to cloud native. If it cost you anything to run something, on some time scale the operational cost dwarfs the creation cost, and if the operation cost is high, that day comes quick. If the fixed cost of deployment is high, then you end up spending all of your money, and you can’t develop anything anymore.
- #16 So what are we continuously delivering? MICROSERVICES. What are microservices? Well here’s Adrian Cockcroft’s definition. SOA. Loosely coupled - I can deploy my service any time I want. Bounded context - I don’t know anything about surrounding services other than their API’s - not their internals.
- #17 Of course the problem with microservices is that you end up building these huge distributed systems. And if you’ve spent any time with those, you know that the probability of any part of the system failing increases exponentially with the number of nodes. So we end up with this tension between microservices enabling us to deliver faster and scale independently, but making it more likely that something will fail.
- #18 And so we have to figure out how we can build reliable systems from unreliable components.
- #20 And maybe we’ve tried this sort of thing before! Maybe you’ve tried to take some legacy apps and shove them into a container and forklift them into the cloud. It’s an incredibly hard problem to solve, mostly because of implicit, poorly understood, and complex contracts. We’ll talk more about contracts a bit later.
- #21 What should be painfully obvious is that we cannot try to build and run microservices the same way we built and ran our legacy applications. That will kill you. So what do we do? Well, I’d like to start with what you should not do.
- #22 Cloud Native does not mean build a massive DevOps team and tell them to go configure all of the infrastructure, orchestrate all of the containers, compose the distributed systems, and generally support any kind of ad-hoc, general purpose automation you might dream up like configuring load balancers or creating NFS mounts.
- #23 I think my partner in crime Andrew Clay Shafer said it best - “ad hoc automation is a problem masquerading as a solution.”
- #24 GREAT JOB PROVISIONING SERVERS THIS YEAR! Wait for it! …said no CIO ever.
- #25 And I know we’re really excited about containers now, but the CIO isn’t going to congratulate you for orchestrating containers either.
- #26 OK, so maybe ad-hoc automation is not the right path. Perhaps we’ll build our own platform then. Other smart people have obviously already built these, but those are web unicorns. We’re the Enterprise.
- #27 And we need an ENTERPRISE CLOUD. We’re different from the web unicorns. We have special needs. And we know best how to translate the operational characteristics of the cloud into our world. (Nevermind that we’ve never built anything like this before.) Our cloud will let us customize everything to meet the unique needs of of our applications.
- #28 Now I’ve gone down this road twice actually. The first platform I built was domain-specific. Its job was to support building and running laboratory management systems. Everyone knew it was going to be awesome. Unfortunately it took three years before it ever saw a production app. The second was a fairly opinionated general purpose platform stitched together from “best of breed” components. It took two years before it saw a production app. So at this rate, maybe if I do it two more times I’ll get to where I want to go.
- #29 I regret to inform you, but you’re not that smart, different, or special. And I’m talking to myself here as well. When I built that first platform, I thought I had special knowledge. But in hindsight, as it turns out, my needs were not significantly different from the web companies in any way. And where they were, they weren’t going to be met by the platform anyway.
- #30 What’s cool about Pivotal is the our breadth of real world experience. You get to talk to people all of the time that built amazing things. And so I asked folks like Ben Black, who was part of the birth of AWS, and Adrian Cole, who spent time at Netflix, Square, and Twitter — “what’s the ratio of developers working on real business facing apps vs. platform?” Across the board, the answers are within some small delta of 10:1.
- #31 Interestingly enough, as I reflect back on the two platforms I built, the ratio was much the same. The real question becomes - where do you want your best engineers spending their time? Solving the problems of delivery? Or delivering great software?
- #32 Ultimately, the degree to which you expend human capital on building delivery mechanisms is a prime indicator of your likelihood of failure. So we’re going to spend the rest of our time talking about an opinionated platform, which in my mind is the only way you can achieve this level of effectiveness, because it destroys the need <TRANSITION> to perform such undifferentiated heavy lifting and simultaneously provides you with the capabilities you need to continuously deliver digital experiences at scale and speed. Don't waste time figuring out structure for your platform - use all of your brain power on differentiation. Because that’s what your competition will be doing.
- #33 So I want to switch tracks a bit and explore what at first glance probably looks like a weird topic for a talk like this. I’ve spent some time over the last year playing around with classes offered by the Complexity Explorer at the Santa Fe Institute. Why? Because complex systems is what we do.
- #34 And during those studies and relating them back to what I’m working on, I’ve discovered this path. That if you built systems based on simple rules, with commodity components, and have explicit contracts between those components, you can build pretty complex behavior without some massive centralized brain that’s running the whole thing.
- #35 One of the first things that you look at in the Complexity Explorer’s classes is the behavior of ants. Ants are able to do pretty amazing things, from the construction of complex intricate structures in their colonies, to building bridges out of their own bodies, to building rafts from their bodies that form a Gore-Tex like structure that repels water and is incredibly difficult to sink.
- #36 Walk through the simple rules. What’s amazing is that we have deduced these rules, modeled them in simulation, and managed to reproduce the same structures in those simulations.
- #37 So…what if our platform worked this way? Some do.
- #38 Amazon started with very simple rules. These from the era of actually provisioning physical hardware, with the agreement that said hardware would be available FIVE MINUTES after the ticket was filed. In order to do this, Amazon had anywhere from 3-5 different server builds — t-shirt sizes if you will — and you were allowed zero deviation or customization from those. And if your software didn’t fit, your software was considered broken.
- #39 Another way to say this is that “PLATFORM IS OMAKASE.” It should be a meal consisting of dishes selected by the chef.
- #40 I’m going to start at the top of the Pivotal stack and work my way through all of it’s different interesting layers, starting with Boot. <RIFF ON BOOT>
- #41 <RIFF ON SPRING CLOUD> About opinionated expression of distributed systems patterns. Drawing from existing implementations.
- #42 <RIFF ON SPRING CLOUD DATA FLOW> Does the same thing for the unique management needs of batch and stream data processing workloads. Foundation for message-driven microservices. Opinionated wiring of components and message buses.
- #43 All of these Spring components of course fit together into a platform built on a foundation of battle-tested components for web, data, integration, and batch workloads, built on the mature and trusted core of the Spring Framework.
- #44 And then there is the platform runtime itself, which brings its own strong opinions from the infrastructure layer up, including how best to orchestrate IaaS clouds to deploy, update, and manage the health of the platform itself, all the way up to elastically managing the lifecycle of your applications and their backing services. Along the way, we’ve created a hand-in-glove relationship between the Spring App Framework Platform and the CF Elastic Runtime Platform.
- #48 But what about polyglot programming? Isn’t one of the promises of microservices that everyone can write their services in whatever languages they choose? Sure. But polyglot is a RED HERRING <TS>. Polyglot is not what makes you productive. Polyglot actually makes it harder to enforce the simple rules and explicit contracts that make the platform so powerful. Is it impossible? No. But there’s definitely a cost to providing the same omakase experience to every taste in programming language.
- #49 So let’s look at the four things again and find them in this platform.
- #51 12 Factor BOSH Release BOSH CPI
- #52 So what are our commodity components? Wait for it…. 1000’s of MICROSERVICES
- #54 With your platform needs met, you can start to deal with the organizational challenges that you have. Conway said you can’t help but reproduce in your architecture the structure of your organization. So now you’ve freed up brainpower to think about where you are and where you need to go.
- #55 You then have the ability to invoke the “Inverse Conway Maneuver,” taking steps like Netflix did. Once you decide the architecture that your system needs to have, you can restructure your organization to look like that architecture, and according to Conway, that architecture will emerge.
- #56 And then you can get about the business of delivering the business capabilities that will differentiate you from your competitors. <RIFF ON THIS SLIDE A BIT>
- #57 What if you don’t have a platform like this? Read the bullets basically.
- #58 We need the platform to remind us of the facts that we discussed earlier. We’re not that smart. We’re not different. We’re not special. The platform constrains us to keep thinking about delivering software.
- #59 And so we’re able to get back to the business of delivering the thing that actually makes our customers awesome, which in turn is what empowers us to win.
- #60 So game on. Thank you.