First generation runtimes for containers assumed the workload inside the container would be stateless and ephemeral. But, most useful systems require storage of state somewhere. With the progression of container platforms from Mesos and Docker, you can easily run your stateful applications such as databases inside of containers. This session will cover the current state of persistent storage, containers and schedulers, including future directions in this arena.
Takeaways: Containers are a huge opportunity to improve efficiency
Taking advantage of this opportunity at scale presents some challenges
Container schedulers are a popular and proven way to handle the challenge of deploying containers at massive scale. Mesos, Kubernetes, Swarm and CloudFoundry are examples your organization might find it worthwhile to use more than one of these.
In the past year, containerization technology has advanced to allow persistent applications to run in a container.
The EMC{code} Polly project delivers supplements container schedulers to deliver true scale out for persistent applications running on containers.
Scale out is not just about adding capacity.
A Storage Scheduler will let you:
run multiple container platforms
run multiple schedulers
Utilize multiple storage providers
in or out of public cloud
This is about giving you flexibility and shifting the burden of keeping up to vendors
These two topics interact and as we’ll see, when addressed properly, link together
These two topics interact and as we’ll see, when addressed properly, link together
Objective: On each cluster node, pack jobs in tight to avoid waste in the form of unutilized resource
Playing Tetris with manual load placement might seem fun for a minute or two, but this gets old quick
Container placement ABOLUTELY must be automated,
Your old system of submitting tickets to reserve an IP and create a DNS entry isn’t going to cut it
The old 3 tier model was relatively simple,
You had your presentation or UI layer, your application or business logic layer, and your persistence or database layer.
Every thing was deterministically placed, and you knew where things were for troubleshooting, and the components knew where there counterparts were
Microservices isn’t quite N squared Metcalf’s law, but it heads that direction – a lot more interconnects.
And to improve efficiency, you have dynamic non-deterministic placement on to cluster nodes.
This is why I’m thinking of setting up a side business on Etsy to sell these cool microservices liquor flasks.It’s also why you need something called a scheduler
These two topics interact and as we’ll see, when addressed properly, link together
Schedulers can also enable end use self service,
With controls, audit, and health monitoring