 All right. Hi everyone. So I hope you get enough oxygen here. It's getting a bit difficult to breathe But we're here to talk about the DevOps approach our title slide has been hidden somehow I don't know, but my name is Anna Elnade. I work as CEO of a Swedish Moodle partner So we're situated up in the north of Sweden I've been working with E-learning production. I've been a teacher and now I'm working with Moodle providing service to a lot of different Customers mainly on the corporate sector And my name is Anders Stenmark. I also have a background as a teacher and I've been working In the software industry before I became a teacher And I've been working with Moodle for 11 years Yeah, and they're about the same for me All right, so Some background to why we Started working in a different way is that we had a lot of challenges So we were maintaining the instances for many different clients and It was growing the number of customers the number of instances and so on And we felt that The customizations that we did and it was taking us longer and longer to To maintain the product and it became a problem to have that reduced quality Security issues and so on the upgrades was taking a long time and also As we're a company that needs some profits to continue going This time-consuming way of working was causing us a low profit So the goal was to scale our business and and also to increase profitability Profitability by decreasing the cost for maintenance and development So just briefly about DevOps Development plus operations And we think that in this case it's about getting different aspects Working on the same goal working together So we have developers we have operations, but we also have the customer success team All experience or views all views are needed in order to work together on this This shows an overview of the work process So we have a discovery phase Then unstable then the development phase and staging and production And we will go into this a bit more in detail So the first part of the process is we call it the discovery phase And it's like anything you do and you need to start off planning what you're supposed to be doing We have the software the requirement specifications You see all the details that we try to plan ahead Generally the purpose and goal is the same if you're doing e-learning content It's the same if you're working with anything you need to have the vision What are we trying to achieve in this And based on that then try to figure out all the other details as you go along So it's a lot of planning and maybe if you start off with one of us doing the initial planning We soon realize that we need to involve all these different perspectives in order to get this in a good way And make it prepared for success The resource allocation of course who is doing what and when In which order do the things need to happen The project planning of course If we have a client on board it's really important to have them available At the times that we need them to look at things Alright then you can Yeah so we really like container technology And we've been using Docker for six years or something like that So when we put together a project the developers and operations plan the development together And all developers use the same Docker compose with the possibility to make local adjustments in their dev environment And we also have we work a lot in sprints using a very simple ticket system that aligns to the overall planning And each morning we have a 15 minute team meeting To check in on progress what tickets have been done And especially what issues have someone been having And it could be a development issue or it could be a deployment issue or anything that needs like the full team brain power Completed and development tested development is then pushed to the dev where it's further tested by other persons We have sort of a continuous delivery philosophy Where push changes are automatically built and pushed to either unstable or dev depending on what type of application you're in All unstable and all everything that's pushed to unstable is built nightly And includes all updates including bugs and any issue you might have Same with with dev everything's built every day Staging we build twice a month and remember I said we use containers So all of our dev servers and stating servers are technically identical So we build stating servers twice a month where we have selected updates Basically the ones that we have validated in our dev environment or that has been validated by someone else than the developer In the dev environment are pushed to the stating environment And then we do pushes to our production servers once a month and those are the validated updates in the staging environment So we go to quite some length to verify that the updates that are pushed to each instance are validated by the developer And that they are validated by someone else And oftentimes also the customer that validates it in the stating environment Our operations are responsible for ensuring and improving efficiency and security in our services So our production nodes are automatically restarted once a month to fetch the latest production built And we have uptime robot that monitors all of our installations So this means that we can actually when we push to production the update is then fetched on a time schedule And installed automatically while we're sleeping So in the result what we've seen is that for us it's a shorter time to market We can have a new Moodle LMS up and running in 30 minutes And we will soon have automated everything that needs to be done manually now We've found it much easier to adapt to the requirements that our customers have And to the competitions that we face especially in the Swedish market which is our primary market The biggest benefit of using this approach has been that we have continuously been able to improve our testing features And we have increased the stability for all the Moodle LMSs that we provide for our customers Because since we use this approach and this technology we are very certain that the fixes and improvements That we previously made for one installation now gets applied to all the installations that we have So it really benefits all of our customers when we do improvements and especially it increases stability when we do updates Because before we do an update it's been updated many times before it's pushed to the production Yes that was the presentation and we're keen to hear your thoughts if you have questions for us Also a discussion around the challenges, the opportunities around this approach So anyone? So first of all congratulations It's not that usual to see an approach based on containers for Moodle I think that's changing a little bit but you know it's great to see Among the logos that I saw in that slide I didn't see Kubernetes Is there a reason by which you guys are not using it or? What's the question why we're not using Kubernetes? Why you're not using Kubernetes? At least I didn't see the logo in that slide so I don't know if I got that right Okay so there's no reason for it, we're moving into Kubernetes As we speak we sort of figured out how we should do that Now it's more what we haven't really figured out or what we want to understand better is how to scale things using Kubernetes Hi, thank you for the presentation We have a similar setup and we have had a bit of issue with our clients wanting to have their data on the test server Or at least some of the data on the test server and that's a bit problematic Have you have a similar experience and a solution for that? So the issue is that your clients have data on the test server and they want to replicate that to the production server For testing purposes that they want the real life data on the test server with user info and such And that's a bit of a problem with GDPR and all Have you had any experience with that? Yeah, I think that's actually one of like the toughest nuggets to sort of crack And I don't know if we have fully cracked it because it's exactly what you say Like the issues that we stumble upon from time to time is that there is a discrepancy Like when you do test data you might just write some sort of script that generates data in a very specific way And our customers they don't generate data in a very specific way And so I don't think we have any really good solution to that Our staging environments are at least to some extent or at least for some customers What we have done there is that we have taken their production servers And anonymized all the data and used that as their staging environment I think that's what that has probably helped us the most to avoid those types of issues Elaborating on the Kubernetes and Docker thing How did you structure your flow with the containers in particular in the case that you want to scale? Are you using the containers in production or not? We're using containers in production Okay And in case you need to scale how you manage it So now we should have our operations guy answering those questions because he's much more into that than we are But we would be happy to talk to you after Yeah absolutely, I will Thank you, sorry to jump in again There are certain offers out there that can help with that scale demand You can go to Google Cloud or even AWS You can create scalers based upon a couple of metrics that you can put together to make that happen So there are even offers out there that automatize the process for you So there are options that can help with the scaling Kubernetes for this So just a thought there One of the things when you work in Sweden is that Especially for like government agencies and municipalities They will not choose Amazon at all It's sort of off-table And that applies for It has started to apply a lot for private companies in Sweden as well because of GDPR Anything for municipalities or government agencies Anything that's outside of the nations border is a big no Which makes things more complicated