SharePoint Saturday Cambridge 2016 Session
•Download as PPTX, PDF•
0 likes•494 views
My session about Extending Office Add-ins with the Azure Container Service
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
Similar to SharePoint Saturday Cambridge 2016 Session
Similar to SharePoint Saturday Cambridge 2016 Session (20)
More from Rick Van Rousselt
More from Rick Van Rousselt (17)
Recently uploaded
Recently uploaded (20)
SharePoint Saturday Cambridge 2016 Session
- 1. Extending Office Add-ins with the Azure Container Service Rick Van Rousselt SharePoint Saturday Cambridge
- 5. docker and containers - Ligthweight, open secure platform - Simplify building, shipping, running apps - Shipping container system for code
- 6. Virtual Machines Each Guest OS needs: • CPU • RAM • Licensing • Maintenance
- 7. Containers • More room for apps • Lesser maintenance • Licensing
- 9. Docker Engine Docker engine Docker engine
- 10. • Blueprint or definition of a container (readonly) • Needed by docker engine to create a running instance of a container • Can consist out of multiple layers Code Node.js UbuntuImage Images
- 13. V1 V2 V3 Why use containers Eliminate app conflicts
- 14. DEV TEST PROD Why use containers Easy app shipping
- 15. It’s just easy for us developers • When joining an ongoing project not need to do a long setup for a developer environment • No need for heavy virtual machines • Development environment is almost the same as production Why use containers
- 16. The SharePoint Context Why use containers
- 17. Connecting to Office 365 groups from a container Demo
- 20. What is the Azure Container Service - Optimised for hosting containers - Easy to manage containers at very large scales - Docker swarm and DC/OS included - Open source
- 21. DC/OS vs docker Swarm • Large scale • Proven in production environments • Complex • Native from docker • Standard docker interface
- 23. Overview of the Azure Container Service Demo
- 24. What’s in it for us
- 26. If you have any more questions Email : rick.vanrousselt@outlook.com Twitter : @rickvanrousselt
Editor's Notes
- My name is rick and i am an office 365 sharepoint consultant. I”m currently focussed on o365 and azure. If you want to contact me please reach out to me on twitter or just send me an email
- Now lets have a look at the agenda. First we will have a quick look at what are containers and how does docker relate to this Then we will go over some of the details why we should start using docker and containers After this we will start exploring the azure container service or ACS for short We will end this session with some examples how we can use containers in combination with office add-ins
- Let’s take a look at docker and containers Docker itself is lightweight open secure platform. Now this itself means not that much… but it simplifys building shipping and running apps. This means that moving between different environments like from dev to production is made easy. Docker does this by providing a shipping container for our code. The most used analogy when talking about docker containers is comparing them to shipping containers. Back in the old days hey had different sizes of cargo. Big and small crates of different sizes. It took forever to load the ship… now standard containers and ships get loaded really fast. Now let’s compare them to something we all know… virtual machines
- We will start at the bottom with the fysical infrastructure. By this i mean the actual hardware. The server, the cpu’s, the ram, the disk,… On top of this a host operating system will be installed. This operating system will also have some kind of hypervisor. This enables the virtualisation. I think we all know ESXI by vmware but there are lot’s of vendors on the market. Once these parts are installed we can start creating our virtual machines. They need an operating system. Because i”ve been focussed on sharepoint for quite some time now this is usually just windows server. Then on this operating system we will install our needed files. Our dll”s for our frameworks and such. This would be sharepoint then… and lastly we would install our app. Each os needs cpu, ram, licensing and maintenance
- Now lets look at this picture from a container standpoint. We still have our infrastructure and our operating system. But on this operating system we can now install the docker runtime. This will allow us run our containers. The containers wil share the files of the host operating system and if needed some of our framework files. This means that because a few layers our now out the picture we have more room for our apps. Aka we can run more apps on the same hardware. Also lesser maintenance is required because no care is needed for every operating system in every virtual machine and of course in a windows world this also means no extra licensing cost for every VM we spin up.
- Docker has a few major components… Docker engine or deamon or runtime… this is wat gets installed Docker images… these the blueprints of our containers And then finally we have our containers… now lets take a closer look at these components.
- Docker engine is responsible for running our containers… actually it does a lot more but for now lets just say it runs containers. This means that if we have the docker engine running on our laptop and we create a container… then we can run this container wherever we want… lets”s say in azure
- An image is a blueprint of a container. These are readonly and needed by the docker engine to spin up a container. They can consist out of multiple layers. Lets take for example we write a node js website. Then we have our code. Now for this code to run we need node installed and for node to be installed we need an operating system. So we create an image where are these layers are stacked on top op each other. A container can now be created from this image on our dev environment but also if needed in our production environment
- A container is a running instance of an image. This actually holds the app and runs it. It’s isolated and secured. This means that it cannot write to the host file system or other containers
- Why should we use containers. Wel first and foremost we can elimate app conficts. Lets say we have version 1 of our app build. It has its own dependencie on a framework that we use. Well then we can easily create a new container which has a dependency on a newer version of that framework or even a 3th version. All these containers run in there isolated environment so we have no issues running them next to each other. As before when this would be installed into a virtual machine when one app needed to upgrade a framework that it used then other apps also needed to upgrade because they would all share that framework.
- We all have been in this situation. We develop an application and it gets tested. But when it’s time to deploy it to production it’s not working. This can be because something was not installed or because something was not configured correctly. Because the containers are created from images they only need the docker runtime. All other dependencies are documented in the image. So when we create our container on other enivronments we should have no issues. Becuase the image gets rebuild and it gets the required files for us.
- Well as a conclusion we can just say it’s easier for us developers. You know the drill when joining an ongoing project. First you need to setup you’re development environment. This usally takes a lot of time. You get a clean virtual machine. Then you need to install you’re visual studio. Then all the frameworks.. Then you need to configure everthing so that you have at least a working version of you’re app. And after all this is done… it”s still not even close to how the production environment is set up and configured. And then the next day the previous project has a bug in it and you need to start up you’re old vm that you just removed from you’re laptop. So the process starts all over again. With containers we can simply pull the images start up the containers and start coding.
- Now what does this all mean for us SharePoint and O365 developers Well remember the good old days.. When we created farm solutions and when we had full control over everything. Well those days also had there drawbacks… Who didn’t have a server in production struggeling because we didn’t dispose properly of our SPWeb. Well a few years back microsoft said this can be no more and the app model was introduced. This entailed that we should now use csom and that our app. At least the provider hosted apps or office add-ins now don’t need to run on a sharepoint server. This set’s us in an excelent position to make the switch faster to containers. Especially for those who develop against office 365 because there we already need to bring our own hosting environments.
- What does this all translate to … that we can ship software faster. Which is always a good thing especially in this rapid evolving world of today
- The azure container service provides us an easy to use way into deploying and managing containers at a large scale. We can quickly set up a cluster of nodes in which containers can run. Normally if we want to set up a node cluster there is a lot of configuration and setup required. Now this all will be taken care of for us. What normally takes days to accomplish can now be set up in 15 min. We can easily scale our cluster environment thru existing azure parts such as virtual machine scale sets and vertical and horizontal scaling of virtual machines. The Azure team has made sure that they only implement open source tools such as docker swarm and DC/OS. This will ensure that you can not only turn to microsoft if you need help but that you can just ask the community. Or if you fix an error or you enhance the software that you can contribute it back to the team
- When creating an Azure container service we have choice. Will we use the DC/OS orchestrator or the native docker swarm. They both have there benifits and drawbacks. DC/OS is new to the party. It just got released a few weeks ago. First we could choose between mesos and docker swarm. Mesos has now been replaced with dc/os. But DC/OS is build on top of mesos. It’s designed to scale very large clusters involving hundreds or thousands of hosts and has a proven track record. But its a complex solution. On the other side you have docker swarm. Which is the native orchestrator that docker offers. This has the advantage that it runs almost the exact same commands as docker on my laptop. But this can also be a disadvantage. This means we need to know our way around the command line tool. And because it’s not been around that long it doesn’t have the trackrecord dat DC/OS has.
- Now… let”s be honest. I am a developer and so are most of you probabely…. I am not qualified to run a production environment node cluster with datacenter orchestrators… So why should i even care that something as the azure container service even exists… But that’s the beauty of ACS. If you manage, nurture and care for it then it can be used in a production environment. But we as developers sometimes just want to test stuff out.. How does our app behave when we scale it,.. Wat happens if we change this or that parameter. Wel ACS can provide us with this. We can easily spin up an environment ourselfs… start up our app or if we have them.. Multiple apps and start testing away… All of this without much configuration or even installing a single item.