Evolving to Cloud-Native - Nate Schutta (2/2)
•
1 like•248 views
The document discusses moving from monolithic applications to microservices and serverless architectures. It outlines the benefits of these approaches, such as improved developer productivity, scalability, and operational efficiencies. It also notes some challenges, such as increased complexity. The document provides guidance on planning the transition, including assessing applications, creating a roadmap, and piloting changes on select applications before full migration.
Report
Share
Evolving to Cloud-Native - Nate Schutta (2/2)
- 4. Reaction to monoliths and heavy weight services.
- 5. As well as cloud environments.
- 7. Developer productivity takes a hit.
- 8. Hard to get your head wrapped around a huge code base.
- 9. Long ramp up times for new developers.
- 10. Small change results in building and deploying everything.
- 11. Scaling means scaling the entire application!
- 12. Not just the part that needs more capacity.
- 13. Hard to evolve.
- 14. We’re all familiar with the second law of thermodynamics…
- 15. Otherwise known as a teenagers bedroom.
- 16. The universe really wants to be disordered.
- 17. Software is not immune from these forces!
- 18. Modularity tends to break down over time.
- 19. Over time, takes longer to add new functionality.
- 20. Frustration has given birth to a “new” architectural style.
- 23. In the eye of the beholder…
- 25. Anything that can be rewritten two weeks or less.
- 27. Think in terms of characteristics.
- 28. Suite of small, focussed services.
- 29. Do one thing, do it well.
- 30. Linux like - pipe simple things together to get complex results.
- 33. Evolve at different rates.
- 34. Freedom to choose the right tech for the job.
- 35. Built around business capabilities.
- 36. High cohesion, low coupling…
- 38. It is just another approach. An architectural style. A pattern.
- 40. Despite what some developers may have said.
- 42. Use them wisely.
- 44. –Simon Brown “If you can't build a monolith, what makes you think microservices are the answer?” http://www.codingthearchitecture.com/2014/07/06/ distributed_big_balls_of_mud.html
- 45. Sometimes the right answer is a modular monolith… https://www.youtube.com/watch?v=kbKxmEeuvc4
- 46. Serverless
- 47. From IaaS to CaaS to PaaS…
- 49. Functions.
- 50. As a Service.
- 51. I hear that is *the* in thing now.
- 52. But we just refactored to cloud native microservices…
- 53. !
- 54. ( °□°)
- 55. Don’t throw that code away just yet!
- 56. Fair to say FaaS is a subset of serverless.
- 57. Though many use the terms interchangeably.
- 58. First things first. There are still servers.
- 59. We are just (further) abstracted away from them.
- 60. We don’t have to spend time provisioning, updating, scaling…
- 61. In other words it is someone else’s problem.
- 64. IaaS Containers Container Container Scheduling Primitives for Networking, Routing, Logs and Metrics Platform Application Container Images L7 Network Logs, Metrics, Monitoring Services Marketplace Team, Quotas & Usage Container Serverless Function Function Execution Function Scaling Event Stream Bindings Container Developer Provided Tool Provided
- 65. Different levels of abstraction.
- 66. Hardware IaaS Containers Platforms Serverless More Flexibility Fewer Standards Lower Complexity Operational Efficiency Push as many workloads up the stack as feasible.
- 67. Veritable plethora of options.
- 68. AWS Lambda, Azure Functions, Google Cloud Functions…
- 69. riff, OpenWhisk, Kubeless, Knative…
- 70. Definitely suffers from the shiny new thing curse.
- 72. And everything that entails.
- 74. There *are* very good reasons to utilize this approach!
- 75. But it isn’t just a new a way to cloud.
- 76. There are serious efficiency gains to be had with this approach!
- 78. Functions push us further up the abstraction curve.
- 79. Allows us to focus on implementation not infrastructure.
- 80. Do you know what OS your application is running on?
- 81. Do you care?
- 82. What *should* you care about?
- 83. Where is the “value line” for you?
- 84. We want to get out of the business of “undifferentiated heavy lifting”.
- 85. Focus on business problems, not plumbing problems.
- 87. Function hasn’t been called recently?
- 89. Request comes in? Instance springs into existence.
- 90. First million (or two) requests are free*.
- 91. * Additional fees may apply.
- 92. For example: data transfer fees or other services you leverage.
- 93. Functions aren’t free however.
- 94. A fractional cost per request.
- 95. Charged based on # of requests, run duration & resource allocation.
- 96. Can be challenging to determine just how much it will cost…
- 97. But for certain workloads, it is very cost effective.
- 99. Serverless ops?
- 100. Again, less for us to worry about.
- 101. Rely on a platform.
- 102. Very valuable tool.
- 103. It isn’t a good fit for every workload.
- 105. But you knew that.
- 106. Plan the journey
- 107. Before you start, figure out where you are.
- 108. You need to assess the applications.
- 109. Some will be great candidates, others…
- 110. We need to understand a few things about our applications.
- 112. What is the tech stack? What version are we on?
- 113. How many users?
- 114. How many transactions per second (estimate)?
- 115. What components do we use?
- 116. What 3rd party things does the application use?
- 117. What are the data integrations?
- 118. What is the data access technology?
- 119. Do we use any internal frameworks?
- 120. Are there any batch jobs?
- 121. Do we have CI/CD? What are we using to build the apps?
- 122. What do we have for test coverage?
- 123. We need to assess the refactoring effort.
- 124. Look for certain red flags.
- 125. Vendor dependencies.
- 126. Writing to the file system.
- 127. Reading from the file system.
- 128. Long startup times.
- 129. Long shut down times.
- 130. Non-HTTP protocols.
- 132. Container based shared state.
- 134. Evaluate your applications for 12 Factors compatibility.
- 135. Again, it is a sliding scale.
- 136. How far out of alignment is the app?
- 137. This effort requires application expertise.
- 138. And it will take time.
- 139. At least a few hours per.
- 140. Consider building a little application for all the data.
- 141. Excel is not an application platform. Cough.
- 142. Unless you have a small portfolio…
- 143. Assessments will bucket your applications.
- 144. Low/Medium/High.
- 145. Or red/yellow/green.
- 146. Whatever works!
- 148. Sanity check it.
- 149. What is the business value of the application?
- 150. Consider the life cycle of the application.
- 151. Is it strategic?
- 152. Is it something we’re going to invest in?
- 153. Or is it going to be retired soon?
- 154. Retirement isn’t a hard no though.
- 155. *When* matters. A lot.
- 156. “When I started, this app was marked sunset…”
- 157. That was 25 years ago. Still running.
- 158. If it is going away in a few months…not worth it.
- 159. Going to be around for a few years, probably is.
- 160. Now we need to do some planning.
- 161. What is your desired end state?
- 162. Cloud native? Just get it running on cloud?
- 163. Legacy apps will require refactoring.
- 164. How long does it take to forklift an application? https://blog.pivotal.io/pivotal-cloud-foundry/features/the-forklifted-application
- 166. Strongly recommend a pilot app or two.
- 167. Get a feel for it.
- 168. Usually a few weeks or so.
- 170. Consider staffing up a “lab” team with expertise.
- 171. Help teams migrate.
- 172. Should *pair* with the application area.
- 173. Need to grow the skills.
- 174. Create a roadmap.
- 175. When can the applications move?
- 176. It doesn’t have to be the entire application!
- 177. Some deployable units will be easy, others hard.
- 178. Move what you can.
- 179. Again, the terminology can be challenging…
- 180. Look to opportunistically migrate what you can.
- 181. But have a rough idea of when.
- 182. Does that satisfy your stakeholders?
- 183. What can you do to accelerate the plan?
- 184. Good luck!
- 185. September 24–27, 2018 Washington DC Gaylord, National Harbor Discount Code S1P200_NSchutta Register Today & Save!
- 186. 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