What does it take to get an application into production? Many processes, tools and automation surround that application to deliver it to the customer. As it becomes more common for development teams to autonomously deliver and run their software, the focus of the traditional operational teams shifts towards an as-a-service mindset. But how is such a team positioned within the company? And is Platform Engineering any different from Software Engineering? In this talk I’ll share my experiences as a platform engineer and explain why I believe that every company should be conscious about why and how to setup this responsibility. I’ll also discuss the biggest challenges surrounding it - and how to tackle them.

1. Platform Engineering 101
Empowering developers to deliver - as-a-service
Skyworkz - https://skyworkz.nl
Sander Knape - https://sanderknape.com

2. Hello, I’m Sander Knape
Cloud Engineer @ Skyworkz

3. Let’s build an app
● Application that connects to a database
● Works on my machine™
→ Let’s get it into the Cloud!

4. Cloud provider / runtime environment

5. Infrastructure as Code

6. CI / CD

7. Artifact management

8. Security scanning

9. Configuration management

10. Secret management

11. Monitoring, logging, metrics

12. Alerts

13. Database migrations

14. Database anonymization

15. Cost insights

16. Security

17. ...

18. There’s quite a bit going on
Cloud provider / runtime
environment
Infrastructure as Code
CI / CD
Artifact management
Security scanning
Configuration
management
Secret management
Monitoring, Logging,
Metrics
Alerts
Database migrations
Database
anonymization
Cost insights
Security
Application

