Containers are isolated application images from the binaries to the file disk. They are isolated in that they virtualise only the application to a specific OS. They are a great solution when you need to lift and shift applications quickly into the cloud production environment, and you don’t have time or resources to rewrite, or refactor the app code to make it ‘cloud native’.
Containers offer an alternative approach to server virtualization
- Containers are fundamentally different & largely complementary to VMs
- Containers are application and OS specific (light) and are isolated guest VMs within a virtual layer
- VMs are virtual images of the entire Server and Server resources (heavier)
Dependence on a single OS can make container-based virtualization less versatile than conventional hypervisor-based virtualization.
- Install a host operating system (OS), rather than a hypervisor
- Install virtualization layer as an application that runs on the underlying operating system
- Within virtualization layer – each container can run its own application — or copies of the same application — but all containers share the same single OS kernel
- Can also download pre-made images from Docker Hub (Rocket, LDX, Microsoft)
Key difference between VMs and Containers is the minimalist implementation offered by Containers
- Containers don’t need a full OS to be installed within the container, and they don’t need a virtual copy of the host server’s hardware
- Containers are designed to function with minimum resources necessary for tasks (eg. few pieces of software, libraries and the basics of an OS)
- This results in two or three times as many containers being able to be deployed on a server than virtual machines
- Portable across the same OS eg. Copied into dev-test-QA-integration-Pre Prod and Prod environments, aiding SDLC
Above ensures security since underlying OS will be the same in each account/environment
Containers: Same idea as Open Source & Java containers eg. EJB, therefore not a new paradigm
- Easy to deploy; can be secured and offer a specific implementation of infrastructure requirements; also offer an alternative to virtual machines.
- Within Cloud the key factor is that Containers are designed to virtualize a single application — e.g., you have a MySQL container and you provide a virtual instance of that application (only, nothing else)
- This means that Containers create an isolation boundary at the application level (not at the server level as with VMs)
- Isolation entails that if anything goes wrong with container (e.g., excessive consumption of resources by a process) will only impact the individual container and not the whole VM or whole server.
- It also stops compatibility problems between applications that reside on the same operating system (OS)
Downside: Containers could involve splitting your virtualization into lots of smaller parts
- The more containers, the more difficult to manage (Docker etc have management tools)
- You will need to deploy patches to all of the different containers
- Managing security and patch updates needs effort and can be complex
- Container orchestration tools can offer scheduling and clustering (scalability vs loads)
Virtual machines are generally considered easy to manage, primarily because there are significantly fewer VMs compared to containers
1 ) Use Orchestration
- Usually containers are ‘clustered’ for HA and load balancing
- This HA architecture needs to be designed and understood
- Use Swarm or Kubernetes – market leading
Docker Swarm:
-enables clustering, scheduling and integration capabilities
-helps developers build and ship multi-container and multi-host distributed applications
Google Kubernetes:
-open source container cluster manager, can schedule container replicas across a group of node instances
-will scale most large container-based applications
Both perform essentially the same functions. POCs will determine what is the best fit for a particular environment and set of apps
2) App Architecture Design & Testing
Orchestration tools remove some of the underlying complexity of Container, but design of how to divide up the application within the containers is critical
- If containers are too fine-grained, the container services will be overly distributed and complex
- If the containers are too coarse-grained, the containers themselves will be too complex
- Test and operationalise the container orchestration (100% uptime is the target)
- This means component and regression tests, performance tests and penetration tests for security
- CI/CD to update containers, update code, without having to stop serving users
POCs will determine the exact nature of granularity and CI/CD processes
Firms usually need help with building and managing Docker Swarm and Kubernetes Clusters
This includes providing production-ready infra with TLS (SSL), HA, and networking extensions via Flannel, Canal etc.
Design of infra connections via API Endpoints is also critical (as is managing APIs eg Mulesoft)
To make Container deployments easier firms usually need help with blueprints, patterns, and building hybrid-applications from VMs, containers and pods (a mix of all 3).
Series of open-source blueprints for Swarm and Kubernetes exist
Patterns and Blueprints can be reused and customised per app demands
Firms need help with:
Pattern management which simplifies creation of managed deployments of container- applications.
- A key win is to build a re-usable component library which enables creation of applications incorporating both/either Docker and Kubernetes.
- A main factor is to allow seamless deployment to these infrastructures
Containers will do the following:
- Allow firms to lift and shift applications per specific OS quickly
- Avoid refactoring and changing internal code behaviour, or external app behaviour
- Greatly simplify testing
- Provide time to set up a dev-ops environment to create a pipeline to update the code, or to engage in refactoring and creating a cloud-native app version