dmj

Any lamp web service would be a safe bet, but also RADIUS, auth servers, DHCP, DNS, file shares, mail relays. Where you'd get unstuck is with the monolithic applications like SIMS - but it is conceivable to do these to (external DB, seperate samba file shares etc) if you were willing to forego Capita support - so it's probably not worth bothering with.

Yes it does. As with virtualization was in its infancy, not all services are great candidates for containerization - sims, for example is a no hoper! Larger services can be subdivided into small containers and all run inside a single pod using the same address space. It does take some thinking about and as with all IT there is never a single way of doing things.

My last school moved multiple services to cloud (Google Compute Engine in that case) and here I'm working more with Azure and AWS. Previously I had moved over web services, domain controllers, redundant DHCP and the like. From my experience it is a mistake to do a wholsale lift and shift - it is too costly. The reasoning is that most services run at full load during a working day and then have virtually no load during holidays and nighttime - but they still need to be available and cloud providers charge by the minute! The technology that works around this dilemma is containerisation coupled with a platform such a kubernetes (which runs on Azure AKS, Google, AWS and on-premesis) to manage the containers. The idea is simply that you run the base minimum of kubernetes servers and as your load increases you automatically deploy more nodes and then kubernetes scales out your applications to take account of the load. I have a few test machines, mostly with web services and it is working quite nicely although I am not sure when we are migrating the load off premise onto azure/aws/google. Ideally we'd like to be able to switch between platforms with relative ease. The general strategy is: implement a logging and hyperconverged filesystem infrastructure Work out which services lend themselves to containerisation and then implement it. Make sure to build the containers in an ephemeral way so they can be created and destroyed without data loss. Run kubernetes on premise and get a handle on managing the containers move the containers directly into cloud providers The really nice thing about ephemeral containers is that you can run preemptible vm's (I think they are called spot instances? in azure) - they cost 80% less than a normal vm but might get turned off as the cloud provider needs the resources - but it doesn't matter because kubernetes will just reschedule the load elsewhere and your service won't miss a beat !

Vault does keep modified files. I don't see why you would need to add another backup system? Our setting is: "Keep files for 90 days from when they were last modified. After expiry, expunge files that have already been deleted." (deleted files are recovered from the file recovery dialogue)

oh - I should also mention that you can force chrome sign in using the ADMX policies in AD but it's not automated.

It is possible to do SSO with windows /gsuite, but you would need to link your GSuite accounts to a single sign on mechanism such as ADFS (this works on Chromebooks too). I've not found another way to do it, or how to do this with macos/linux clients*. - but would be interested to hear if anyone else has experience. If you go down the saml/ADFS route it means you would have to use Active Directory as your only password store, so you don't get some of the advantages of storing passwords in Google (such as LDAP) and have another point of failure - so it is certainly not a panacea. Once users authenticate to windows the credentials are passed through to ADFS which then automatically logs you into GSuite. as a pointer see: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-browser-wia * edit: this may solve the mac issue using shibboleth https://wiki.shibboleth.net/confluence/display/IDP30/SPNEGOAuthnConfiguration - I am not sure. Another option would be for you to store the browser cache in a roaming profile so that users only need to login once.

My thoughts are that the best way for redundancy AND disaster recovery is to segregate the server data from the server configuration. Every production service that gets deployed has the configuration written as code which is then stored in version control. The data is backed up and stored separately. This has a few advantages: because the config doesn't need to be applied manually, the servers can rebuild themselves. As the servers as ephemeral they are pretty much designed for load balancing from the outset. It's really easy to see who's made a server change by looking at the git history!

Isn't that just describing a paging system that has been in windows for the last 30 years?

If you don't want to build it yourself there are a number of online IDE's , many of which provide educational discounts and will link into your Google/One drives and authentication systems. https://codeanywhere.com/pricing The Computing department may be able to get a budget for this.

We are currently looking at Mimecast but it is quite expensive. A cheaper option might be to route email through Google suite as they have some quite good spam filtering (I think it is called postini) and they don't charge for it.