 Good afternoon and welcome to the webinar Dispelling Public Cloud Myths. My name is Mark Epton, your host and technical consultant here at EduServe. Today I'm joined by Merevon Hassel, who is the IT Strategy Manager for Alesbury Vale District Council. Our webinar today is in three parts. Initially walking through some of the more common myths around public cloud and its usage in government, then leading to an overview of moving from cloud from the perspective from Alesbury Vale District Council, we will then follow up with a Q&A session. Within the webinar software you will see a panel allowing you to post your questions and we will do our best to answer as many as we can at the end of the presentations. The webinar itself will also be available for download and playback after the event closes. To start, let's look at the drive towards cloud in public sector. In 2012 the government introduced the cloud store, which is now morphed into the digital marketplace as we now know it. The aim was very simple. It was to establish a single marketplace in which providers of all sizes could expose services and pricing thereby potentially driving down the cost of public sector IT. With this the G-Cloud framework came into being, allowing shorter more flexible contracts to be created without the need for full procurement competitions that we have seen to date. In 2014 this took a further step on with the government making announcements for digital by default across all public sector bodies as a part of the core digital strategy of government. This was a further push to get public sector bodies to engage and evolve forwards towards some and move away from some of the legacy technology that supports society through the various institutions. However, public sector is raced ahead with the adoption of cloud services and a new model of subscription and consumption building has evolved and the efficiencies and opportunities to utilize new technologies have been abound. The public sector though has been seemingly lagging behind this curve. Why? Through the webinar we'll uncover some of the myths that are commonly seen as reasons not to move and also look at a case of a successful migration. Myth number one, public cloud is insecure and everyone can see my data. It's possibly one of the biggest misconceptions I regularly find with many late adopters as they think public means public, that everybody can see everything and it's available. Rather than it, what it really means is that the cloud fabric itself is available for use by anyone with a computer and a means to pay for it. The public cloud itself is inherently secure. It's been designed that way with security at the core all the way through and remains that way when it is properly implemented and properly configured. It's built on a fail-saste principle of no access and let it is explicitly granted. Major cloud providers operate global security operation centers which monitor threats and respond accordingly 24, 7, 3, 6, 5 days a year. The scale is much larger than anything you can see at country level. With this, global threats can be counted with relative ease and some never even reach the tenant environment. Additionally, both AWS and Azure are approved for use by any government body up to and including the official protective marking. This is critical and a major step forwards in making cloud and technology platforms more trustworthy versus the legacy area of having to build large complex infrastructures with lots of referential security and a lot of processed. Public cloud also supports an increasingly mobile workforce and aids in the productivity increases that are required by businesses and organizations in public sector the world over. Myth number two, I'm prohibited from using public cloud to store my data. A common argument as well that people can't put data into the public cloud because anybody can get at it or it's not going to be stored in the right way, it could be available in other countries. Generally at the root of this, particularly within public sector is a internal decision at some point that someone has made to say we're not adopting for various reasons. However, any government, department, central or local can use public cloud as is certified and managed centrally. The oversight is maintained by GDS and supported by NCSC, the National Cyber Security Center. With this oversight, data is monitored as to where it is government data and tendencies are located and watched to make sure that there are no intrusion attempts. And this is not only limited to the UK environments. In fact, when this policy was originally put into place, this was built around the two European regions for both AWS and Azure in North and West Europe. The only true legally restricted user until recent times is the NHS. Their legislation that enables the NHS to do its job actually requires that patient data must be within the geographic restrictions of England and Wales and Scotland for the Scottish NHS. However, this does not stop the use of European regions for nonpatient data. And by this I mean appointment making general internal operations. This whole problem is now made somewhat easier with the recent advances of both AWS, Azure and in the last week, Google announcing that they have UK regions available coming online respectively. Now everything is possible to use cloud and put the data in the appropriate place. The only construct is to select the appropriate region for the data, the usage and the audience that's going to be consuming it. Myth three, the cost is prohibitive. Tough area to overcome and the route generally goes towards an organizational board to the CIO, CFO and CEO areas. It's not impossible to overcome there. Fundamentally, this is a drive from shifting from a traditional CAPEX expenditure model to an operational expenditure model. On prem, we generally operate on a three to five year cycle with licensing true ups and we ammortise equipment through the accounting process. Cloud, the billing becomes a consistent month to month bill predictable and with real-time analysis of usage. So rather than the large spikes that we see on the on-premise cycle, we now see a relatively flat run rate which can be accounted for understood and forecast in advance with a great deal of care. Like for like technology platform, operational costs on cloud are lower. Can also be taken even further down by using smart analysis and refactoring from traditional methods of operating applications and data to newer models. So moving pieces from having a full up environment where you are running a virtual machine with software layered on top and your data running within to maybe a SAS or a past model. Myth four, and this is quite an emotional one for a lot of organizations, cloud is stealth outsourcing. Public cloud does not mean an automatic outsource. This is a different world that we're in today that we have been in over the last 20 years. Customer remains in full control with a cloud outsource, a cloud operation. And the tendencies are owned by the end customer but can be operated by the customer or provider on their behalf. They can retain as much management as they like. There are many hybrid models in organization and very many demonstrable points of both singular environments and multi-user environments, multi-provider models out there. It also drives opportunities to develop talent for a new technology world. One of the key issues in society now is the rapid advance in technology and people being able to take usage of it. So with internet of things, etc., developing a rapid pace, cities can take advantage of this for smart usage of lighting or road data, etc. So that covers the basic myths there. So I'm now going to hand over to Maravon Hassel who will take you through the examples that she's worked through at Alesbury Vale District Council. Over to you. Thank you, Mark. Can you hear me okay? Yes, we can hear you. Sorry about the fire alarm earlier. Okay, so yeah, I was just going to talk for a little bit about our journey through to the cloud. We're using Amazon Web Services and Azure and some other clouds at the moment so I'll talk that through. But just a little bit about Alesbury Vale really, which kind of puts the backdrop around why we did this. So Alesbury Vale is just outside the London kind of the ring and Greenbelt and it's a massive growth area. So there's always new homes going in, always additional people come in to the area. And that very much drives from an IT point of view the need to have very flexible IT so that the IT can be there to facilitate all of the things that the council wants to do rather than kind of being held up to hold it back. So if I just walk through. So when we started looking at cloud there was a series of kind of general benefits, some of which Mark has kind of talked through as part of the spilling the myths part. But really it was about actually us driving down some of our costs and understanding exactly what our costs were for. So in terms of the things that our staff used to do, so our staff used to traditionally do they're looking after PCs, looking after servers, looking after kind of physical infrastructure. And actually that wasn't necessarily because of our scale, the best use of their time. So this was about saying actually let's get rid of that, let's move that to infrastructure as a service and get somebody else to manage that piece and get our staff focusing on the bit that actually they can add the most value to, which is about looking after the environment and making sure that it's appropriately sized. So things like dynamic scaling, the ability to flex up, flex down to move things on different servers to see exactly how much everything costs was an incredible advantage from our point of view. The other parts really are around things like improved resilience and staff recovery. So we have staff recovery contracts, we no longer need those. So we actually looked to spread our environment across three different availability zones in Dublin, across the Amazon cloud to enable us if there was any issues for any of those data centers for us to move very easily from one to the other and to provide the staff recovery and backups. The other thing for us was that when we first started looking at this, so we've had a cloud first strategy for probably for about seven years now. And when we first started looking, we were keen to move everything to software as a service, but for a lot of the applications that we wanted that wasn't available. So if I take some of the in-house kind of line of business applications, those software as a service solutions weren't there. So our first step was to move to infrastructure as a service, use the Amazon cloud to set up the physical environment or the virtual environment and then run off services on those. So really kind of driving down costs and giving us that flexibility. And very much from Alice's point of view, this was a hardware strategy which was around providing that agility so that we can very clearly switch things on, test things out, and switch things off when we don't need them anymore. We had got to ourselves to a point as well where very much on the kind of CAPEX, OPEX model, where every cycle that comes around, we have to then refresh the physical kit. There's a significant investment associated with that. If we don't know exactly what we're going to need in five years time or in two years time, what we don't want to be doing is investing in the wrong kit because then that ties us into it for the long term. So the ability to actually use that virtually on somebody else's environment is very powerful for us. It also meant that we didn't need to create extra storage. Storage is a very easy thing to utilize from a cloud point of view. And actually it actually saves internal time just in terms of the things like the procurement processes. So as any other council, we have very interesting procurement processes that sometimes take quite a while. And this enables us to very quickly flex up and flex down in terms of the capacity that we have. We also had a perfect burning platform for my point of view. So we had moved to physical offices several times. We had a data center within one of our physical offices. We moved. We had to move to the data center. We moved. We had to move it again. We then thought actually what we'll do is we'll use the county resources to host that force, which is great because they won't keep moving. So we moved our data center into the county offices. So this is Box County County County Council. And then they actually decided to close their offices as well. So that was a bit of a problem. So we took that as an opportunity. Look, we need to stop doing this and we need to move. We also wanted to provide that visibility of the costs associated with each application. So from an IT point of view, what you often get is kind of like a monolithic. The whole service costs a certain amount. And it's very hard to attribute to individual services the cost of running those services. By actually breaking that apart, we were able to create an environment where we could then see each application and the costs associated with that application, which is very powerful in terms of making business cases about what we should do next. So we then had a bit of a conversation about, okay, so we know that we want to move to the cloud. Which cloud do you want to move to? And we did quite a lot of evaluation of this. We looked at the public cloud that's available. We looked at some private companies who would host things for us. We looked at whether we could just go to software service for everything. Most of our focus was on the Amazon Web Services viewer question. At the time that we did the evaluation, we did the sizing exercise to look at what we actually needed. From our point of view, Amazon Web Services was a better cost profile for what we needed. So we chose it primarily from a cost basis. And then kind of kicked off the project to move down through that. And then if you like, it was a very traditional project. So the spreadsheet top right is a very detailed spreadsheet of all of the different services that we've got. And for every one of those, we worked out what was the physical environment that was currently on? What that would equate to in the new world? So what would the instance be, the sizing, the type of server that we would need in Amazon? And we went through very methodically and worked out what all of that would be. And created a master plan. We used ARCUS Global to support us in the initial pieces of the project to help us to do the design work, to set up the network. So there's a lot of work around actually how you create the network from ARCUS, alluding earlier to some of the security aspects. You have to build those in. So you have to understand how you want things to be secured and therefore what the network should look like. So we designed all of that. And then we had to look at really what applications we wanted to start moving. And we moved some of the bigger ones early on to see what that would be like. So we moved our parking application fairly early on because it was fairly standalone for us. And then we started moving things like our network drives. These things all required quite a lot of work. So network drives a lot of data to move. So we had to set up some processes whereby we could replicate. And actually those jobs ran for over a week in the end of replicating the data up. And then we ran in parallel mode for some time. And then we ran view only for the on-premise environment and for all the users to move over. And then we actually cut over to Amazon. And I think what came through for us very strongly was the whole thing about testing. As we kind of stepped through the process, what we found was that things weren't always as we thought they were going to be. So some of the things that we thought was going to be very simple turned out to be more complex. There were bits of integration that we didn't know about that somebody years ago that meant that when we moved things, things broke. So we had to keep trying things and then rolling back and then trying again. And we did that several times. We iterated around. And we realised that actually that was quite a good approach for us. So we would do it and then roll back. Do it and then roll back. So we got ourselves to a point where we could do it more effectively each time. And then the picture around the climbing really was very much you kept thinking we were there and then you'd find another something that you had to do so that it was a bit of a mountain in terms of moving over the services. As we worked through the process we developed a methodology for doing it which enabled us to do it in a much quicker manner as we stepped through. Just to show a little bit around sizing and what this might mean. This was just to look at from our point of view the virtual environment that we set up in the first place. So I've kind of got the go live column with the different types and sizes. And also to kind of talk a little bit about how our journey's been, which is one of the great strengths of Cloud. So when we went live we had eight microservers and 16 small ones and all these different things. And actually what we didn't know until we actually went live with it was that that wasn't always right. And one of the really important things to do is to continually monitoring the sizing of your environment to make sure it's right. And that's what you use your staff time for. So have we got those applications running on something that's appropriate? Is it big enough? Is it too big? Where can we optimise and trim down? And we did quite a lot of trimming down exercises to reduce the scale of things or moving them to different types of servers to assist with that. And then what we've also been able to do over time, as you can see from the numbers that have gone down from the original go live to today, is actually start switching off and moving other services to software as a service. So it's really facilitated our agile move to moving everything to software as a service. The tools that come with it are fantastic in terms of monitoring what's being used, checking the cost each month. You can monitor those and then kind of flexing up and flexing down. And the other big thing for us is availability. The availability, I think we've had one issue in the four years we've been there that was only for half an hour. So the availability has been phenomenal, much better than anything we could have ever provided in our previous environment. In terms of lessons learned, from a staffing point of view, what we found was, obviously, that we needed to retrain our staff. So rather than running down to the server room or driving up the server room to physically fix the environment, they needed to learn the whole new toolset that was available as part of our services. And they did need to manage it. So we had lots of initial excitement about, well, it's fantastic. I can just spin up a test server here, and I can replicate this environment over here, and I can take as many backups as I like snapshot, and I can store those for however long I like. And when we went live, our initial costs were starting to go up and up and up. And when we reviewed that, it was because it was so easy to switch things on, people were doing it everywhere and then not switching things off. So we had a lot of work around the kind of sizing and around exactly what was appropriate at any one point in time. The other big thing for us was around the staffing. So general staffing in terms of people using these services. So internally, we had a lot of concern about whether it was okay to move all our data away from something that we could see to the cloud somewhere. So we had a lot of internal work to do to win people over, and then to take them on the journey with us because things were never quite as we had hoped. So for example, some of the applications would run a bit slower. So then we needed to increase the size of them and test them again. And we invested quite a lot in our staff in terms of running test days, doing lots of promotion internally to help them to help us to kind of move forward to make them feel excited as part of it and kind of pushing the boundaries in terms of what the council is providing. The other thing that I mentioned earlier really was around the network side. So there was more network work than we had anticipated, if you will, virtual, but that also, we needed the skill set to be able to do that. And we used partners to assist with some of that. But there was no silver bullet in all of this. This was very much from our point of view a trial and error and taking people on that journey with us. In terms of our next steps, so we are continuing to look at what we want to do next with each of our applications. We're continuing to invest in Amazon Web Services, but more in other spaces. So we're looking at things like Alexa and utilising some of the AI capabilities that Amazon has, and we've been doing some discussions and trials with them around that. We do currently use Azure. We use Azure for some of our authentication processes. We may use it for some specific services going forward, but we won't move wholesale to that. We are investing heavily in the Salesforce Cloud. We are putting more and more applications on that and connecting those together, trying to create a much better internal experience, both for our staff and for our customers so that everything works in a consistent manner. And we're looking to ultimately go for a complete server-free, including virtual servers, software-based servers, browser-based access to all of our applications, both from a customer and a staff point of view, which will also enable us at that point to remove our network. So that's our next five-year strategy, and that's what we're working to, and continually reshaping what we have. So hopefully that kind of gives you a bit of a summary of what we've done. I'm happy to take any questions. That's great. Thanks very much, Marilyn. I'll just take a quick look at the questions on the poll here. Okay, so what difficulty did you have in getting buy-in from across the organisation for this transformation towards public cloud? Quite a lot of the ones that you raised in the first place, really. So we took it through our information governance group. We talked about the data, where the data was currently, where the data was going to be around the security implications of that, so actually where we believed it was safer, and then we got them to buy into the process that we were going through, which helped enormously, obviously, if that was essential, for then getting the buy-in with the rest of the staff. I think the problem for the staff, when we actually did this, it was fairly early on in the process. They didn't know of it. They didn't really know what it meant. They didn't really understand the idea that we'll update their desktop, so we have Citrix and Think Client, so their desktop, they're actually working in Dublin, was a bit of a strange thing for them. So we did lots of testing, lots of, let's give it a go, see what you think and make sure that you're happy with it. So lots of engagement. Okay, so if you had to go back and start again, what would you do differently? I think there's some of the bits that we would definitely do in the same way, but I think we would probably spend more time in the design, and also I think we would probably signpost a bit more of the trial and error kind of nature of it. So I think people expected that we were going to flip over and it was all going to work, and that was always a very tough ask, really. So perhaps positioning more around, we're going to, this is going to be a journey, and we're going to kind of step through this in a controlled manner, because what's really, really important obviously is to protect the data, keep the business running, and we're not going to do anything foolish or too quickly through that process. Okay, brilliant. So if you were giving advice to another local authority about having to go through the very similar process, what would be the key pieces of advice you'd give them? I think for me it definitely can be done, and if you haven't done it, why haven't you done it? I think it's liberated us, so I think it's a definitely spend the effort to get the buy-in. And I think you have to do it top-down, so I think you have to get your senior team to understand what it all means, what it will mean for them in terms of delivering the services that they want. So this isn't about IT for IT's sake, this is about enabling the services to flex up and flex down in a much more agile way. If they have more staff coming in, it's really easy just to get some more licenses and have some more staff. There's not a physical constraint that they're going to come up against, so I think I would spend the time investing in the kind of senior team. I think the other big area is the IT team, so we I think perhaps have slightly underestimated the amount of change that it would mean for them, and I think obviously they're key to the whole program. So perhaps more training, perhaps more hand-holding, perhaps a little bit more support with them through the early stages. What we have found since then though is obviously they absolutely, they're on the why didn't we do this sooner, but actually trying to get them through that was actually quite tough. Okay, we've got a question from the webinar here asking about the size of your user base and how you operate your connection to AWS? So we have about 450 staff, so all of those staff are using Think Clients, Citrix, Environments, so their desktops are running from Amazon Web Services. We also have obviously 100, we have 180,000 residents in the Vale, so they are using self-service access to services that we run, actually run those through our Salesforce cloud, so they're utilizing those not with those users at the same time. So and in terms of connecting to Amazon, what we've actually done is we've put in a direct connect, so a physical, not physical, virtual connection between the two environments, so it's part of our internal network, so we've actually, does that make sense, so we've actually, I'm drawing, you can't do drawing here, and we've extended our perimeter to include Amazon, so our perimeter is, doesn't just include that. So I am an environment, counts as part of our internal environment, so for things like Pearson compliance, when we draw those pictures, that's part of our internal environment. Okay, that's really useful context for people. So we've got a question here, which is examples of IoT on AWS. Do you have any IoT on AWS, Mervon, or? In terms of, in terms of AWS at the moment, the biggest thing we're doing that's not about service is the Amazon, is the Alexa work. So you could argue that kind of connected up the internet, but we're not doing monitors and sensors. We are looking to do that next, so that is exactly what we're talking to Amazon Web Services about. So hooking up the internet, hooking up home devices, residence devices to provide services for them in their homes on the back of what we've implemented internally. Okay, and I'll just put a bit of extra colour around that. So there's some city projects that are going on at the moment, which are connecting, you know, multiple things at the IoT sort of level. So everything from smart street lighting, operating in a more intelligent fashion rather than just a sensor that tells them when it's getting dark and then subsequently turning off as the sun comes up in the morning, smarter usage by detecting road usage and shutting down traffic lights and things like that, to looking at tidal flow traffic for street planning. Some services are also extending things like their home help environment. So with a panic button that people press, instead of having that depending on a phone line, it's actually talking to a mesh Wi-Fi in an area and is treated as an IoT extension. So there's many, many examples by IoT, which is a field that's developing at a pace faster than we saw the original sort of public cloud development. And if you look at some of the examples, particularly in the US around, I think it's a city of Chicago are pushing a lot there. And also there's a project underway in New York as well, which are probably the two big key ones. And one of those is AWS, one of those is Azure. So it will give you a good set of context as to the two different providers. Okay, we have no other questions on the call. So I think at that point we'll bring it to a close. Marivon, thank you very much for the insight that you've given us into Ales Revealed District Council. And good luck with the next steps as you take that forward and evolve more. With that, thank you all for being on the webinar today. As it closes, the recording links will be going out. So feel free to play those back. And thank you very much for your time.