CSC AWS re:Invent Enterprise DevOps session
•
2 likes•2,019 views
Enterprise DevOps is different then DevOps in startups and smaller companies. This session how AWS/CSC address this. How AWS IaaS level automation via CloudFormation, UserData, Console, APIS and some PaaS OpsWorks/Beanstalk is complimented by CSC Agility Platform. CSC Agility adds application compliance and security to the AWS infrastructure compliance and security. CSC Agility allows for the creation of architecture blueprints for predefined application offerings.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to CSC AWS re:Invent Enterprise DevOps session
Similar to CSC AWS re:Invent Enterprise DevOps session (20)
More from Tom Laszewski
More from Tom Laszewski (20)
Recently uploaded
Recently uploaded (20)
CSC AWS re:Invent Enterprise DevOps session
- 1. Eddie Satterly, CTO, Big Data and Analytics CSC November 13, 2014 I Las Vegas
- 2. Highly Competitive Market New Competition Unexpected, younger , agi le Client Improved Cost Control and Margins Greater Flexibility Faster Time to Market Heightened Security Changing Expectations Pace of Technology Change Urgent Business Demands Slow application release cycles Constant IT resource delays Aging apps; complex and costly infrastructure Lack of IT innovation with “80/20” budgets And IT ... Current IT Operating Models Just Can’t Keep Up The solution: A flexible, efficient application-centric hybrid cloud ecosystem
- 3. from this … … to this DevOps is a discipline to increase the pace and frequency of software releases without sacrificing quality Dev wants to compress their cycle times and focus on coding and creativity IT Ops wants to keep pace with faster change while improving reliability
- 4. 1 Increase the speed and frequency of software releases Start Finish Before Provision Dev Build Provision Test Deploy 2 Fewer production defects and easier roll-back Catch defects before Production, which are an order of magnitude more costly to resolve After Dev Test Defect Costs Design Test Production SDLC
- 5. Develop Test UAT Operate Application Lifecycle Infrastructure Lifecycle Platform2 Platform2a Platform2…n Platform1 Platform1a Platform Lifecycle
- 6. Application Develop Test UAT Operate Lifecycle Infrastructure Lifecycle Platform2 Platform2a Platform2…n Platform1 Platform1a Platform Lifecycle Completely separate, disjointed lifecycles IT resource provisioning delays Manual platform configuration Configuration mismatches and errors Poor automation across silos Extremely Long Cycle Times > 612 months RESULT: Extremely IT Resource Intensive:
- 7. Develop Test UAT Operate IaaS IaaS Portal Access from a portal (not directly from SDLC tools) Delays for manual configuration remain Insufficient cloud governance and security controls Needed: IaaS + PaaS Automation CloudFormation, OpsWorks, BeanStalk orchestrated with Agility
- 8. Developers want access to platforms When building and managing applications, which of the following 55% 75% 0% 20% 40% 60% 80% 100% App server Web server Database Storage objects Operating system JVM/JRE Other None of above 2% 8% 47% 54% 72% 79% services do you want to have access to? Source: Forrester Cloud Developer Survey
- 9. CSC Agility Platform Application-Based SLAs Key Business Value Enabler for IT • Application SLAs not limited to AWS SLAs • IT can deliver SLAs based on application requirements • Enabled by policies, thresholds, alerts, actions, auto-scaling, bursting, and auto-provisioning
- 10. CSC Agility Platform and AWS reference architecture Cloud Implementation CSC AWS Managed Services Resource Management Resources • VM Backup / Restore • Patch Mgmt, Anti-Virus • OS Support & Monitoring • SPOC Cloud Svc Desk, Billing • Resource configuration management • Resource monitoring • Resource pools • Virtual and physical resources Source: Gartner, “How to Build an Enterprise Cloud Service Architecture,” March 5, 2012 Amazon Web Services Connectors Access Management Service Management Service Optimization • Self-service interface • Service catalog • Service provisioning • Service governor • Service orchestration CSC Agility Platform Cloud Mgmt Platform Cloud Management Platform • Agility Platform Cloud Connectors (2)
- 11. Example Implementation: CSC Agility Platform and AWS
- 12. Policy-Based, Pro-Active Security Key Business Value Enabler for IT Security Zone Encrypt Driver Secure encryption keys • Internal Agility Platform key store • Support external key stores with KMIP Zoned security model SOE enforcement on instances • Mandate software packages that can’t be removed/changed • Native integration with virtual and physical firewalls including AWS Security Groups • Embed agents and utilities to secure instances (HIDS, AV, etc.) Secure access • Identity management (AD, LDAP, SAML) • Deny remote root access to machines, create user accounts by default • Proxy all guest access requests through Agility Platform to enforce policies • Workloads across hybrid clouds can join AD domains using policies Secure logs for auditing Secure data in transit • Secure VPN tunneling with AWS CGW and VGW • Proxy integration • Virtual DHCP Secure data at rest • Runs on AWS EBS • File system encryption • Deploy multitier apps components across different AWS VPC subnets (Web server to DMZ, etc.) Cloud A Cloud B … Cloud “n”
- 13. The Importance of Application Blueprints Design Develop Test UAT Operate git Platform Engineer Dev Blueprint Common Application Blueprint QA Blueprint UAT Blueprint Prod Blueprint Multitier applications of any size and scale that can be modeled and deployed to any AWS Region
- 14. How to model and orchestrate complex, multi-tier workloads Graphically design multitier applications and platforms Deploy infrastructure independent blueprints to AWS and on premise EC2, S3, EIP, EBS, others…
- 15. Design Develop Test UAT Operate SDLC Tool Chain: git Extensible, application-centric policy controls enable true self-service automation Cloud Management Platform Internal Private External Private AWS
- 16. a Use policies to provide both consistency and Customize Environment customization: Dev Security zone Dev VM quotas Dev chargeback Public cloud permitted No autoscaling No failover Customize Environment QA Security zone QA monitoring QA autoscaling Private cloud only QA backup/failover Customize Environment Prod Security zone Prod monitoring Prod auditing Prod autoscaling Private cloud only Prod backup/failover … And Enforce Consistency SOE packages App topologies Reg. compliance … And Enforce Consistency SOE packages App topologies Reg. compliance … And Enforce Consistency SOE packages App topologies Reg. compliance Policy Controlled Customization Policy Controlled Consistency Dev Blueprint QA Blueprint UAT Blueprint
- 17. Policy Policy Policy Policy Governance/Security Rights and Permissions Applications Roles Projects Orgs App Configuration Code/Artifacts Platforms Topologies/Configuration Services Application Components Infrastructure and SOE Security and Environment Configuration SOE Agents/Utilization OS and OS Configuration Network Compute Storage Regulatory compliance policies SLA policies including autoscaling Configuration management policies Security zones policies Lifecycle event policies Orchestration policies Access control/entitlement policies Workload placement policies Quotas and scheduling Metering/chargeback policies Backup and failover policies Resource capacity policies Storage tier policies Much more … Cloud Management Platform
- 18. Develop Test UAT Operate git Promote with Code Dev Blueprint UAT Blueprint Prod Blueprint QA Blueprint Promote with Code Promote with Code Design Visual dashboard to promote code and environments across SDLC stages Customize lifecycle stages and approval processes Integrate with existing tool chains
- 19. Firewall Cloud Mgmt Platform 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 architectures Develop Test UAT Production git Platform Apps s Infrastructu re Web Servers App Servers Database Servers Firewall Load Balancer4 Maste r Slave Blueprint Web Servers App Servers Database Servers Firewall Load Balancer4 Maste r Slave Web Servers App Servers Database Servers Load Balancer4 Maste r Slave
- 20. Profile of a CSC Agility Platform and AWS Customer “We’ve gone from spending 50% of our operating budget on infrastructure to just 26%. A nearly 75% investment in apps and information rather than infrastructure – that’s huge.” (Wall Street Journal) Increase Innovation App updates/deployment up almost 3x, from 1,200 to 3,000 changes a month. Lowered Costs for “Keeping Lights On” Cut IT operations costs by $100 million a year. IT Budget Innovation Operations
Editor's Notes
- 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
- 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??
- 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.
- 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..
- 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
- 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.
- 10
- 11
- 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)
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.