Containers and the Docker EE Difference and usecases
â˘Als PPTX, PDF herunterladenâ˘
1 gefällt mirâ˘238 views
Erik Baardse Director Channel & Alliances APAC - Docker Tech Insights, Mumbai
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ăhnlich wie Containers and the Docker EE Difference and usecases
Ăhnlich wie Containers and the Docker EE Difference and usecases (20)
Mehr von Ashnikbiz
Mehr von Ashnikbiz (20)
KĂźrzlich hochgeladen
KĂźrzlich hochgeladen (20)
Containers and the Docker EE Difference and usecases
- 1. Containers and the Docker EE Difference Erik Baardse Director Channel & Alliances APAC May 31st, 2018
- 3. Containers are the âFastest Growing Cloud Enabling Technologyâ By 2020, more than 50% of global organizations will be running containers in production. -Gartner Title source: 451 Research
- 4. Static Website ? ? ? ? ? ? ? ? Web Frontend ? ? ? ? ? ? ? ? Background Workers ? ? ? ? ? ? ? ? User DB ? ? ? ? ? ? ? ? Analytics DB ? ? ? ? ? ? ? ? Queue ? ? ? ? ? ? ? ? Desktop Test/QA Cluster Production Cluster Public Cloud Data Center Mainframe Windows Server Edge Device The âMatrix from Hellâ Breeds Complexity
- 5. The âMatrix from Hellâ Breeds Complexity Static Website ? ? ? ? ? ? ? Web Frontend ? ? ? ? ? ? ? Background Workers ? ? ? ? ? ? ? User DB ? ? ? ? ? ? ? Analytics DB ? ? ? ? ? ? ? Queue ? ? ? ? ? ? ? Desktop Test/QA Cluster Production Cluster Public Cloud Data Center Mainframe Windows Server Edge Device â Containers Cut Complexity
- 7. ... Encouraging Large Enterprises to Adopt Docker for Top Initiatives... Modernize Software Supply Chain Modernize Existing or âTraditionalâ Applications (âMTAâ) Cloud Strategies Avoiding lock-in Reduce Data Center Expenses Faster Application Development and Delivery
- 8. Supporting Global Growth with Microservices The more we move workloads to microservices, the better the efficiency. Global Head of Infrastructure and Operations KEY CHALLENGES Infrastructure & tech refresh demands growing while IT resources remain flat. SOLUTION Use Docker EE to refactor critical transaction processing applications RESULTS ⢠Deployed applications globally: grew transactions from 100K to millions daily ⢠Provision in seconds rather than days or weeks ⢠Container efficiencies = 10x increase in scalability
- 9. Forecasting 66% Cost Savings with Faster App Delivery Docker Enterprise Edition creates a self-funding model to fuel change and innovation at scale. Jeff Murr Director of Platform Engineering, MetLife KEY CHALLENGES Enable innovation by reducing TCO of existing apps and infrastructure SOLUTION Docker Enterprise Edition for Modernizing Traditional Applications RESULTS ⢠66% TCO reduction for single technology stack ⢠70%+ VM consolidation ⢠10X increase in CPU utilization ⢠3X improvement in application delivery, from 15 to 5 months
- 10. KEY CHALLENGES 150+ year old banks needed to accelerate innovation and cut costs by moving 80% of apps to the cloud by 2020 across multiple data centers SOLUTION Use Docker Enterprise to build a CaaS solution more flexible than PaaS to support thousands of existing applications RESULTS ⢠First 10 applications in production, with 50 more in development ⢠400 developers now using Docker EE ⢠Integrated Docker EE with CI/CD tools: Jenkins, GitHub, and Nexus Migrating Thousands of Applications to the Cloud With Docker Enterprise Edition, everyone wants to work with containers; everyone wants to work with Docker and itâs a change of mindset in the company.â Thomas Boussardon Middleware Specialist
- 11. Kicking Off Your Containerization Strategy
- 12. ⌠To Deliver New Value and Savings Across Your Organization MTA ACCELERATOR PACKAGE (4 weeks) MTA PILOT PACKAGE (8-12 weeks) MTA PRODUCTION PACKAGE (12-24 weeks) MIGRATION SERVICES BY PARTNERS (custom) MANAGED SERVICES BY PARTNERS (custom) Proof of Value First Applications in Production Production at Scale Manage & Innovate TECHNICAL ACCOUNT MANAGEMENT TRAINING SOLUTION ARCHITECT Docker Enterprise Software Subscription Agility Improvement OpEx Savings CapEx Savings Team Competence
- 13. App Qualified App Assessment, Architecture, and Planning Dev Team Training Containerize App Components App Operating Model (SLA, updates, deployment) Operationalize App on Docker EE Dev Platform App Compiles Build and Image build via Dev Pipeline (Optional) Containerize Automated Test (Option) App Deploy via Dev Pipeline (ex. Jenkins file) App Validation and Testing Dev Platform (functional) App Deploy and Testing Pre-Prod Platform (security, perf, rollback) Go-live App on Prod Platform App Migration Retrospective and Docs Handover and Training (Optional) App Production Pipeline Assessment, Architecture, and Planning Operationalize Dev Pipeline (SCM, CI/CO, DTR) Containerize CI/CO (optional) Pipeline Validation and Testing on Dev Platform Extend Pipeline to Prod Platform (Scan, limits, security) Go-live Pipeline on Prod Platform Platform Requirements, Architecture, and Planning Create Enterprise Base Images Operationalize Dev Platform (LDAP, provisioning, storage, backup) Operationalize Pre-Prod/ Prod Platform (DA, DR, 3rd Party) Pre-Prod/ Validation and Testing Go-live Prod Platform POC or Equivalent Completed High-level Assessment and Business Case Establish teams, Organization, Init Training Production Pilot Selection and Planning Production Pilot Kickoff Internal Marketing and Service Creation Operating Models (Service, Platform, Pipeline, SLA/RACI) Security (Compliance requirements, Audits) Integrate Onboarding Aps Tools (wiki, ticketing, hotline) Onboarding Assessment and Planning Establish App Support Onboarding Content Publishing Establish Training Program Establish Center of Excellence Governance and Service Retrospective and Docs CI/CO Operations Continuous Improvement Process Docker EE Platform Operations Continuous Improvement Process Governance and Service Delivery Continuous Improvement Process ⌠With a Methodology Depth to Ensure Success Applications Pipeline Platform (Docker in your data center, cloud, etc.) Governance Operationalize Pre-Prod/Prod Platform (HA, DR, 3rd Party)
- 14. MTA Accelerator DESCRIPTION The Docker MTA Accelerator Service helps customers to understand the value of modernizing traditional applications on the Docker EE platform using a standard infrastructure build out and prescribed set of methodologies for containerizing and deploying candidate apps. OUTCOME ⢠Enable application teams to containerize and deploy their app(s) through an automated build pipeline ⢠Enable operations teams to understand fundamental concepts related to deploying Docker EE ⢠Transition to pilot engagement opportunity
- 15. MTA Pilot DESCRIPTION The Pilot Service enables a customer to move beyond PoC by integrating Docker EE into their infrastructure and automatically build and deploy an application on a development cluster. OUTCOME ⢠Enable pilot development team to Dockerize their application and automate the build and deployment on a development cluster. ⢠Enable operations teams to integrate Docker EE into their existing infrastructure and information systems. ⢠Evaluate the required organization, processes, and tooling for the Docker service.
- 16. MTA Production DESCRIPTION The Production Service enables a customer to automatically and securely deploy their first apps in production by operationalizing Docker EE in their infrastructure on a highly available production cluster. OUTCOME ⢠Enable development team to Dockerize their applications and continuously deliver them in an automated, tested, and secure way. ⢠Enable operations teams to operationalize Docker EE in their existing infrastructure and systems and manage its lifecycle across development and production clusters. ⢠Establish the required organization, processes, tooling, and support to allow development teams to onboard at scale to the Docker service.
- 17. Typical ROI Results from Customers Infrastructure Savings ⢠Hardware and software licensing savings 20% â 40% ⢠Operations support savings 20% â 40% ⢠Reduction in number of virtual machines (VMs) 50% â 90% Productivity Gains 30% â 60% ⢠Agility Deploy and scale in minutes ⢠Security Secure app isolation, threat scanning, and monitoring ⢠Portability Streamlined workflow from development to production
- 18. THANK YOU :) Return to Platform Features
Hinweis der Redaktion
- Main point:  Containers are not new, this is not bleeding edge technology. Containers are mature, safe and and very versatile, new technologies are being delivered as containers. Speaker notes Containers are not a new technology. They've been around since the late 1970s. Google began implementing most of their services in containers from 2006. Docker began in 2013, and there have been other derivatives since then. And yet, most would credit Docker with having facilitated the uptake of container technology into mainstream IT. It was Docker that made it accessible. What made Docker's launch the breakout time for containers? There were versions of containers before Docker, but Docker went a lot further. They built an efficient ecosystem around managing them. They put in place a command line interface, built REST APIs on top of them, simply made containers easier to use. Since then weâve seen so many innovations and emerging technologies being delivered as  Docker containers.
- This is advice regarding the entire sales deck. The sales deck is intended for a broad, generalist audience. This not what you would bring out to a set of developers or operations specialists, although I think you'll find that there are components of use and interest to those folks as well. Â We've broken it down into five distinct chapters. You don't necessarily need to use every chapter if your audience is aware enough that you don't need to start at Chapter One, for example. But, here is how it breaks down. Â Chapter One is called The Container Difference. It's a quick introduction to container technology. Often, we find that, even people who think they know what containers are, sit attentively to find out what we think containers are, what we explain them to be, and the benefits they bring. Â The point of Chapter One is to highlight that containers are a technology, and technology can give you some benefits, but not a sustainable benefit. For a sustainable benefit, you need more than just the technology. You need the Docker platform and services. Â That leads us into Chapter Two, which is called the Docker Difference. In Chapter Two, you'll see the three pillars of our value statement around Freedom of Choice, Security, and Operational Agility. We'll cover those in that chapter. We'll hang things off of that. So, the concept of the platform and services will relate back to those three pillars. Â Chapter Three is titled Our Commitment to Your Success, and highlights the depth of experience and understanding that we bring to each engagement. Let's not understate that. We are the most experienced company in this technology and with this platform, and it is the most commonly used platform and technology out there. We bring that to every engagement. This is where you begin to see the services wrap that Ian's team has been working on. Â That brings us into Enterprise Results, and this is a fairly classic logo-based derivation of who we are and the credibility we bring. So, it highlights a number of common initiatives that lead companies to consider Docker, and containers in general. We've hung logos off of that. Â And then, we go into Chapter Five, which is called Kicking Off Your Container Strategy. This is the call to action. It details the kinds of service packages our company offers, describes what you can expect from them, and, to an extent, which one may be more suitable for you. Â That wraps it up. The intention is, by the end of it, you've stimulated some conversation around where the best place is to start with the customer. Again, this is not necessarily something you have to use from Chapter One through to Chapter Five. It depends on your audience. What you will hear throughout is that there's an emphasis on the platform as opposed to just selling Docker EE. The emphasis is not just on selling Docker EE Advanced. It's to sell it as part of a services package. Â That's the emphasis going forward for the company. It's not just selling Docker EE. It's selling it as part of a services package. Why? Because we've found, if left to their own devices, customers who buy Docker EE on its own generally don't get the most out of it and, as a result, don't renew very often. These customers certainly don't grow very much, if at all. Â The conclusion is, we have to help them. In a way, it's also a commitment that they show us that they're serious about this. With that said, we'll kick off into the sales deck.
-  Main Point:  Initially container popularity exploded because it helped developers solve the cloud portability problem. It then started to be used to address the broader platform portability problem. The big question is why? Why did this technology become the worldâs fastest growing software in history. Initially, and by that I mean from around 2014 to 2016 it was developers who led the way. The problem was a variation on an old one, write a app once and have it run anywhere. That was the main attractionâŚ.application portability mainly for new applications back then. This chart should look familiar.  You can see the range of applications and the the environments and platforms they have to run on, and the nearly infinite number of versions of frameworks, drivers, and libraries these applications were built on. Portability, the ability to move an application between platforms, on-prem and cloud, or anything like that is really hard to do before Docker. Not only do you have the inability to move apps around, but you have to go back and maintain them. You have to stand them up and operate them..sometimes in a different way for each platform. Those are the things that consume so much of our resources and our manpower. Â
- Main Point:  And hereâs how to think about software Containerâs solving the portability challenge. Simple, standardized, ubiquitous Docker technology just like cargo containers (âabstracts the application from the infrastructureâ) Speaker Notes When we introduce containers, and put those applications, services, and functions into containers, we've created a standardized way of deploying them to almost any platform. For people that are newer to the container world, itâs worth a quick comment on why we use the shipping container metaphor. Besides sharing a  name, cargo Containers like the one in this picture revolutionized shipping. All of these steel boxes were the same size and would securely protect whatever they contained. Nothing in one container affects whatâs in another. All shippers needed to know was that their products could fit into one of these steel boxes. And all the transportation companies needed to know was the size allowing them to set up ships, trains, and trucks to carry the industry-standard container. Shipping costs for labor and equipment dropped as the entire industry standardized on these containers. Thatâs the analogy... that standardized way of building and packing cargo is analogous to software everyone can receive and run them. However the analogy also has limitations. Unlike cargo, Software containers are not all the same size. Infact one of the critical differences is that software containers carry just what the application needs to run and nothing more. So they are very lightweight. Nothing that isnât needed. In the IT world that means they are light on computing resources.
- In some ways, everything I've been talking about so far has been hypothetical. I want to ground it in the reality of what our customers are doing with us today.
- Main Point: Things have changed since the early days of Developers looking for a simple way to develop portable apps. Today Enterprises such as these use Docker for a range of IT initiatives. Chief among them, Modernizing Existing (or Traditional) Applications. Modernizing them to move to the cloud or just to take advantage of the savings and productivity gains on-prem or for any of the other reasons shown. Look at the breadth of industries represented and the leading names among them...Dockerâs platform is mainstream technology used at Enterprise Scale. This is enterprise scale...you need a platform and access to specialist expertise. These are the initiatives that led to the platform we built. We always start with what you want to achieve for your business, and these are the business initiatives we see over and over again. Chief among them is the desire to maximize the life and use of existing applications...weâve called this Modernizing Traditional Applications or MTA By the way, these initiatives arenât mutually exclusiveâŚ.you can choose to MTA an existing app to move it to the cloud in order to reduce or avoid data center expenses. Similarly accelerating app development comes naturally from just containerizing app development (since you can move it from Dev to Test to QA to Prod without issue) but that decision can also be a part of a bigger initiative to modernize the whole software process to  incorporate eg CI/CD and DevOps as a methodology. . [Click] Now we've aligned a selection of large organizations using Docker to deliver them. Truth be told, in many instances, it was more than one motivation. At times, what started as the first reason for looking at this evolved into something else. Quite often, what started off as a developer initiative for doing things easier turned into a massive financial benefit that was too hard to ignore and just steamrolled whatever else was in the way. You'll see some of that as we go into these in more depth. Look at the breadth of industries represented and the leading names among them...Dockerâs platform is mainstream technology used at Enterprise Scale. Weâll talk more about that later. You canât do all of this without a robust scalable platform and proven scalable enablement expertise to go with it. Â
- Let's start with Visa, one of our oldest customers. Their challenges will be very familiar â more demands with a flat budget or flat head count. I have heard so many versions of this, that new infrastructure provisions took a few days â as much as a few months. That often is one of those initial reasons to look at Docker. I can set up a permanent environment and whatever's not being use disappears, so I'm not paying for what I'm not using. But, it's there at the ready for whichever team feels they need to get on and grab some resources and start doing some development, testing, or whatever the case may be. Â In the case of Visa, it was this regular patching cycle that keeps getting in the way and taking so much time. Their solution was to take some key applications for transaction processing and they said, "We're done with this heavy maintenance. We're done with this weekly 2:00 a.m. downtime so that we can patch this. We're going to refactor these applications into microservices so that we can just maintain the components that need fixing." Because containers don't take any time at all to tear down and stand up, once they're ready to deploy the new microservice, the update, it's as simple as switching one on, switching the old one off, and no one is the wiser that you've even done something. Â Look at some of the results. They rewrote two key applications, and look at the difference in speed â from about 100,000 transactions per day to millions per day. They were able to increase the scale by 10x on the services they were running. That's a tenfold increase in density of applications per server in containers versus traditional VMs. That goes back to the very beginning of the presentation, where I said that's that key infrastructure gain. Because of the means of refactoring and microservers, provisioning time is now seconds rather than days or weeks as it was before.
- MetLife is a fairly common case of mergers over time leading to sprawl of systems, leading to all sorts of complications and inevitable inefficiency. With some 400 systems of record, customers couldn't access all their policy details in one place. When they traveled, it was difficult. The agents outside were complaining that they couldn't do the same for their customers. They weren't able to optimize the use of their time with their customer and looked to sell new products. Â The challenge was that there are a lot of complicated systems out there and how to do this. In the case of MetLife, they decided to do a couple of things. They completely redesigned the frontend, the system that faces the world â the customers, agents, and internal users â and modernized many of the backend applications. They took a very radical approach for a very conservative company, to completely redesign the frontend and modernize many of the backend applications. Â Here are the results. These are quotes from one of the key executives of the program, Jeff Murr. "Total cost reduction of 60-odd percent. VM reduction of 70-odd percent. Dramatic consolidation in space." They were able to move to the cloud at high speed. They've accelerated development of new applications as well. These are very common findings. Again, I note here that this is an insurance company and not exactly everyone's idea of a fast mover or radical thinker. They had the confidence in this technology to take such a dramatic step as to completely rebuild their frontend on Docker technology.
- SociĂŠtĂŠ GĂŠnĂŠrale (sohs-yeh-TAYÂ Â Â zheh-neh-RAHL) This is a 150-year-old company. So is MetLife. I keep emphasizing this because, as new as this technology might appear to be, it's not. As radical a step as some of you might think it is, it's not. Here are Exhibits A and B, these two 150-year-old companies who thought this was safe enough to take a big step with us into the world of containers using the Docker platform. Â And, what was SociĂŠtĂŠ GĂŠnĂŠrale's key motivator here? A very common one and one of the six we've talked about â moving to the cloud. Getting costs down. Eliminating the need for capital investment in data centers, potentially globally. So, that's what they did with us. The containerized their applications and, with our help, moved them to the cloud. Where are they right now? They have about ten applications running in production on our platform with another 50 in development and 400 developers already using the platform. Â The point of these examples is firstly to show you the case studies, but to also emphasize that this is not a West Coast startup solution only. This is for major corporations with a lot of legacy investment in systems and applications and processes. There is a way to take advantage of these amazing benefits of moving to this technology in a safe way with a platform and the support services to get you there and productive.
- Kicking Off Your Container Strategy. Hopefully, we've made some sense so far. We've covered the technology, the need for a platform and what it brings, the value of a services partner to jumpstart your team with training and best practices, and finally, some examples of customers, what they're doing and the benefits they're seeing. The logical next step is, if you're interested in doing this with us, is where do we start?
- Before we leave our look at the our service packages support your Containerization strategy, itâs worth a quick mention of how the benefits tend to grow and change over time. If you only want to get your feet wet and start with a PoC, the main value is competence â the skills and confidence your team gains that containers can support your applications, fit your work flows, and deliver the benefits your expect. If just jump right into a Pilot, youâll also start to see the immediate reductions in CapEx as your development servers are able to support many more applications. As you put applications into production, those CapEx saves are matched with labor and OpEx reductions. A smaller infrastructure means less to manage. Youâll either support the same workload with fewer people or be able to assign members of your team to higher-value tasks. And as more applications and new development goes into production â whether supported by Migration or Managed Servicers by partners or not â those savings are more than matched by the business value of increase Agility. Youâll have a faster, more responsive team able to help your company build competitive advantage.
- Main Points: Not expected to read through this slide: its job is to show the depth of each workstream. Each measures success through key milestones and outcomes. Its a reference slide...if they want to go deep, then you need a different meeting. Here is a different view. Itâs an eye chart, but I just want you to be confident thereâs substance behind these claims. The colored boxes on the right are those same workstreams of Governance, Platform, Pipeline, and Application Development. And every one of those little boxes is a topic weâre cover in depth with a consultative service. We  working with your team to deliver training and best practices to you end up with the result you're looking for. So you can have an operationalized version of your application with an integrated operational service process and a repeatable way of maintaining and updating that software. ----------------- [Additional Detail on workstreams to support Q&A] Application Assess and Categorize Train to containerize Deploy and test Deploy to Production Monitor and Maintain Pipeline Assess, define and plan Operationalize Validate and Test Platform Assess, Define and Plan integration of the Docker platform into your entire environment Full, integrated set up Test Governance Assess, Define and Plan Train and Support Implement and Monitor Standardize and Maintain
- I'm going to touch on these, if only to just leave a couple of data points in your mind. We've described the Accelerator Package, and many of our customers have started with this package. Some have started down the line because they've had some exposure internally and they feel like they're sold on the technology, and they want to know how to industrialize it now. Â The Accelerator Package is about taking a couple of applications, containerizing them in Docker, and putting them into an environment where you can see them running, play with them, and reach your own conclusions. [If a pricing range is appropriate] Depending on the complexity of the applications, and the amount of training that's needed for your people, you can anticipate somewhere in that range of $32,000-44,000.
- The Pilot Package is a custom package. We will come in and talk to you about the applications you're seeking to explore, the level of maturity in your organization, and is it something you want to do yourself or bring someone else in to help you. All of this comes into the discussion. We will imbed a level of training. We will embed an individual with you called a TAM, or a Technical Account Manager, to make sure you're not about to take yourself off the edge of a cliff. That's that belt and braces approach. Â We'll put a Solution Architect on there with you to design the environment correctly around those four processes â Governance, Pipeline, Platform, and Application Development. It will be customized to you. [If a pricing range is appropriate] Depending on the complexity, the maturity, etc., this can run in the range of $130,000-300,000. It depends on the length of that engagement as well and all of the components that come into it.
- The Production package is the largest, where would come in and help you take key applications all the way into a production environment. Obviously, that's a longer engagement. It takes a lot more analysis to make sure we get that right. [If a pricing range is appropriate] And consequently, the price is a little higher with a range around $230,000-500,000, depending on the complexity, duration, maturity, etc. Â I give you these numbers, not to have you start to budget them, but just to give you a sense of scale. The key is they are a proven formula, but they are custom. We would come in for a scoping discussion and discuss all of these elements with you and come back to you with a proposal around an estimated time and materials basis. We would discuss that further, arrive at a statement of work that we all agree to, and then get to work. Â I'd encourage you to explore packages seriously. Sure, you can buy some software subscriptions and play on your own, but we find that they end up being wasted effort and wasted money. This is a little more than buying subscriptions. There's no doubt about it. But, the payoff, from what we've seen, is dramatically higher if you combine service packages with software subscriptions. Â Â
- I hope it's been of interest, has answered some questions, and has held together logically for you. More importantly, I hope you engage us to see just what we can do for you with the Docker platform, as we've done for so many other customers. Thanks for your time.