Evolving to Cloud-Native - Nate Schutta 1/2
3 likes307 views
The document discusses evolving applications to be cloud native by taking advantage of cloud computing abilities like scaling up and down on demand. It describes that cloud native applications are defined by practices like continuous delivery, containers, microservices, and functions. It also discusses how infrastructure has shifted from custom servers to commodity servers and cloud providers, and how applications need to be designed to leverage this shift through principles like loose coupling, statelessness, and deploying configurations separately from code.
Evolving to Cloud-Native - Nate Schutta 1/2
- 6. Container all the things?
- 8. Functions. As a Service.
- 9. Did someone say Polycloud? https://www.thoughtworks.com/radar/techniques/polycloud
- 10. How do we make sense of all this?!?
- 11. There are real engineering issues to overcome.
- 12. Many believe in magic sparkle ponies...
- 13. How do we avoid pitfalls?
- 14. And a strong case of resume driven design?
- 16. Applications designed to take advantage of cloud computing.
- 17. Fundamentally about how we create and deploy applications.
- 18. Cloud computing gives us some very interesting abilities.
- 19. Scale up. Scale down. On demand.
- 21. * Additional fees may apply.
- 22. Cloud native isn’t just an architectural pattern.
- 23. Combination of practices, techniques, technologies.
- 26. Automation.
- 27. Containers.
- 28. Microservices.
- 29. Functions.
- 31. DevOps.
- 32. Infrastructure is a different game today isn’t it?
- 33. We’ve seen this massive shift.
- 34. Servers used to be home grown.
- 36. Spent days hand crafting them.
- 37. Treated them like pets…
- 39. Did whatever it took to keep them healthy and happy.
- 40. Servers were a heavily constrained resource.
- 41. They were really expensive!
- 42. Had to get our money’s worth…
- 43. Thus was born app servers.
- 44. Put as many apps as possible on a server.
- 45. Maximize the return on investment.
- 46. But that has some unintended side effects.
- 48. One application’s bug could take down multiple apps.
- 50. “Your app can’t get this feature until all other apps are ready.”
- 51. Currency === 18 months of freezes, testing, frustration.
- 52. Organizations ignored currency issues…pain wasn’t “worth it”.
- 53. –Yoda “Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.”
- 54. #YodaOps
- 55. Move code from one server to another…
- 56. Worked in dev…but not test.
- 57. Why?!?
- 58. The environments are the same…right?
- 59. “Patches were applied in a different order…”
- 60. Can I change careers?
- 61. Things started to change.
- 63. Linux and Intel chips replaced custom OS on specialized silicon.
- 65. Prices dropped.
- 66. Servers were no longer the constraining factor.
- 67. People costs eclipsed hardware costs.
- 68. Heroku, AWS, Google App Egine, Cloud Foundry, Azure.
- 69. Shared servers became a liability.
- 70. Treat them like cattle…when they get sick, get a new one.
- 73. Containers and PaaS changed the game.
- 74. Package the app up with everything it needs.
- 75. Move *that* to a different environment.
- 76. Works in dev? You’re testing the exact same thing in test.
- 77. So. Much. Win.
- 78. Your app needs a spiffy new library? Go ahead!
- 79. It doesn’t impact any other app because you are isolated.
- 80. Moves the value line.
- 81. Less “undifferentiated heavy lifting”.
- 85. Run experiments. A/B testing.
- 86. Respond to business changes.
- 87. Deliver in days not months.
- 89. Speed matters.
- 90. Disruption impacts every business.
- 91. Your industry is not immune.
- 92. Amazon Prime customers can order from Whole Foods.
- 93. Some insurance companies view Google as a competitor.
- 94. We’re all technology companies today.
- 95. 12 factors
- 97. Characteristics shared by successful apps.
- 98. At least at Heroku.
- 99. I. One codebase in version control, multiple deploys.
- 100. Version control isn’t controversial. Right?!?
- 101. Sharing code? It better be in a library then…
- 102. II. Explicitly define your dependencies.
- 103. Do not rely on something just “being there” on the server.
- 104. If you need it, declare it.
- 105. III. Configuration must be separate from the code.
- 106. The things that vary from environment to environment.
- 107. Could you open source that app right now?
- 108. IV. Backing services are just attached resources.
- 109. Should be trivial to swap out a local database for a test db.
- 110. In other words, loose coupling.
- 111. V. Build, release, run.
- 114. Deploy the executable with the proper configuration…
- 115. Launch the executable in a given environment.
- 116. VI. Stateless - share nothing.
- 117. State must be stored via some kind of backing service.
- 118. In other words, you cannot rely on the filesystem or memory.
- 119. Recovery. Scaling.
- 120. VII. Export services via port binding.
- 121. App exports a port, listens for incoming requests.
- 122. localhost for development, load balancer for public facing.
- 123. VIII. Scale via process.
- 124. In other words, scale horizontally.
- 125. IX. Start up fast, shut down gracefully.
- 126. Processes aren’t pets, they are disposable.
- 127. Processes can be started (or stopped) quickly and easily.
- 128. Ideally, start up is seconds.
- 129. Also can handle unexpected terminations!
- 130. X. Dev/Prod parity.
- 131. From commit to production should be hours…maybe days.
- 132. Definitely not weeks.
- 133. Developers should be involved in deploys and prod ops.
- 134. Regions should be identical. Or as close as possible to identical.
- 135. Backing services should be the same in dev and prod.
- 136. Using one DB in dev and another in prod invites pain.
- 137. XI. Logs as event streams.
- 138. Don’t write logs to the filesystem!
- 139. It won’t be there later…
- 140. Write to stdout.
- 141. Stream can be routed any number of places.
- 142. And then consumed via a wide variety of tools.
- 143. XII. Admin tasks run as one off processes.
- 144. Database migrations for instance.
- 145. REPL for the win.
- 146. Run in an identical environment to the long running processes.
- 147. Your legacy apps will violate some factors.
- 148. Maybe all 12!
- 149. In general…
- 150. II. Explicitly define your dependencies.
- 151. Probably one of the harder ones to satisfy.
- 152. Do we really need this library?
- 153. “It works, don’t touch it.”
- 154. III. Configuration must be separate from the code.
- 155. Many an app has hardcoded credentials.
- 157. VI. Stateless - share nothing.
- 158. Also can be challenging.
- 159. Many apps were designed around a specific flow.
- 160. Page 2 left debris for Page 3!
- 161. “Just stash that in session”.
- 162. IX. Start up fast, shut down gracefully.
- 163. Many apps take way too long to start up…
- 165. X. Dev/Prod parity.
- 166. Environments should be consistent!
- 167. Shorten code to prod cycle.
- 168. “It worked in test…”
- 169. Do your applications have to be fully 12 factor compliant?
- 170. Nope.
- 171. Is it a good goal?
- 172. Sure.
- 173. But be pragmatic.
- 174. Certain attributes lessen the advantages of cloud.
- 175. Long startup time hurts elastic scaling & self healing.
- 176. Think of it as a continuum.
- 177. 12 Factor Compliance Benefits of Cloud Deployment
- 178. Developers also talk about 15 factor apps.
- 179. aka Beyond the Twelve-Factor App. https://content.pivotal.io/blog/beyond-the-twelve-factor-app
- 180. However you define it…
- 181. To maximize what the cloud gives us…
- 182. Applications need to be designed properly.
- 183. Legacy applications will fall short.
- 185. Building greenfield?
- 186. Go cloud native!