Containers and the Docker EE Difference and usecases

Editor's Notes

• #3: 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.
• #4: 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.
• #5:   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.   
• #6: 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. 
• #7: 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.
• #8: 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.   
• #9: 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. 
• #10: 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. 
• #11: 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. 
• #12: 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? 
• #13: 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. 
• #14: 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 
• #15: 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. 
• #16: 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. 
• #17: 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.     
• #19: 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.