19. Software development is more than just
writing [Go, Java, NodeJS, C#, …]

20. You need a platform

21. Kubernetes isn’t enough

22. Definition time: “Platform Engineering”
The composition and integration of a set of processes, tools and automation
(components) to build a coherent platform with the goal of empowering developers
to be able to easily build, maintain and operate their business logic.

23. Why Platform Engineering?

24. Why Platform Engineering
“[T]he reality is that state of the art cloud native technology is still too hard to use if
every product engineering team has to individually solve common problems
around networking, observability, deployment, provisioning, caching, data storage,
etc.”
https://medium.com/@mattklein123/the-human-scalability-of-devops-e36c37d3db6a

25. VPC’s in AWS

26. Specific knowledge is required

27. Ownership

28. Platform Engineering
==
Software Engineering

29. Who has the responsibility?
1 or 2 platform engineers
1 platform team
multiple platform teams

30. Multiple approaches
● “Just hand me your source code on a USB stick. I’ll put it on the server and
make sure and that it keeps working”
Or…
● “Create a pull request <here> to automatically get a Git repository, CI/CD,
filled with a Hello World application, that deploys all the way to production”

31. Challenges we’ll talk about
1. Protecting the platform for organizational scalability
2. Building an opinionated platform
3. Specifying contracts
4. Collaborating with your users

32. Protecting the platform for
organizational scalability

33. AWS Lambda: Language Support

34. AWS Lambda: Custom Runtimes

35. Protect the platform
https://www.independent.ie/sport/soccer/premier-league/the-platform-we-created-is-more-important-than-one-
person-mauricio-pochettino-coy-on-future-37652030.html

36. The question to ask for each new feature
How much support will I need to provide after I have delivered this feature?
Less (or equal) is the only acceptable answer

37. Reducing toil
“Toil is the kind of work tied to running a production service that tends to be
manual, repetitive, automatable, tactical, devoid of enduring value, and that
scales linearly as a service grows.”
https://landing.google.com/sre/sre-book/chapters/eliminating-toil/

38. Examples of toil
● Manually creating Git repositories and granting the correct people access
● Manually creating CI/CD pipelines based on another project
● Running load tests from a laptop with a security token that you can not share
● Putting secrets into your secret management solution

39. Examples of toil: old-school operations
● Manually;
○ Flushing caches
○ Rebooting servers
○ Renewing SSL licenses
○ ...

40. Toil leads to bottlenecks

41. Toil leads to boredom...

42. … or toil leads to stress

43. Self-service through automation

44. Self-service instead of toil
● Manually creating Git repositories and granting the correct people access
● Manually creating CI/CD pipelines based on another project
● Running load tests from a laptop with a security token that you can not share
● Putting secrets into your secret management solution

45. Scalable support
Developer: Hello, can you help me with “something” for feature X?
Platform: Did you check the docs for feature X?
Developer: Yes, but it doesn’t mention anything about “something”
Platform: I see, give me as second
Developer: Sure
Platform: I edited the docs to include “something”, does this answer
your question? https://github.com/org/docs/pull/1337
Developer: Totally, thanks!

46. How to protect yourselves
● Automate. Think “as a service”.
● Prefer managed solutions above self-hosted. Every minute you spend on
maintaining a self-hosted solution is time not spend on improving the platform
usability
● Prefer documentation above single answers
● Make the platform as simple as possible

47. Building an opinionated platform

48. AWS Lambda: Language Support

49. Abstraction levels
“Serverless”
“IaaS”
Levelofabstraction
“Bricks”
Platform
Managed externally
Platform features

50. Abstraction levels
“Serverless”
“IaaS”
Levelofabstraction
“Bricks”
Platform
Managed externally
Platform features
Splunk Cloud
AWS CloudWatch
AWS Secrets Manager
Google Cloud Datastore

51. Abstraction levels
“Serverless”
“IaaS”
Levelofabstraction
“Bricks”
Platform
Managed externally
Platform features
HashiCorp Vault
Splunk Self-Hosted
Prometheus/Grafana
MySQL on EC2
GitLab on EC2

52. Abstraction levels
“Serverless”
“IaaS”
Levelofabstraction
“Bricks”
Platform
Managed externally
Platform features
CloudFormation

53. Abstraction levels
“Serverless”
“IaaS”
Levelofabstraction
“Bricks”
Platform
Managed externally
Platform features

54. Abstraction levels
“Serverless”
“IaaS”
Levelofabstraction
“Bricks”
Platform
Managed externally
Platform features
Developer
responsibility

55. Self-service
● Lambda languages v.s. Lambda runtimes
● Hosted, shared CI/CD solution vs. BYO CI/CD solution
● Default Docker / EC2 images vs. built your own
● Default network with every application vs. create your own VPC/Subnet

56. $> curl -s localhost:9200/_cluster/settings?include_defaults=true
| jq '.defaults'
| grep ""[a-z_.-]*": ["[]"
| wc -l
361
Elasticsearch settings

57. Elasticsearch settings in AWS

58. It’s about balance

59. Business value
What is the business value of each development team maintaining their own;
● CI/CD server
● Monitoring solution
● Network
● ...

60. Getting buy-in
Team Manifesto
We build everything with developers. We’ll always select a pioneering team that
has interest in a new service/feature, and work with them to make sure we pick
and configure the right tool and solve the root problem.

61. How to sell an opinionated platform
● Simple to use, high-level abstractions; developers shouldn’t want to use
anything else
● Make everyone aware of the constant balance seeking
● Build the features together with developers

62. Specifying contracts

63. AWS Lambda: Language Support

64. Your contract is your interface
“Serverless”
“IaaS”
Levelofabstraction
“Bricks”
Platform
Managed externally
Platform features
Interface

65. Perfect world
Platform Application

66. Actual world
Platform Application
Grey area

67. Implemented world
Platform Application
Contract

68. Implemented world
Component
A
Component
B
Contract

69. Embrace dependencies
Order
Service
Product
Service
Artifact
Mgmt
Owner:
backoffice
team
Owner:
catalogue
team
Owner:
platform
team

70. Write documentation

71. Documentation
“Serverless”
“IaaS”
Levelofabstraction
“Bricks”
Platform
Documented by the external party
Documented by the platform team
Interface

72. AWS: Shared Responsibility Model

73. Shared Responsibility
● Git repository automation
● CI/CD autoscaling
● Network ACLs
● Kubernetes cluster
● Logging / Metrics agent on EC2,
listening on specific port
Platform Development
● Creating Git repositories
● CI/CD configuration
● Security groups
● Application in Kubernetes
● Shipping logs/metrics to specific
port

74. Continuously test your responsibility
● Are my agents autoscaling?
● Are my NACLs correct?
● Is my Kubernetes cluster stable?
● Are the logging/metrics agent operable?
→ Make this transparent!

75. Shift left
Idea Development ProductionStaging
Early feedback Late feedback

76. Codify your contract
execution:
- concurrency: 5
hold-for: 20m
ramp-up: 5m
scenarios:
requests:
- method: GET
url: https://example.com
modules:
blazemeter:
projectName: Team Name
testName: Test Name
modules:
blazemeter:
projectName: .*
testName: .*
Implementation Contract

77. Codify your contract
Best Really good

78. Codify your contract
execution:
- concurrency: 5
hold-for: 20m
ramp-up: 5m
scenarios:
requests:
- method: GET
url: https://example.com
modules:
blazemeter:
projectName: Team Name
Must specify testName:
https://url/to/docs

79. $> git clone example/template/skeleton
Codify your microservices

80. Default microservice
● Unit testing
● Integration testing
● Log example
● Metric example
● Secret example
● CI/CD to production
● ...

81. How to define your contracts
● Be aware of the contract and make the company aware
● Minimize the gray area
● Codify your contract
○ Shift left
○ Examples / blueprints
● Make sure the company understand the interface to your team

82. Collaborating with your users

83. AWS Lambda: Language Support

84. Scalable support
Developer: Hello, can you help me with “something” for feature X?
Platform: Did you check the docs for feature X?
Developer: Yes, but it doesn’t mention anything about “something”
Platform: I see, give me as second
Developer: Sure
Platform: I edited the docs to include “something”, does this answer
your question? https://github.com/org/docs/pull/1337
Developer: Totally, thanks!

85. Getting buy-in
Team Manifesto
We build everything with developers. We always select a pioneering team that has
interest in a new service/feature, and work with them to make sure we pick and
configure the right tool and solve the root problem.

86. Scalable support

87. Imagine… a power outage
You’re at home, watching TV, and BAM: TV is out, lights are out. What do you do?
● Check the other rooms to see the scope of the outage
● Check with the neighbours if it’s just your home or more
● Check with the power company

88. How to collaborate with your users
● Teach everyone how the platform works, in a scalable way
○ Documentation
○ Workshops
● Enable collaboration between development teams
● Make it clear how you work

89. Summarizing
1. You need a platform - and someone should own it
2. Always think about scale - both organizational and technical
3. Opinions are OK
4. Specify contracts, but be careful about what you support
5. Collaborate

90. Thank you!
Questions?
Skyworkz - https://skyworkz.nl
Sander Knape - https://sanderknape.com - @SanderKnape