1. Scaling a Serverless Developer Platform for Teams
Mikael Vesavuori

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. 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. 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. - 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?

9. No platform, no job…?

10. Serverless?

11. https://www.youtube.com/watch?v=AXxr0pghWS0

12. Cloudy with a chance of Kubernetes

13. Kubernetes is the wrong abstraction

14. So hard and “chorey” it’s a meme

18. https://www.cncf.io/blog/2022/03/07/devops-why-it-is-misunderstood-what-it-always-should-have-been/

20. But there is!

21. Serverless

22. - Typically short-running
- On-demand
- Stateless
- Pay per execution
- Managed
- Auto-scaling
Common identifiers for a serverless service

23. - 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

26. Gateway pattern

27. Event-driven (async) pattern

28. Actually not bullshit that it “just needs a YAML file”

31. - 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)

32. Developer platform?

33. - 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?

34. Devs gonna dev…and gonna platform…and…?

38. - Backstage
- Humanitec
- Upbound
- DevOpsBox
- Shipa
- Begin (?)
- AWS Proton
- AWS Service Catalog
- …
What options are there?

39. Backstage

40. Humanitec

41. AWS Proton

42. How low can you go?

44. Netlify (+ maybe some minimalistic framework like Svelte)

45. Vercel

46. The direction seems to be moving to even higher-level abstractions

47. Begin

48. Begin
!

51. Architect

52. Anyway, let’s move on now

54. Time for a bit of history

55. 1 developer
1 designer

56. - 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

61. Anyone remember this bird?
🪦

62. Or the big drink?
🪦

64. - 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

65. 10+ developers
~3 designers
Lots of projects

66. Startup time = a financial liability

67. - 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

68. Be faster

69. Actually, be 100x faster

70. 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.

79. - 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

80. Approach I have used with Polestar (and elsewhere)

81. 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

82. - 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”)

83. 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)

84. 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

85. Generalized examples incoming

89. 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!

90. Lessons learned

91. - 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

92. - 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

93. - 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

94. https://github.com/mikaelvesavuori/catalogist + https://github.com/mikaelvesavuori/better-apis-workshop

95. 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

96. https://teamtopologies.com

97. - 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

98. In conclusion

99. - 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

101. - 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