 Welcome everybody to this session on server considerations. The learning objectives for this session are to be able to describe the high level DHS to architecture. Understand the pros and cons of different hosting options. And importantly to understand the skill set is required to maintain DHS to. We also describe the routine activities of what the DHS to back end administrator does. And lastly give some tips around how to create a plan as a host. Again with let's try to understand a little bit more about the DHS to architecture itself. The DHS is a web application, which means that people access it through a web browser and can be set up quite simply using using a piece of software like Apache Tomcat to host the DHS to web application. And that in turn uses a PostgreSQL database back in reality setting it up in a production setting. There's quite a lot more to take into account than just this. Let's delve a little bit deeper. DHS to architecture. So the DHS to software that is to be hosted somewhere on some physical machinery in order to actually work installing DHS to because it's a web application. These are much more complex exercise than simply installing something like Excel software on your laptop. There are multiple components involved and also a single DHS to system may involve multiple servers, not just one. For example, very commonly the database might be set up on a different server to the web server. Our country's DHS to implementation will also most likely include multiple programs that are actually run on separate DHS to systems hosted on different servers. It's quite easy as we saw really in the previous slide to make a DHS to system run, but to put it together in a robust and scalable and manageable and secure way requires quite a lot more. Importantly, it's not just about the technology. Human beings are needed to manage it to install it, etc. We'll talk a little bit about some of the skill sets required in subsequent slide. So thinking a little bit architecturally about how you put your DHS to system together. There are some considerations to bear in mind. The application is typically going to need to be continuously available 24 seven with very little scheduled or unscheduled downtime. The data it will hold is valuable and potentially it's also sensitive from a privacy perspective. Large sites may have tens of thousands of users and often millions of records. The system needs to be actively maintained and updated, sometimes over over many years. All of the above give rise to some quite complex requirements regarding physical infrastructure security and performance constraints and a broad range of technical skill, none of which are immediately visible. When viewing the simple software architecture that we showed at the start. It's essential that the server implementation is properly planned for when an implementation is in its planning stage, in order to be able to mobilize the physical and the human resources to meet these requirements. In this section, we're going to talk about different provisioning variations or where to host your system. One of the first variations that people often consider is hosting the server locally. This is sometimes referred to this a little bit tongue in cheek as having the server in the basement. Here, we're describing a situation where the server is installed on sites to be in the Ministry of Health building alongside all the offices and everything else. Often it's in a repurposed room like a storage room or the like. The reason why people do this and the pros I suppose is that it gives the system owners the most direct control over the server resources and data, but has a number of disadvantages. The first is that it requires probably more skill to do this to design it to install it and to manage it than some of the other models we discussed below. They're quite high startup costs in terms of buying servers, buying network equipment and importantly preparing the room appropriately. There are numerous physical challenges which need to be addressed. The common challenges that we've seen problems with continuous power right servers that are affected by a power supply that goes on and off frequently during the day, both affect availability but they also do longer term damage to the equipment themselves. Road and control is something that's often not considered but rats and mice tend to have quite an attraction for server hardware I think they enjoy the warmth of the motherboards and they enjoy eating the fiber optic cables and they can be a major problem. Water and ventilation management can be difficult. We've seen cases where server room has been installed underneath the toilet block for example so the possibility of water leakage and things coming in. There's a lot needs to be done in terms of air conditioning and using the right type of air conditioners physical security is obviously a challenge that needs to be looked at in the architectural design of the room. 24 seven access to the building is often difficult where the building is is normal office building. Very often we find that it's possible to get into the building between office hours and after office hours getting access can be really quite difficult. If you're maintaining a system 24 seven, all of these factors make it a little bit challenging because of the costs and the risk involved in doing it this way. We would really not advise going for this particular group variation on the same would be having buying physical servers but hosting them somewhere a bit more appropriate in a converted cupboard. It's quite common increasingly common I suppose for for ministry or even national government to be building their own national data centers or ministry wide data centers where all the environment controls are in place. Ministry of Health applications would be hosted within such purpose built data centers often managed as a cross government service. This could be taking physical servers hosting them in the data center that's a model is referred to as co location, or it could be running virtual machines within the national data center. Some pros of this approach is that often this is aligned with national policies around data sovereignty and particular, particularly a concept known as geo location of data, but essentially government requires that government data is kept within the geographical confines of the country. Ministry of Health doesn't need to maintain the server infrastructure directly. And this is a huge advantage because it means all the management of the network and looking after faulty hard drives and things like that are outsourced effectively to someone else. All that's really required from from ministry perspective would typically be the system administrator skills to actually set up and run the DHS to server. There are some drawbacks and cons to this one of which being that the cost is typically higher than doing then using cloud hosting providers. Not always the case, but typically find that it is if you're using a national data center or a national company that's hosting virtual machines for government. In terms of economies of scale, they've got a much smaller client base, let's say than the likes of Amazon or Azure or Lin node, then the costs will likely to be higher for holding virtual machines or co location, quite dependent in this case on the skill level infrastructure of the data center team itself because this is now no longer under your control. And in many cases, we find data centers are really very well run in other cases. It's not necessarily the case often there are bureaucratic layers to go through. And often the infrastructure that was installed about six, seven years ago was not being refreshed. They cannot always assume that the infrastructure is exactly the way we would like it access to services as it can sometimes be hampered by bureaucratic processes. In terms of, for example, if one needs a new virtual machine spun up or running a test instance, if you are using a cloud service, typically this would be a few clicks. So if you're going through a local provider which doesn't have the same kind of client focus infrastructure, it might require memos and a little bit of backwards and forwards is not quite as flexible. The other thing is we often do see performance issues in some of these setups in cases where the ministry of government has sufficient technically human resources and infrastructure. So the third option, taking into account some of the pros and cons mentioned above, probably the most common variation that we see performing quite well is using the cloud in a model often known as infrastructure as a service where essentially ministry will be setting server resources from one of the global providers such as Linnode or AWS, Contabo, Azure. There's a number of options out there. The way this would work is Ministry of Health as an account of the cloud company and it pays for the use of server resources, typically build monthly, but sometimes arrangements can be made to prepay a year in advance. On the budgetary mechanisms that are available. A few advantages to this approach is, first of all, I think it's usually the most cost efficient. The most cost efficient way is going to cost less, typically to run your DHS to server this way. It can provide better performance and reliability often the earlier two options. And in terms of skill sets, you no longer need to have all the skills required to manage networks and surrounding infrastructure again only system administrator skills are required. The big downside or disadvantage I suppose is that the cloud is structured in such a way that typically clients will pay with credit card it's a very agile sort of model. And often the payment, the way the payment works for the cloud is not a very good match for typical Ministry of Health procurement processes that they can be budgeting challenges for recurring payments we've seen situations for example where the government has set up their cloud account and paid for maybe a year's hosting in advance. But when the year comes to an end and the bill becomes due again, it's not being budgeted for in advance and a mad scramble ensues to get the money and often many cases we've seen where service has actually been interrupted because the cloud provider will switch you back on again when you start to pay the bill. As most the cloud services work on a credit card basis, some of the providers one can negotiate direct debit payment and we've seen that in a few cases we can give advice on that. But credit cards typically not very good match for government procurement UI does have a relationship with some of the providers, for example, Lin node that allows countries to pay up front with wire transfer and this can make it a more viable option. The other variation of provisioning using the cloud using a model known as as software as a service, something called SAS. In this model, and there are a number of companies that offer this including BAO systems blue square is South Africa. In a model like this ministry again has an account with it with it with the commercial cloud company, but the company in this case doesn't offer virtual machines which you need to administer yourself, they would offer DHS to as a service. The advantage of this approach is that it provides that the provider manages the system setup and the administration, which means there's a cost implication there you don't need to employ a system administrator. Also, most of the security concerns would be handled by the provider. There are service level agreements that you can agree with the provider around performance and stability of the system. There are some disadvantages as well. It's more expensive naturally to purchase software as a service and simply purchasing infrastructures as a service, though that does need to be offset on the savings you're making in not employing system administrators. There are potential payment challenges and budgeting challenges as before, as you are still dependent on having a cloud provider to which you're paying monthly or bulk payments to. So similar to the previous mode these services also require regular recurring payments to the service provider. And so management processes need to be in place to manage the budget and to ensure that the bills are being paid. This slide is provided as a brief summary of the sections we've discussed in the slides above. The idea of laying out in a table like this is that it might be useful as a tool for you to assess different options that are available to find what suits your environment the best. As you can see for each option which is which is presented in a row. We have taken into account that there are more factors than just simply the costs of the skills that are required to operate a particular type of setup and some thoughts about security considerations in each case. When it reflects on those four different modes, one of the things that should strike you is that often the way you make your decision is not necessarily based on the technology that you have, but also around the people skills, the human resources that are available to you. Most of the challenges in fact around hosting are actually people challenges. You need to ensure that you have people in place who have the skills and knowledge required to manage a DHS to implementation. As we mentioned earlier, a typical DHS to implementation is quite a complex arrangements. One recommended approach to making provisioning decisions is to look at what skills of people that you have available to you and determine your decision on how you're going to start out hosting based on what you have. Some questions that could help you evaluate the readiness of an implementing organization. If you're going to outsource to for technical assistance to an organization is what projects have they supported before. Do they have experience dealing with DHS to which DHS to implementations. Have they dealt with do they deal with currently you should ask them how they set about their installation and how whether it is automated or whether they are doing it on an ad hoc basis. And you need to assess do they have the appropriate skills to actually do what they claim they're going to do. You can see, for example, some of the system administrator job description that we include below.