Upgrade to Pro — share decks privately, control downloads, hide ads and more …

An app modernization story with Cloud Run

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.


Mete Atamel

April 15, 2020


  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!