CSC AWS re:Invent Enterprise DevOps session

Editor's Notes

• #3: And this is bad enough. But the real problem for today’s Enterprise IT is that there are a number of IT environments on the Internet, with very low barriers to entry that give business users and developers unparalleled choices in meeting their pent up demand for responsive IT
• #4: NOTES: The movement toward DevOps was born and started to pick up steam. Now enterprise customers and other industries want in on the action So what is DevOps? Sometimes, people get caught up in the debate of exactly what DevOps is, so let’s try and quickly level set. DevOps is a discipline (or philosophy if you prefer) to release software faster without sacrificing quality. Ultimately that’s it. And lots of people benefit from more frequent releases… particularly business application owners, and the end-customers that drive your business. There are clearly 2 primary stakeholders in this, and that have their own specific objectives Dev compresses their cycle times and focuses on coding and creativity. Spend more time coding, less time on nonproductive, noncoding tasks. IT Ops keeps pace with faster change that Agile Development has thrown over the wall at them… but they can’t sacrifice reliability in the process. Find new ways to automated and standardize their mostly manual configuration efforts today to keep pace and keep risks down.   So those are the high-level objectives…. But how do you DO IT??
• #5: NOTES: Let’s quickly cover the two most important benefits of this (there are others). First… When we say “reduce cycle times,” what we’re really doing is squeezing out the nonproductive or low-value administrative effort that everyone in the SDLC has to go through today to manage their underlying platforms and infrastructure. There’s a lot of it – as shown in the gray areas on the slide. Some studies have shown that this can consume as much as 30-50% of the Dev and Test organization’s time … which includes all the environment provisioning and manual configuration of machines … the software build process, the software release management processes, and more.   Our goal is to reduce time-to-market without short-cutting or changing any of the high-value Dev and Test work your already doing today. In fact, we want to free up more time for you to do that higher value work in your existing IDEs or Test Automation Suites… for example (shown in Blue).   2) Second is reducing defects caught in production. One of the biggest sources of production defects comes from configuration errors associated with underlying platform and infrastructure. It’s a common problem, because the real configuration complexity rears its head in production, and not in earlier Dev and Test work. For example, Developers may code on their desktop in Ubuntu…. But those configurations don’t work when they deploy on RHEL…   And it’s well known that the cost of resolving a defect once it reaches production is literally an order of magnitude more costly than catching and addressing that defect earlier in Development. And there are other important quality implications as well as it relates to customer satisfaction.
• #6: NOTES: In enterprise settings, tackling a DevOps initiative is not that easy. There are the process issues, the organizational issues, and the technology issues. Let’s set aside most of the organizational issues for this discussion, other than to say you’ve got silos built up between different teams…. And you need new catalysts to bring them down. But just focusing on the process and technology perspectives, there are some significant problems with orchestrating and automating across an enterprise SDLC. Why? Because, in reality, you’ve got separate and disjointed lifecycles between Infrastructure, Platforms, and Applications. Applications have an entire category of tools and process to manage application development. From IDE, repositories, bug tracking tools, testing tools, and more. These tools also support development processes ranging from waterfall to Agile. However that lifecycle is supported by IT infrastructure that has a completely different lifecycle of its own. Different in terms of procuring servers, storage and networks,.. upgrading and patching OS and utilities, and sunsetting older gear. And then you have platforms lifecycles… and they can have the most chaotic lifecycle of all. There may, or may not, be a platform standard but often times Dev just does what it wants anyway. QA uses its own flavor as well. Often you get all different types of permutations across the SDLC…which can become a nightmare in terms of fixing configuration mismatches when you deploy into Production..
• #7: NOTES: So the result is really long cycle times and a process that is extremely IT resource intensive. Why? Because of these completely separate, disjointed lifecycles … the symptoms may sound very familiar: IT resource provisioning delays Manual platform configuration Configuration mismatches and errors Poor automation across silos
• #8: NOTES: So how do you fix it? Well, sorry but IaaS won’t do it. I say this because DevOps has become a popular space. As a result, a lot of folks have “DevOps washed” their existing offerings… IaaS is really quite narrow in scope and isolated from the rest of the SDLC: Access from a portal (not directly from tools SDLC teams use) Offers base OS images(which are not what dev and test really want) Delays remain for manual configuration (the user patches and maintains the operating systems and the application software themselves) Insufficient governance for a true self-service experience (still typically manual approvals) “Shadow IT” problems remain (unless you provide a better/equivalent experience than Amazon EC2 for example) IaaS does not really change the dynamics of a slow and costly SDLC. The scope of a DevOps solutons needs to be much broader. Let’s discuss some of the key attributes that make up a real DevOps solution.
• #11: 10
• #12: 11
• #13: Comprehensive security requires the following: Host intrusion detection systems and antivirus Virtual firewalls Encryption of persistent data Secure connectivity Federated Identity Management ====================== Network Isolation SM Secure is a redundant customer-controlled encrypted overlay network service that provides security in a cloud, across multiple clouds and between enterprise DCs and commercial clouds. Supports Multicast / static IP management / Point-to-Point Routing Firewall Integration Instance Isolation All stacks include active host based intrusion detection /prevention packages. Pluggable Virus Scanning is integrated into each stack. Data Isolation All stacks include configurable encrypted block storage and SDKs for non-block storage reqs. Backups of block storage devices inherit encryption Recipes available for encryption of data to be transferred or stored in non-block storage. The Cloud Manager provides granular role-based access control to instances and stores Certificate and key-pair access control of instance log-in. Connections only over strong-encryption SSL. “Overlay Network” - Extends the client’s network into the cloud provider: Bridges to corporate network much like a VPN. Enhanced failover, load balancing, peering Support extension of corporate IP assignments. (both DHCP, Static) Support point-to-point connections. (eg. Servers can talk directly to each other without having to go back to corporate DMZ/Data highway.) Ability to bridge multiple clouds. Support for multicast Requires deployment of at least two nodes in both the external cloud provider and the corporate data highway. (4 nodes minimum)
• #14: NOTES: First, you need to provide the platforms and deployment environments that SDLC teams can really use to do their work. “Out of the box” … without further manual configuration. Development platform defined as database, app server, web server, and other application components … all orchestrated together and spun up as a whole. And these platforms need to be available on-demand from the cloud of your choice … public or private.
• #15: So how is it that we’re creating these custom multi-tier platforms?   We make it as easy as possible with our Blueprint Designer. Graphically model these multi-tier, cloud portable apps and platforms You assemble them by dragging-and-dropping templates and layering on packages…. to create your middleware components You then define startup orders between app components, pass variables between them, and recognize each other’s IP addresses and other dependencies Finally you customize these platforms with policy controls, like compound autoscaling policies for one tier, or creating security zone policies….   And the Agility Platform orchestrates all this … and then drives the deployment of this through the underlying cloud or resource manager that you select. The application blueprints themselves are infrastructure independent. And this is a different approach than what others have taken. So you can create a blueprint once…. And deploy it across all the public and private clouds that we support.
• #16: The focus on applications and platform blueprints is important … but those apps and platforms don’t do you much good unless you’ve also got effective governance in place … otherwise you can’t deliver them with any meaningful self-service automation. (It’s not just about risk mitigation. It’s also about automating an on-demand, self-service user experience.) And you need a policy engine that can customize platforms for the specific needs of each stage in the SDLC…. Because each stage really has unique needs.
• #17: NOTES: For example: For the Dev team, You can have policies to allow EC2 usage for some projects Or provide chargeback reports to managers For QA, You can require that deployments only go to the internal private cloud (based on the live customer test data that’s used). You can enable autoscaling for performance testing purposes. For production, you can embed a completely different set of monitoring and security agents, and enforce different security zones, to give you a different security posture And yet … there are some things you may want to keep totally consistent Like the SOE… which enables certain services to be installed on all instances within a project. Or adhering to regulatory constraints … like geographic location or some other industry compliance mandate.   These policy controls provide you with a lot of flexibility and control, and allow you to set the right balance between customization and consistency for your environments.
• #18: NOTES: The focus on applications and platforms is important … but those apps and platforms don’t do you much good unless you’ve also got effective governance in place…. Otherwise you can’t deliver them with any meaningful self-service automation.   So the way you do Could Governance and policy matters.… What you need is to take an application-centric approach with an extensible policy engine on the back end. When we’re talking about cloud governance in the Agility Platform, we’re talking about much more than just Role-based Access Control. Or simple provisioning constraints.   Out of the box with the Agility Platform, we provide over a dozen different types of application-centric policy controls. Everything from… Regulatory compliance policies SLA policies including compound auto-scaling rules. Configuration management policies for continuous compliance of workloads after they’ve been deployed. Detailed Security zone policies including configuring firewall rules and embedding security agents and utilities. Lifecycle event policies to customize environments based on SDLC stage. Orchestration policies. Entitlement policies. Workload placement policies to limit workloads to authorized environments. Quotas, scheduling, leasing, chargeback, backup, failover, resource capacity policies. Storage tier policies And much more…..   And these policies apply up and down the application topology shown in the middle. So they absolutely apply to the infrastructure layer … for configuring network, for storage tier, including storage provisioning using EMC’s ViPR, which was talked about in the keynote. But also all the way up through configuration the application components, and the actually application itself.   So the Agility Platform represents this “control plane”…. And the idea is to fully automate and govern IT resource consumption…and simplify the complexity of doing that across different types of clouds.
• #19: NOTES So far we’ve been talking about platforms and environments, but automating the promotion of code and approving builds are also key areas to automate. Release Manager is a... Visual dashboard to promote application code artifacts and complete deployment environments across SDLC stages. You can customize your SDLC stages, such as Dev, QA, UAT, and Staging. And you can promote software releases from an easy-to-use, drag-and-drop dashboard. In addition, we enable tool chain automation with adapters to SDLC tools like: IDEs, such as Eclipse and Visual Studio Repositories, like Git And Continuous integration servers, like Jenkins.   So you can provide end-to-end automation across your tool chain.
• #20: NOTES: So… putting it all together, Agility Platform helps you orchestrate and accelerate the software development lifecycle. We give you: On-demand platforms and apps that end users really need Automate workflow across existing tool chains Governance, visibility, and cost transparency that managers require Automate application release and promotion Detect and remediate configuration changes Leverage hybrid clouds and enable cloud portability In summary, the combination of application blueprints, policy controls, and RM can enable you to orchestrate and automate significant portions of your SDLC … and really increase the speed and frequency of software release, which is a critical aspect of improving your business agility.   That’s essentially what is illustrated here ... showing the app toolchain up top, integrated directly with the deployment environments, which are modeled with blueprints and governed via policy, and then deployed into your preferred public or private clouds while remaining infrastructure independent and cloud portable.
• #21: NOTES: First, you need to provide the platforms and deployment environments that SDLC teams can really use to do their work. “Out of the box” … without further manual configuration. Development platform defined as database, app server, web server, and other application components … all orchestrated together and spun up as a whole. And these platforms need to be available on-demand from the cloud of your choice … public or private.