Successfully reported this slideshow.

Scaling a Serverless Developer Platform for Teams

0

Share

1 of 101
1 of 101

Scaling a Serverless Developer Platform for Teams

0

Share

Download to read offline

In this presentation, you’ll get a practical high-level overview of how it actually works scaling development activities to many teams using serverless and cloud-native technologies. We’ll look at the tech itself, some example architectures and common concerns to address. While we are AWS-centric here, the lessons learned and advice are transferable to other clouds as well.

First presented at AWS User Group Gothenburg, March 31 2022.

In this presentation, you’ll get a practical high-level overview of how it actually works scaling development activities to many teams using serverless and cloud-native technologies. We’ll look at the tech itself, some example architectures and common concerns to address. While we are AWS-centric here, the lessons learned and advice are transferable to other clouds as well.

First presented at AWS User Group Gothenburg, March 31 2022.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Scaling a Serverless Developer Platform for Teams

  1. 1. Scaling a Serverless Developer Platform for Teams Mikael Vesavuori
  2. 2. Scaling a serverless developer platform for teams # 1 - Get a sense of how serverless offers a paradigm that is easier and more effective to implement for typical teams
  3. 3. Scaling a serverless developer platform for teams # 1 # 2 - Understand the variety of “developer platforms” you can use to empower developers and streamline development
  4. 4. Scaling a serverless developer platform for teams # 1 # 2 # 3 - Look at some examples of developer platforms I’ve helped set up - Sharing of some key learnings
  5. 5. - Cloud Software Architect and Technical Standards Lead at Polestar - Experience with developer platforms with Humblebee, Volvo Group Connected Solutions (Volvo Autonomous), Mölnlycke Health Care, Polestar - Makes a lot of open source and writes on Medium - Serverless and cloud-native fan for 5+ years - https://mikaelvesavuori.se Who am I?
  6. 6. No platform, no job…?
  7. 7. Serverless?
  8. 8. https://www.youtube.com/watch?v=AXxr0pghWS0
  9. 9. Cloudy with a chance of Kubernetes
  10. 10. Kubernetes is the wrong abstraction
  11. 11. So hard and “chorey” it’s a meme
  12. 12. https://www.cncf.io/blog/2022/03/07/devops-why-it-is-misunderstood-what-it-always-should-have-been/
  13. 13. But there is!
  14. 14. Serverless
  15. 15. - Typically short-running - On-demand - Stateless - Pay per execution - Managed - Auto-scaling Common identifiers for a serverless service
  16. 16. - Global scaling with much less effort - Faster to get going - Less/no undifferentiated heavy lifting - Less/no maintenance - “Higher abstraction” means less need for deep expertise - High developer experience (DX) - Ideal with microservice architecture - Not just functions-as-a-service: serverless databases, messaging, etc. Benefits
  17. 17. Gateway pattern
  18. 18. Event-driven (async) pattern
  19. 19. Actually not bullshit that it “just needs a YAML file”
  20. 20. - Microservices and serverless functions place a big burden on developers to be mature and stringent enough to write acceptable, "correct" services - Can be harder to monitor depending on your setup and operations (can also be relatively easy if you go all-in) - Can be hard to figure out all potential hacking scenarios, involving for example event injection - Easy to get identity and access management (including permissions) wrong with serverless functions, potentially evolving into security problems - Can be hard to stitch together stepped events if your use case cannot be covered by native cloud event sourcing - requires clarity on workflows/sagas and similar Negative traits of serverless (esp. FaaS)
  21. 21. Developer platform?
  22. 22. - As little as a text document - As much as a full, unique proprietary product - Enables self-service: for example RBAC, environment provisioning, infrastructure management, templates, and more - Self-service <——> DevOps - Some degree of centralization around the “platform” required What is a developer platform?
  23. 23. Devs gonna dev…and gonna platform…and…?
  24. 24. - Backstage - Humanitec - Upbound - DevOpsBox - Shipa - Begin (?) - AWS Proton - AWS Service Catalog - … What options are there?
  25. 25. Backstage
  26. 26. Humanitec
  27. 27. AWS Proton
  28. 28. How low can you go?
  29. 29. Netlify (+ maybe some minimalistic framework like Svelte)
  30. 30. Vercel
  31. 31. The direction seems to be moving to even higher-level abstractions
  32. 32. Begin
  33. 33. Begin !
  34. 34. Architect
  35. 35. Anyway, let’s move on now
  36. 36. Time for a bit of history
  37. 37. 1 developer 1 designer
  38. 38. - Created multiple boilerplates for front-end projects to minimize time waste and scaffolding - Created style guides and design-to-code abilities with tokens; actually fairly early! - Improved and adjusted patterns that I found were poor practice from other, more typical offerings - Open sourced these (my first OSS projects!) How I began
  39. 39. Anyone remember this bird? 🪦
  40. 40. Or the big drink? 🪦
  41. 41. - Yep, absolutely use a code-oriented way to store, manage, and create tooling - It’s well worth providing the full monty: linting to structure to deploying - Learned a lot of soft skills involved: Project hygiene, documentation, DX… - Gave a good head-start on automation tooling - Did not meaningfully affect anyone other than me, though Outcome and lessons learned
  42. 42. 10+ developers ~3 designers Lots of projects
  43. 43. Startup time = a financial liability
  44. 44. - At Humblebee, I evolved the same kind of “all-in-one” tooling - Conformity and set good opinionated defaults for cross-functional requirements such as performance, security, offline support… - One toolbox to enable scaling from MVP to production - Move devs into “one way of working” - “Progressiveness” in tooling choices - Help transition from web sites to web applications - Bet on React, Webpack, PWA - Introduce CI/CD and modern web tooling like Netlify - Go serverless Scaling to applications at Humblebee
  45. 45. Be faster
  46. 46. Actually, be 100x faster
  47. 47. No more than 4:48 We met this goal and could typically set up a frontend application with a serverless backend in around 4 minutes.
  48. 48. - Yep, absolutely use fully managed services with high DX - Created a software platform that devs were encouraged to co-own (inner source) - Devs felt they could get going fast - Good way to learn new technology inside the company - Drastically improved our race to build applications (from practically zero) - Drastically decreased risk and time-to-start - Easy to onboard our bi-yearly Hive students Outcome and lessons learned
  49. 49. Approach I have used with Polestar (and elsewhere)
  50. 50. WHAT Should be able to go from zero to deployed service in minutes, while having guardrails in place to ensure maximum “playing field” without creating issues as they evolve. HOW Developer have a stable starting point, yet have full authority to adapt their scaffold as needed and create required infrastructure. Ambition
  51. 51. - Cloud-native - DevOps - Infrastructure as Code - Serverless - Microservices - Fully managed - Decoupled and headless - SaaS-type solutions for non-unique requirements Principles (that will usually be “right”)
  52. 52. Create a clear, transparent, opinionated platform from scratch based on architectural primitives (services) from the cloud. - Platform Team maintains the developer-facing tools and acts as support - Provide “glue” tooling and opinions for things that devs may not think a lot about - Provide CI/CD pipelines with “GitOps”-type operations where CI makes the changes - Application boilerplates (Node, .NET, GraphQL) a core component of the overall platform - Remove decisions that can be centrally made (for example language support) - No need to individually be responsible for all the concerns to be compliant with our guidelines Approach I’ve used with Polestar (and elsewhere)
  53. 53. User access control (meta, pre-requisite) - Developers get an SSO profile in the cloud + source code system CI/CD - Use a fully managed, hosted solution like GitHub, GitLab, Bitbucket, AWS CodeBuild… - Team start with a working (managed) pipeline, but get to own and modify it as they need - CI has restricted set of rights to deploy into lifecycle environments Infrastructure provisioning - Terraform, CDK, Serverless Framework, “native” (CloudFormation, ARM, and similar) - IAC + CI/CD means we have completely deterministic runs Environment management - Use minimal env count; make them exact clones; use software-defined stages as far as possible Network - Cloudflare, AWS Route53… Documentation - Generate and distribute documentation during CI Tools
  54. 54. Generalized examples incoming
  55. 55. Serverless and “everything-as-code” is an ideal, lightweight combo. No need for anything more complex! - We are not a full IDP because we don’t have to be! - The solutions I have worked on have (so far) not required an “actual” platform as a piece of software to go in between the developer and our environments - Dev Platforms are very Kubernetes-oriented? They seem to need to move up the abstraction layers…? - I (and devs!) seem to have been happy with “less sophisticated” approaches this far - Don’t abstract too much; no reason to become an expert in a non-standard, proprietary tool - Instead, automate most of the parts that are needed for a developer (or team) to be productive - Don’t underestimate churn and maintenance of keeping a big platform floating Our platform is not a “real” IDP - and it’s OK!
  56. 56. Lessons learned
  57. 57. - Don’t assume you need a big “platform” to be helpful - Your platform should be dead easy - no reason to be “good at it” - Architecture and tech choices need to be crystal clear - since the platform will high-speed them - Don’t make it bigger than you can meaningfully support Lesson #1: Bigger is not always better
  58. 58. - Use an open-source or inner-source approach - You will need to set up processes and communicate standards for contributions - Spend time documenting - Talk about the platform, show the platform, create internal ambassadors - Train yourself with your own (or by supporting existing) open source software - Assume that OSS might very well have higher standards than closed source! Lesson #2: Make it open
  59. 59. - Make it “easy to do the right thing” and “hard to do it wrong” - Enable people to do their own job without asking for help or guidance plus update stuff as they go along - IMO, the most significant parts you can do are: - 1. Provide the minimum viable code base for a typical application - 2. Provide plumbing + access so applications can go from localhost to production with no/minimal specialized skills - It’s not just about providing the “hard” tech - don’t forget about docs, discoverability etc Lesson #3: Champion a self-service approach
  60. 60. https://github.com/mikaelvesavuori/catalogist + https://github.com/mikaelvesavuori/better-apis-workshop
  61. 61. Lesson #4: Platform interaction must be just that - Easy to break stuff if communications and expectations are not explicit and known - Platform teams should be precisely that; nothing else - Can be hard to make traditional orgs understand the value of platform teams - Learn from Team Topologies
  62. 62. https://teamtopologies.com
  63. 63. - Don’t trivialize the skills bump but don’t make everything sound like magic either - Onboarding is important - Rapid enablement can create ignorance which can lead to dangerous “mindtraps” - Provide training for the core skills (ex. IAC) if not abstracting them fully Lesson #5: Learning is harder than you think
  64. 64. In conclusion
  65. 65. - Serverless offers a paradigm that is easier and more effective to implement for many teams - An IDP wraps a set of tools together to empower developers and streamline development - it can be super elaborate or very simple - The end goal of such platforms is to make business value creation easier, faster, more stable - At Polestar, our Platform team provides and maintains a set of serverless-oriented internal products and starters for teams to use - The key takeaway is that you should definitely think of how a platform could serve you and your context, but that it’s not going to be a one-size-fits-all solution, plus it’s easier to think about tech stacks more than (the actually hard stuff) around “softer” issues like onboarding, training, documentation, learning, platform ops, and such In conclusion
  66. 66. - https://www.youtube.com/watch?v=AXxr0pghWS0 - https://thenewstack.io/do-you-need-an-internal-developer-platform/ - https://internaldeveloperplatform.org/what-is-an-internal-developer-platform/ - https://www.cncf.io/blog/2022/03/07/devops-why-it-is-misunderstood-what-it-always-should-have-been/ - https://teamtopologies.com - https://github.com/TeamTopologies/Thinnest-Viable-Platform-examples - https://github.com/mikaelvesavuori/ - https://backstage.io - https://humanitec.com - https://aws.amazon.com/proton/ - https://fwa.dev - https://www.netlify.com - https://vercel.com - https://begin.com - https://www.humblebee.se References

×