So you have decided what you will write your application in, both backend and frontend, you have decided where you will store the source code and how you will track issues, you have figured out your authentication and authorization solution, all that is missing now is somewhere to actually run the application so people can use it. In the Domino world this was a simple solution, just put the NSF on the server, but when you leave the Domino world it because probably one of the hardest decisions.
First you need to know ‘HOW’ the application runs. If you have decided on Java for the backend then how does that run, do you deploy fat jar files that contain Tomcat web servers? Do you use skinny jar files that need to be deployed to an application server like WildFly or IBM Websphere Liberty. Using .NET then maybe you need to look at an IIS Server. What about the frontend? Where does that run do you need a server just for that or will it run on the servers the backend code is running on?
Then you need to ask if you will be running this all in-house or using a cloud provider like Azure, or Amazon Web Services. Do you use a container system like Docker or CloudFoundry?
At this stage you probably wish you could keep Domino around….
Because we decided to use Spring Boot we started looking at Pivotal CloudFoundry as our deployment solution but ultimately found that to deploy a Cloud Foundry solution on our Azure infrastructure might be very costly, it involved about 50+ VMs, additional cores and the Pivotal consultants we contacted really didn’t seem too interested in our business unless we were going to spend upwards of quarter of a million…
Next we looked at Docker. The best way to ‘think’ about docker is that you have a server which is the Docker host and then on that you have Docker containers which could be described as mini virtual machines, technically they aren’t but it is easier to think of them that way starting out. Docker on it’s own is just a technology stack just like HTTP is just a web stack. To make it useful you also need to look at Container Orchestration. This is the layer that manages all your Docker hosts and Docker Containers.
Orchestration layers include Docker Swarm (built in to Docker), Kubernetes, Apache MESOS and Cattle to name just a few. Cattle is one you may not hear of by that name but you may hear of Rancher. Rancher is the UI to Cattle but Rancher can also manage Docker Swarm and Kubernetes and it was this capability that draw me to looking at it. Rancher can also manage multiple environments so if you have a set of Docker hosts dedicated to your QA environment and a set of Docker hosts for your production environment then Rancher can keep them all separate for you.
So as you probably guessed we decided to deploy our applications using Docker containers running on Docker hosts which are running in Azure VMs using Rancher/Cattle as the orchestration layer. This turned out to be a great choice as we could then tie it all back in to our Microsoft Visual Studio Team Services build and release system which I’ll discuss in later posts.
Dec's Dom Blog 