Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud-Native Fundamentals: An Introduction to 12-Factor Applications

526 views

Published on

It seems like a new cloud-native technology or project is launched every week, and though there are technical changes required for building and operating cloud-native applications, technology alone isn’t a silver bullet. It turns out that how you build your applications is critical to enable seamless scaling and resiliency to failures. What do you have to do to ensure your applications can fully leverage the power and flexibility the cloud offers?

The 12-Factor principles have been around for a decade and have proven themselves as core, foundational principles for cloud-native applications. But they require changes to how you design your applications, the way teams collaborate on code, and more. Understanding the 12-Factor principles is a strong foundation for adopting cloud-native patterns and practices.

Join Pivotal's Nate Schutta, developer advocate, to learn:

● Which of the 12 Factors are most critical to building scalable applications
● Which of the 12 Factors are most likely violated by your heritage applications
● What you can do to make your existing applications more 12-Factor compliant
● Which of the 12 Factors are most critical to applications moving to the cloud
● How to externalize state and configuration in order to simplify scaling and code changes

Presenter :Nate Schutta, Software Architect

Published in: Technology
  • Be the first to comment

Cloud-Native Fundamentals: An Introduction to 12-Factor Applications

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

×