Cloud-Native Fundamentals: An Introduction to 12-Factor Applications
2 likes1,277 views
The document discusses the Twelve-Factor App methodology, which outlines best practices for developing cloud-native applications that are scalable and maintainable. It emphasizes the importance of separating code from configuration, ensuring statelessness, and creating a deployment pipeline to streamline the development process. The content also suggests evaluating legacy applications for compliance with these factors to optimize their performance in cloud environments.
Cloud-Native Fundamentals: An Introduction to 12-Factor Applications
- 5. Container all the things?
- 7. Functions. As a Service.
- 8. Did someone say Polycloud? https://www.thoughtworks.com/radar/techniques/polycloud
- 9. What the heck are the 12 factors? Why 12? Why not 11?
- 10. Is *my* app 12 factor?
- 11. What should I do with my heritage portfolio?
- 12. How do we make sense of all this?!?
- 15. Applications designed to take advantage of cloud computing.
- 16. Fundamentally about how we create and deploy applications.
- 17. Cloud computing gives us some very interesting abilities.
- 18. Scale up. Scale down. On demand.
- 20. * Additional fees may apply.
- 21. Cloud native isn’t just an architectural pattern.
- 22. Combination of practices, techniques, technologies.
- 25. Automation.
- 26. Containers.
- 27. Microservices.
- 28. Functions.
- 30. DevOps.
- 31. Infrastructure is a different game today isn’t it?
- 32. We’ve seen this massive shift.
- 33. Servers used to be home grown.
- 35. Spent days hand crafting them.
- 36. Treated them like pets…
- 38. Did whatever it took to keep them healthy and happy.
- 39. Servers were a heavily constrained resource.
- 40. They were really expensive!
- 41. Had to get our money’s worth…
- 42. Thus was born app servers.
- 43. Put as many apps as possible on a server.
- 44. Maximize the return on investment.
- 45. But that has some unintended side effects.
- 47. One application’s bug could take down multiple apps.
- 49. “Your app can’t get this feature until all other apps are ready.”
- 50. Currency === 18 months of freezes, testing, frustration.
- 51. Organizations ignored currency issues…pain wasn’t “worth it”.
- 52. –Yoda “Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.”
- 53. #YodaOps
- 54. Move code from one server to another…
- 55. Worked in dev…but not test.
- 56. Why?!?
- 57. The environments are the same…right?
- 58. “Patches were applied in a different order…”
- 59. Can I change careers?
- 60. Things started to change.
- 62. Linux and Intel chips replaced custom OS on specialized silicon.
- 64. Prices dropped.
- 65. Servers were no longer the constraining factor.
- 66. People costs eclipsed hardware costs.
- 67. Heroku, AWS, Google App Egine, Cloud Foundry, Azure.
- 68. Shared servers became a liability.
- 69. Treat them like cattle…when they get sick, get a new one.
- 72. Containers and PaaS changed the game.
- 73. Package the app up with everything it needs.
- 74. Move *that* to a different environment.
- 75. Works in dev? You’re testing the exact same thing in test.
- 76. So. Much. Win.
- 77. Your app needs a spiffy new library? Go ahead!
- 78. It doesn’t impact any other app because you are isolated.
- 79. Moves the value line.
- 80. Less “undifferentiated heavy lifting”.
- 83. Run experiments. A/B testing.
- 84. Respond to business changes.
- 85. Deliver in days not months.
- 87. Speed matters.
- 88. Disruption impacts every business.
- 89. Your industry is not immune.
- 90. Amazon Prime customers can order from Whole Foods.
- 91. Some insurance companies view Google as a competitor.
- 92. We’re all technology companies today.
- 93. 12 factors
- 95. Characteristics shared by successful apps.
- 96. At least at Heroku.
- 97. 1. One codebase in version control, multiple deploys. 2. Explicitly define your dependencies. 3. Configuration must be separate from the code. 4. Backing services are just attached resources. 5. Build, release, run.
- 98. 6. Stateless - share nothing. 7. Export services via port binding. 8. Scale via process. 9. Start up fast, shut down gracefully. 10.Dev/Prod parity. 11.Logs as event streams. 12.Admin tasks run as one off processes.
- 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.
- 118. State must be stored via some kind of backing service.
- 119. In other words, you cannot rely on the filesystem or memory.
- 120. Recovery. Scaling.
- 121. VII. Export services via port binding.
- 122. App exports a port, listens for incoming requests.
- 123. localhost for development, load balancer for public facing.
- 124. VIII. Scale via process.
- 125. In other words, scale horizontally.
- 126. IX. Start up fast, shut down gracefully.
- 127. Processes aren’t pets, they are disposable.
- 128. Processes can be started (or stopped) quickly and easily.
- 129. Ideally, start up is seconds.
- 130. Also can handle unexpected terminations!
- 131. X. Dev/Prod parity.
- 132. From commit to production should be hours…maybe days.
- 133. Definitely not weeks.
- 134. Developers should be involved in deploys and prod ops.
- 135. Regions should be identical. Or as close as possible to identical.
- 136. Backing services should be the same in dev and prod.
- 137. Using one DB in dev and another in prod invites pain.
- 138. XI. Logs as event streams.
- 139. Don’t write logs to the filesystem!
- 140. It won’t be there later…
- 141. Write to stdout.
- 142. Stream can be routed any number of places.
- 143. And then consumed via a wide variety of tools.
- 144. XII. Admin tasks run as one off processes.
- 145. Database migrations for instance.
- 146. REPL for the win.
- 147. Run in an identical environment to the long running processes.
- 148. Your legacy apps will violate some factors.
- 149. Maybe all 12!
- 150. In general…
- 151. II. Explicitly define your dependencies.
- 152. Probably one of the harder ones to satisfy.
- 153. Do we really need this library?
- 154. “It works, don’t touch it.”
- 155. III. Configuration must be separate from the code.
- 156. Many an app has hardcoded credentials.
- 158. VI. Stateless - share nothing.
- 159. Also can be challenging.
- 160. Many apps were designed around a specific flow.
- 161. Page 2 left debris for Page 3!
- 162. “Just stash that in session”.
- 163. IX. Start up fast, shut down gracefully.
- 164. Many apps take way too long to start up…
- 166. X. Dev/Prod parity.
- 167. Environments should be consistent!
- 168. Shorten code to prod cycle.
- 169. “It worked in test…”
- 170. Do your applications have to be fully 12 factor compliant?
- 171. Nope.
- 172. Is it a good goal?
- 173. Sure.
- 174. But be pragmatic.
- 175. Certain attributes lessen the advantages of cloud.
- 176. Long startup time hurts elastic scaling & self healing.
- 177. Think of it as a continuum.
- 178. 12 Factor Compliance Benefits of Cloud Deployment
- 179. Developers also talk about 15 factor apps.
- 180. aka Beyond the Twelve-Factor App. https://content.pivotal.io/blog/beyond-the-twelve-factor-app
- 181. However you define it…
- 182. To maximize what the cloud gives us…
- 183. Applications need to be designed properly.
- 184. Legacy applications will fall short.
- 186. Building greenfield?
- 187. Go cloud native!
- 188. Don’t build legacy.
- 189. Plan the journey
- 190. Before you start, figure out where you are.
- 191. You need to assess the applications.
- 192. Some will be great candidates, others…
- 193. We need to understand a few things about our applications.
- 195. What is the tech stack? What version are we on?
- 196. How many users?
- 197. How many transactions per second (estimate)?
- 198. What components do we use?
- 199. What 3rd party things does the application use?
- 200. What are the data integrations?
- 201. What is the data access technology?
- 202. Do we use any internal frameworks?
- 203. Are there any batch jobs?
- 204. Do we have CI/CD? What are we using to build the apps?
- 205. What do we have for test coverage?
- 206. We need to assess the refactoring effort.
- 207. Look for certain red flags.
- 208. Vendor dependencies.
- 209. Writing to the file system.
- 210. Reading from the file system.
- 211. Long startup times.
- 212. Long shut down times.
- 213. Non-HTTP protocols.
- 215. Container based shared state.
- 217. Evaluate your applications for 12 Factors compatibility.
- 218. Again, it is a sliding scale.
- 219. How far out of alignment is the app?
- 220. This effort requires application expertise.
- 221. And it will take time.
- 222. At least a few hours per.
- 223. Consider building a little application for all the data.
- 224. Excel is not an application platform. Cough.
- 225. Unless you have a small portfolio…
- 226. Assessments will bucket your applications.
- 227. Low/Medium/High.
- 228. Or red/yellow/green.
- 229. Whatever works!
- 231. Sanity check it.
- 232. What is the business value of the application?
- 233. Consider the life cycle of the application.
- 234. Is it strategic?
- 235. Is it something we’re going to invest in?
- 236. Or is it going to be retired soon?
- 237. Retirement isn’t a hard no though.
- 238. *When* matters. A lot.
- 239. “When I started, this app was marked sunset…”
- 240. That was 25 years ago. Still running.
- 241. If it is going away in a few months…not worth it.
- 242. Going to be around for a few years, probably is.
- 243. Now we need to do some planning.
- 244. What is your desired end state?
- 245. Cloud native? Just get it running on cloud?
- 246. Legacy apps will require refactoring.
- 247. How long does it take to forklift an application? https://blog.pivotal.io/pivotal-cloud-foundry/features/the-forklifted-application
- 249. Strongly recommend a pilot app or two.
- 250. Get a feel for it.
- 251. Usually a few weeks or so.
- 253. Consider staffing up a “lab” team with expertise.
- 254. Help teams migrate.
- 255. Should *pair* with the application area.
- 256. Need to grow the skills.
- 257. Create a roadmap.
- 258. When can the applications move?
- 259. It doesn’t have to be the entire application!
- 260. Some deployable units will be easy, others hard.
- 261. Move what you can.
- 262. Again, the terminology can be challenging…
- 263. Look to opportunistically migrate what you can.
- 264. But have a rough idea of when.
- 265. Does that satisfy your stakeholders?
- 266. What can you do to accelerate the plan?
- 267. Good luck!
- 268. Nathaniel T. Schutta @ntschutta ntschutta.io Thanks! I’m a Software Architect, Now What? with Nate Shutta Modeling for Software Architects with Nate Shutta Presentation Patterns with Neal Ford & Nate Schutta