Paving the path towards platform engineering using a comprehensive reference model.pptx

Editor's Notes

• #2: KEES Paper is based on the master thesis of Ruben van de Kamp, investigating platform engineering at Wehkamp.
• #3: KEES Recent graduate Master Software Engineering at the University of Amsterdam - - graduated with an honours Have been working for Wehkamp almost 4 years (Product Information team)
• #4: KEES Explain path finder: Not only enterprise architecture Also way of working Turning strategy into delivery
• #5: KEES First we’re going to give some context about Wehkamp and our engineering setup Then we’re going to look at platform engineering We’ll elaborate on our case study And we’ll share the conclusions
• #6: KEES
• #7: KEES WRG: Wehkamp Retail Group 3 webshops: Wehkamp, Kleertjes.com and Union River
• #8: KEES Let’s focus on Wehkamp and some statistics Quite an operation
• #9: KEES
• #10: KEES How did we get here?
• #11: KEES Article by The New Stack introducing Platform Engineering Had not heard about it yet It feels like a fit, we already use many tools in our container platform.
• #12: KEES Golden paths feel like a fit Again, the fit is there: observability (logs, metrics) are 100% shared. Most services use a form of dependency injection and ORM that is not so different. So the main question is: How can we implement platform engineering? One way to start: get a graduate student to do some research! So here’s where Ruben comes in!
• #13: RUBEN
• #14: RUBEN Before we dive into the research we first want to give a short explanation of what platform engineering is and why it is important Platform to centralize and standardize tools Focusses on organization instead of team level
• #15: RUBEN Main focus: How can platform engineering be implemented In order to give answer: 3 questions: How to model How to design guided by PE-RM How to implement guided by PE-RM
• #16: RUBEN It can be concise: not a lot of research done. We have focussed on what reference models there are related to other methodologies: DevOps and Agile Focusses on team level and therefore not sufficient for platform engineering How to model a reference model: ODP-RM -> later will be explained
• #17: RUBEN Many articles talking on what they believe platform engineering is White paper from humanitec -> reference architecture, but only focusses on technical implementation
• #18: RUBEN ODP-RM → multiple viewpoints to give better understanding
• #19: RUBEN Created with a iterative process where we interviewed different experts
• #20: RUBEN First thing will be how the platform lifecycle will work, by introducing a platform it needs to have a lifecycle Two starting positions: no adoption, new features Lead to same lifecycle where platform is build
• #21: RUBEN The existing development lifecycle will stay the same Platform engineering will have impact on provision of application domain that will help in development lifecycle
• #22: RUBEN First talk about platform team Talk about development team and that they are stakeholders of the platform Development guild → important for golden paths Enterprise architects
• #23: RUBEN Point out the platform version and golden paths Development guilds are maintaining these golden paths
• #24: RUBEN Explain that the development team will create an application design and based on that they can come up with platform feature requests
• #25: RUBEN Operations can be separated into two functionalities: getting applications in production and keeping applications in production Computational viewpoint is more difficult → can be different for each organisation Golden paths are essential in the translation of these operations The sequence diagram separates the different actors in planes which we will showcase in the engineering viewpoint Diagram link: https://app.diagrams.net/#G13CGjLkFYjmYsTMrY3XqGA_1XHfFMPVkd
• #26: RUBEN Based on the Humanitec reference architecture since the separation of planes are valid Normally it is important to point out the objects and channels, but this way we can better translate into real world scenarios Developer Portal: one stop shop for self service
• #27: RUBEN It depends on the organization and what tools they already use Brownfield project More focussed on the standardization and guidelines on what would be most suitable in this platform
• #28: RUBEN It depends on the organization and what tools they already use Brownfield project More focussed on the standardization and guidelines on what would be most suitable in this platform
• #29: KEES Nice overview by Ruben Let’s see how this matches at Wehkamp First we’ll create a conceptual design And than Ruben will guide us through a prototype to do some experiments so validate our model
• #30: KEES Redefine roles Missing consultation structures: backlog management, planning, delivery sessions
• #31: KEES Implementation of features Do’s or don’t – guard against excessive feature
• #32: KEES
• #33: KEES Now: users, eat what you get PE: stakeholder with influence
• #34: KEES Golden path as a reference architecture Golden path as a jump start
• #35: No formal delivery, poor versioning of the platform Individual tools are now versioned and communicated Platform should be one integrated product
• #36: Measure effectiveness
• #37: Missing golden paths
• #38: Missing process to further do platform development from the dev team perspective Again: it is all about individual tools
• #39: Less effort Standardize on default settings
• #40: KEES Let’s add the tools to the boxes of the technology viewpoint Our tools fit very well within the model
• #41: KEES No dev portal
• #42: KEES The platform is not treated as 1 integrated product. Ruben wants to do some experiments We’re missing metrics Let’s get them from our pipelines / GitHub Ruben wants to do some experiments
• #43: Ruben wants to do some experiments We’re missing metrics Let’s get them from our pipelines / GitHub
• #44: RUBEN
• #45: RUBEN We mainly used two open source tools from which we continued to implement the platform: Otomi: PaaS solution → helps to setup a lot of the tooling, however the configurations of the tooling and the way it all interacts as one implementation in this research had to be done manually Backstage: this is the main point of work, this linked everything together including templates etc.
• #46: RUBEN In order to showcase the added value a platform will bring to the organization and development teams we have created a very based application lifecycle You will start with creating your application domain: Create repository Pipelines Maybe some boilerplating You will develop your application You want to update your domain by making deployment files You want to monitor you application
• #47: RUBEN We have created golden paths that will have only one input: the application name It will do the following: Create your repository Create your CI/CD pipelines Create your docker registry Scaffold the application with best practices
• #48: RUBEN When you want to deploy an application you can use a different golden path → setup deployment workload files This will take care of the following Create yaml files for argocd to deploy application Setup the docker image to the latest version that has been stored Update pipelines to automatically deploy when new version is released
• #49: RUBEN Because the application are scaffolded in the golden paths they will all expose defaults metrics Use predefined dashboards to see the metrics
• #50: RUBEN Now that we have created a prototype we can do some experiments to see if it actually has any effects
• #51: RUBEN We did three experiments: Performance analysis: validate if it is actually helping developers Usability study: is this platform something that the developers want Expert feedback: is the implementation suitable within an organization Performance analysis and usability study are done in one experiment
• #52: People from inside and outside the organization were asked Before we did the experiments we asked the participants to give an estimation on the time it would take them to deploy an entire application to production in which they already have the tools available, they only have to make the entire devops lifecycle Average: almost 7 hours
• #53: The participants are divided into two categories: No tutorial: deploy react application to dev Tutorial: deploy nestjs application to Prod, but also dev Tutorial: gather logs and metrics of application in production The average time it took to get an application to production was around 22 minutes which is much lower than the average of almost 7 hours.
• #54: After the tasks the participants were asked to fill in a questionnaire Role → different type of roles to get feedback from different experienced people Ease of use → accidentally reversed the scale, however the ease of use was pretty create, however the open questions suggests that the multiple ui’s made it more difficult Based on open questions a tutorial and documentation is very helpful especially when onboarding new developers Task ratio → the platform did almost all the tasks, which is exactly how the participants experienced the experiments
• #55: Likeable feature → backstage and the golden paths, since it gave the developers an easier time setup their infrastructure Recommendation → everybody suggests to introduce this within their work
• #56: IMPORTANT: tell about the fact that we first did a demo and discussion to give them the most information before the questionnaire Role → different types of roles, not on experience but more on the way they are located in the organization, different viewpoints Platform design → the design of the platform was great, both technical as well as functional Ease of use → they believe the platform is easy to use
• #57: Applicability → not always very high → this was expected since each organization could have their own way of implementing things or have an existing tool set Integration with other systems → same thing, depends on the organization since green field projects is not likely Recommend → everybody would recommend the platform however Otomi is not always the best solution
• #58: RUBEN Now that we have explained to you what we have done it is time to wrap things up and summarize our research
• #59: RUBEN
• #64: Now we only have created a reference model and validated it with a conceptual design and a separate prototype It would be better to implement it in a real organization and see the effect, but that will take time Case studies within more organizations to see if is applicable to a range of organizations The field is new, so it can change fast and therefore the reference model needs to be updated (if necessary) Although we have tried to keep it as general as possible
• #65: KEES