Cloud VDI – Bob Winding (Notre Dame)
Use cases they looked at:
- Classes that need locally installed software
- Application delivery instead of high-end lab machines
- Workstations for researchers wher the whole project is in the cloud
- NIST 800-171, ITAR, etc
- Heavyweight, graphics and processing-intensive work
Looked at: Workspaces (AWS); Microsoft RDP and RDP Gateway, Fra.me, Ericom Blaze and Ericom Connect
Performance is everything – did tests with PTC Creo, Siemens NX10, and Solidworks. Set up test environment in Oregon. Nobody in central IT knew how to operate the software. Found in almost every case that the remote setup was beating the local desktop performance. In some cases, local environment crashed under load, but in AWS loaded in under 2 minutes. (G2X.large).
Researchers observed that they can transfer
Cloud Governance – Do You Need a CLoud Center of Excellence? Laura Babson (Arizona)
a group that leads an organization in an area of focus
Establish best practices, governance, and frameworks for an organization
Applications vs Operations – what do you about tagging, automation, monitoring, security, etc. Don’t want to end up with different ops solutions for different applications.
CoE can help streamline decision making. CCoE can make decision if funding isn’t required, or make a recommendation to a budget committee if funding is required.
Recent decision making: Account strategy – how many and where to put each workload? Campus to Cloud Connectivity’ Monitoring; Tagging policy
Can help with communication and engagement across the organization
AWS CloudFront – Gerard Shockley (Boston U)
What is a CDN? geographically dispersed low latency, high bandwidth solution for distributing http and https.
Terminology: Distribution (rules that control how cloudfront will access and deliver content); Origin (where the content lives)
Only works with publicly visible infrastructure at AWS
Easy to get metrics and drill down into specifics
DevOps != DevOps – Orrie Gartner (Colorado)
Brought a new data center online 3 years ago to consolidate IT across campus, built a private cloud
Ops and Devs teams work close together, automating everything, fine with accepting higher risks, building strong relations between teams, performing continuous integration and deployments.
Didn’t go well this summer moving to the public cloud – lack of understanding of vision and goals from other silos.
Ensure the entire enterprise strives for the same end goal, communicates that goal
Created a vision and articulated cloud strategy. 6 phase roadmap to to public cloud, includes embracing DevOps culture. Line in strategic plan – encourages every team to articulate how they will embrace DevOps concepts.
Educate Up. Educate Laterally. Educate Down.
Change is not easy – changing culture in the organization. Prosci ADKAR – model embraced for making organizational change. Small steps, like encouraging process folks to use Jira, the same tool used by the devs and ops folks.
Us versus Them – a View From the Information Security Bleachers- David McCartney (Ohio State)
Security is not the enemy – they’re scared, unaware, and unprepared for the cloud.
Scared – “how can we stop you?”
Unaware – why move? what kind of data? what security is needed (vs. what you think you need)? what did we do to deserve this?
Unprepared – How do current security services expand? What do you mean “no agent”? Logging? Auditing? Access management? Vulnerability scans? incident response? What about regulatory and framework requirements?
Model Us + Them – Embrace security, buy them booze.
Engage security early, sell the opportunity to do something new and exciting, provide options for training and guidance.
MCloud: From Enable to Integrate – Mark Personett (Michigan)
MCloud is an umbrella service. Strictly IaaS – currently offering AWS, but might mean others later
First iteration launched in 2014 – access to UM enterprise agreement, optional consolidated billing; data egress waiver; M Cloud Consulting Service
Working on launching M Cloud AWS Integrate: provisioning – private network space, shibboleth integration, etc; Guardrails – security best practices, common logging, reporting, etc; Foundational services in AWS – AD, Shib, Kerb, DNS, etc; Site to Site VPN services.
Azure Remote App – Troy Igney (Washington U in St. Louis)
two core requirements when enrollment in second year CS class spiked. Needed Visual Studio. New computers too expsensive. On prem VDI – too expensive. Off Prem VDI – Azure Remote App.
Goal – deliver consistent development environment across a range of BYOD devices.
Challenges: Support an entire class’s logons at once. Required Micsrosoft off-menu configuration.
Advantages – template once and deploy, capacity costs based on current enrollment – dynamically adjust for enrollment changes.
Largest RemoteApp deployment directly supporting classroom delivery.
Microsoft dropped RemoteApp in favor of Citrix virtualization technologies.
Lots of lessons learned supporting remote VDI
Adopting Cloud-Friendly Architecture for On-Premise Services – Eric Westfall (Indiana)
Indiana primarily on premise with an increasing amount of SaaS. Have newer data centers and heavy investment in VMWare. Inevitable to get to hybrid environment, but in the meantime working to be prepared – “cloud-ready” app architecture.
12 factor principles
Object Storage (using S3 API in on-prem solutions)
Facilitating DevOps culture
Containerization – investing heavily in Docker. Adopting Docker Data Center
Hope it will allow to take advantage of existing infrastructure investments. Give dev and ops staff opportunities to experiment with cloud services. Allow modernization of app architecture and deliver practices. Prepare for inevitable future.
Cloud Initiative and Research – Steve Kwak (Northwestern)
Cloud Governance – October 2015. IT Directors from the schools and enterprise IT. Hired a consultant to help develop governance.
Cloud Architecture and COnsulting Team – April 2016 – 5 initial team members. set up initial environments at AWS and Azure. Worked through billing and accounts, and providing consulting.
Running cloud days and “open mic” sessions with AWS .
Research environments – 3 centrally managed – HPC (heavy upfront investment for dedicated compute, always a queue); Social Science cluster (aging infrastructure, limited support); Research data storage (separate storage from HPC). Looking to burst HPC to the cloud and move the other two.
Genomics pilot in AWS. Hire on a 3rd party team to put architecture together.
HPC Environment -working on targeting specific workloads in cloud with scheduler, and figure out bursting.
Controlled Approach to Research Computing in AWS – Paul Peterson (Emory)
Mindset of security team – need a similar set of controls in cloud as on-premise. This is quite challenging.
Started working to build Research Cloud. Collected 24 use cases and put them in three categories, divided into 2 VPC types. Worked with AWS professional services to build out VPCs. Pilot started this summer, going to end of year.
Type1 VPC- one availability zone, no Internet gateway – access only through Emory. Single sign-on with Shib.
Tpe2 has two availability zones, and an Internet gateway.
Goal of project team is to make requests for VPCs easy. Automation is key.
Generate VPC service. Created an inventory of accounts, LDS groups, Exchange distribution lists, and CIDR ranges.
Service gets next available account, adds admins to LDS group, creates SAML provider, Creates account alias, selects cloudfront template, get next available CIDR range Creates stack, compute subnets for account. Takes less than 5 minutes.
We Demand, On-Demand: Berkeley Analaytics Environments, VDI and the Cloud – Bill Allison (Berkeley)
Central IT budgets getting cut 10% year-over-year.
VDI use cases have been mostly around desktop pps, not research. Funded a pilot through December. User and use-case driven (faculty oriented) – need to tell story from a faculty perspective. Research IT group is like field workers, mst with PhDs.
Analytics Environment on Demand – not a change in the way you compute, at least on the surface. Use the skills you know already. Creating an abstraction layer.
Art of Letting Go – Relationship advice for dev and ops in the cloud – Bryan Hopkins (Penn)
Team lead for cloud app dev team. Cloud First program – replace homegrown frameworks with off the fhelf frameworks; replace waterfall with agile; replace monliths with integrations and composed apps
Three things we’ve learned so far: 1. Have a clear try-and-scrap phase in R&D – give it leeway. 2. Accept that interests and traditional roles will collide. Dev team can help with platform tasks, ops team can help with dev. Everyone cares about Jenkins. Bring them together. 3. Let go of notions of perfection and clean lines. Off-the-shelf means you get what’s on the shelf.