An app modernization story with Cloud Run

Back in 2016, I deployed an ASP.NET monolith app to IIS on Windows. It worked but it was clunky in every sense of the word. Over the years, the app was freed from Windows (thanks to .NET Core), containerized to run consistently in different environments (thanks to Docker) and decomposed into a set of loosely-coupled, event-driven, microservices (thanks to Knative and Cloud Run). The end result is a simpler and portable serverless architecture, easier and cheaper to run and maintain. In this talk, we’ll go through the modernization journey, explore the decision points and deep dive into the final architecture.

Transcript

1. An app modernization story with Cloud Run Mete Atamel Developer Advocate at Google @meteatamel atamel.dev/tags/app-modernization
2. Stage 0: Prototype (Late 2015 / Early 2016) Goal: Get something up and running Reader Transformer Web API Server: ASP.NET (4.6) Windows app on IIS hosting Client: Android and iOS app with Ionic Framework
3. Prototype: Pros & Cons +Worked! +Easy to understand +Easy to deploy +Inexpensive -Too much coupling -Bad DevEx (FTP to see logs!) -No redundancy -No persistence -No resilience
4. Prototype: Lessons Learned 1. Stick to MVP 2. Research your options 3. Avoid coupling at all costs 4. Design with future in mind
5. Stage 1: Lift & Shift (Late 2016 / Early 2017) Goal: Improve resiliency and redundancy Compute Engine Windows VMs on Google Cloud Compute Engine Compute Engine Cloud Load Balancer
6. Lift & Shift: Pros & Cons +Easy to move with ASP.NET Framework Template +Redundancy & load-balancing with Instance Template & Groups +Possiblity of autoscaling +Much better DevEx with Stackdriver logging, VM snapshots etc. -More expensive than IIS hosting
7. Lift & Shift: Lessons Learned 1. Moving to Cloud was not that difficult 2. Cloud is much more than just hosting
8. The app served us well until 2019... 1. .NET Core 2. Windows dependency 3. Containers 4. Costs
9. Stage 2: Containarization (Early 2019) Goal: Remove Windows dependency and cost Re-write in ASP.NET Core (2.2), containerize w/ Docker & deploy to App Engine Flex (Linux) App Engine
10. Containarization: Pros & Cons +Windows license fees out +Free autoscaling +Revision management +Traffic splitting -VM based -Pricing -Slow deploys
11. Containarization: Lessons Learned 1. Refactor for clear benefits 2. Solid functional tests are crucial 3. Project organization matters 4. There’s no magic bullet
12. Container to production in seconds Natively Serverless One experience, where you want it Cloud Run Bringing serverless to containers
13. HTTPS Endpoint Public • Website • API endpoint Private • Internal services • Async tasks • Mobile backend • Webhook
14. Billable time Instance Billable Time Request 1 Start Request 1 End Request 2 Start Request 2 End Instance Time Billable Non-billable
15. Stage 3: Serverless (Mid 2019) Goal: Move from VM minute-based pricing to serverless pricing Update to ASP.NET Core (3.0) & deploy to Cloud Run Cloud Run
16. Serverless: Pros & Cons +No VMs +Serverless billing, much cheaper +Quick deployments (seconds) +Great DevEx (integrated logging, revision and traffic management, etc.) +Based on open-source Knative -Still a monolith with monolith issues
17. Monolith issues 1. Scaling: all or nothing 2. Cold starts 3. In-memory state 4. No way to update individual services
18. Monolith decomposition questions 1. How do you break the monolith? 2. How do microservices communicate? 3. How do you handle persistence without coupling?
19. Stage 4: Monolith to microservices (Early 2020) Cloud Scheduler Cloud Pub/Sub Converter (Private) Cloud Storage Web (Public) Cloud Firestore Reader (Private)
20. Monolith to microservices: Pros & Cons +Loosely coupled architecture +Ability to update individual pieces +Ability to use different languages +Better utilization of resources +Persistence -Many moving parts -More complex deployment -Probably more expensive than a monolith?
21. Grand Lessons Learned • Transformation does not have to be all or nothing • Even simple lift & shift can have huge benefits • Non-optimal solutions can be a stepping stone to more optimal solutions • Expect some kind of re-write for cloud at some point • Monolith decomposition is hard! Need a good reason beyond separation of concerns
22. @meteatamel atamel.dev/tags/app-modernization github.com/meteatamel/amathus github.com/meteatamel/cloudrun-tutorial cloud.google.com/run Thank you!