Storage for Containerized Applications
•Download as PPTX, PDF•
3 likes•692 views
Persistent storage for containerized applications Linux containers are on course to change DevOps forever. Container technology will also impact how we think about persistent storage for applications and microservices. In turn, software-defined storage will impact how storage is dynamically provisioned and managed for containerized applications. Using close integration with orchestration frameworks, such as Kubernetes and private Platform-as-a-Service (PaaS) such as OpenShift, Red Hat® Storage extends the current limit of performance by providing seamless, enterprise-grade storage for critical applications in containers.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Storage for Containerized Applications
Similar to Storage for Containerized Applications (20)
More from Red_Hat_Storage
More from Red_Hat_Storage (20)
Recently uploaded
Recently uploaded (20)
Storage for Containerized Applications
- 1. Storage for Containerized Applications Irshad Raihan Product Marketing, Red Hat Storage Oct 15, 2015
- 2. Container
- 3. Why Containers? Developers Operations • Speed • Choice • Sandbox • Stability • Legacy • Production
- 4. What Are Containers? Software packaging concept that typically includes an application and all of its runtime dependencies • Higher Quality Software Releases • Shorter Test Cycles • Easier Application Management HOST OS SERVER CONTAINER LIBS APP CONTAINER LIBS APP Benefits
- 5. LightweightVirtualization HOST OS, SHARED SVCS SERVER CONTAINER LIBS APP CONTAINER LIBS APP HOST OS SERVER VIRTUAL MACHINE LIBS APP HYPERVISOR GUEST OS VIRTUAL MACHINE LIBS APP GUEST OS Virtualization Containers • Lesser Overhead • Faster Instantiation • Better Isolation • Easier Scale
- 6. “Linux Containers” “Docker” Why Now? Source: Google Trends
- 7. Simplifying Container AdoptionThe Open Source Way STANDARDS
- 9. Why Persistent Storage for Containers? Base: 194 IT operations and development decision-makers at enterprises in APAC, EMEA, and NorthAmerica Source:A commissioned study conducted by ForresterConsulting on behalf of Red Hat, January 2015 “For which workloads or application use cases have you used/do you anticipate to use containers?” Scalable, Cost Effective Containerized Storage
- 10. How Did We Get Here?
- 11. Storage in the era of Microservices From Infrastructure centric to Application centric Microservices • Small • Loosely Coupled • Continuously Deployed • Disposable Automated Provisioning Single Control Plane Storage as a Microservice
- 12. ThankYou
Editor's Notes
- Inspired by the shipping industry Separation of concerns brought efficiency and cost Linux containers speed up application development, because you can build once and run on any infrastructure. Infrastructure can include bare-metal servers, virtual machines, public clouds, and network devices. Encapsulating dependencies inside a container helps shorten the testing cycle. That’s because containers make it easier to write single-function applications, which simplifies testing and can accelerate the development and operations (DevOps) cycle. Developers can add new application features more quickly by taking advantage of automated building, testing, integration, and packaging - at the speed of containers. Containers simplify IT operations: Fewer operating systems to manage: Each virtual machine can be carved into multiple containers, all sharing the same operating system kernel. Greater application mobility: You can move workload between private and public clouds more quickly, by orders of magnitude. Instead of moving gigabytes between clouds, you can move megabytes. Easier OS patching: A virtualized application with 10 virtual machines has 11 operating systems - the hypervisor and each guest operating system - and each needs patching. In contrast, a containerized server with 10 applications has only one operating system. Easier application patching: Docker container images are composed of layers, and you can patch by just adding a layer. The new layer doesn’t affect the others. The layers of a web application image, for example, might include an Apache web server, a PHP runtime system, and Redis for caching. Better workload visibility: Operators can’t see the workload inside a virtual machine, but they can look inside a container from the container host environment. One benefit is the ability to detect unused container instances, helping to avoid virtual machine sprawl. Another benefit is simplified dependency mapping and security maintenance. Improved resource utilization: Linux containers run on a single computing instance, making it easier to detect their activity and retire unused containers. Idle containers don’t take up computing, memory, and I/O resources. Faster provisioning: Containerized applications can boot and restart in seconds, compared to minutes for virtual machines (Figure 1). Booting and restarting are faster because containers have smaller payloads and don’t carry the overhead of a hypervisor and guest OS. Faster boot time correlates with less downtime. This benefit is especially appealing for organizations that want to use a public cloud service to handle higher-than-usual transaction volumes. In this case, faster boot and restart times can directly reduce costs.
- Isolates applications on a host operating system. Overhead of guest OS (10’s of GB) Incomplete separation (two versions of apps in same vm) Scale Physical: 27 hours Virtualized: 12 mins Container: 10 sec Virtual machines aren’t ideal for every use case: Virtual machines need minutes to spin up, which can degrade the user experience and give hackers time to exploit known vulnerabilities during bootup. Patching and lifecycle management for virtual machines requires a significant effort. That’s because every virtualized application has at least two operating systems for operators to manage and secure: the hypervisor and the guest OS that is inside the virtual machine. Even the simplest OS process needs its own virtual machine. This requirement increases flexibility, but it also makes virtual machines impractical to use for microservices architectures with hundreds or thousands of processes. When each physical server is replaced by one virtual machine, physical resource utilization tends to remain low. Server sprawl is simply replaced with virtual machine sprawl. Less time is needed to transport, copy, and instantiate containers because they are smaller than virtual machines. They are often just a few dozen megabytes, where a typical virtual machine might be hundreds of megabytes, or even gigabytes. For example, if a website relies on a particular version of the PHP scripting language, the container can encapsulate that version. As a result, multiple versions of the same scripting language can co-exist in the same environment - without the administrative overhead of a complete software stack, including the OS kernel. Containerized applications perform about as well as applications deployed on bare metal.
- Red Hat works with the open source community to drive standards for containerization
- With the advent of xPaaS, users can move beyond the limits of simple application development of today’s PaaS offerings to the next generation of PaaS technologies and capabilities. xPaaS is a rich set of application development and integration capabilities that will enable users to build and deploy complex enterprise-scale applications. Gartner uses the term xPaaS to describe the whole spectrum of specialized middleware services that can be offered as PaaS. Red Hat is in a unique position in the industry to deliver xPaaS, having both a comprehensive portfolio of middleware technologies and the supporting PaaS infrastructure together under one roof.
- Micro Services: An approach to develop a single application as a suite of small, independently deployable services.