As Cloud Architectures Grow Up, Migration and Portability Will Be Key Issues

Brian Loomis, Chief Technology Officer, MSU
Brian Loomis, Chief Technology Officer, MSU

Brian Loomis, Chief Technology Officer, MSU

Michigan State University is a land-grant research University, located in East Lansing, Michigan, with over 50,000 students and a faculty staff of over 3000. The mission of the University is to provide education to undergraduates, outreach through local healthcare organizations and 4-H clubs around the state, and provide state-of-the-art research facilities for advancing knowledge. Our information technology services organization provides a growing catalog of services to meet these myriad missions. One of the most pressing challenges is the transition from cloud consumption in a software-as-a-service model to a hybrid model where services are provided in the environment they fit best, which may change as technologies mature. A large number of the current teaching and learning systems are SAAS: from learning management systems like D2L and Canvas, to print services distributed across campus (managed from the public cloud), to student recruitment and alumni relations analytics solutions. The University also supports research and administrative workloads through an on-premise 10,000 sq. foot datacenter, and has recently entered partnerships with infrastructure-as-a-service cloud providers to extend business continuity and provide additional capacity. In the words of one of our architects, “IT is no longer about drawing what’s in a given box on the diagram, our job is the lines between the boxes, the integration of services.” Those services are now hosted in multiple environments, by multiple suppliers and partners such as other Universities or research organizations.

Having multiple cloud providers presents integration challenges, both at the API, or operational, level, and in the data reporting architecture. As a University, we may have multiple providers in a certain capability area – such as student success, the tracking of how students progress towards degrees and outcomes and identifying when counseling conversations might be required. Each application in a different cloud provider may have its own schema and reporting mechanism, but we often want these systems to talk to each other and share data both to coordinate a business process and also to provide holistic data insights to a program. For example, a student in one college may have grades and attendance information local to that unit’s application, but we need to combine that data with housing and meal plan data or mobility data to understand if a student needs additional support or even a simple check-in. The applications need to communicate events to each other and often API gateways (ESB) or application-provided APIs can help here; the solution architect often has to diagram the business process and draw out the detailed connection points. Each application may have its own dashboard for aggregate data – for instance, across a student population – which presents the second challenge to the architecture: data often needs to be combined in a data warehouse to provide overall statistics for a program, in this case a percentage of students progressing normally towards a degree. Where this data warehouse exists is a challenge to the process designer – do we use the on-premises data warehouse, create a new or cached version in a public cloud, or leverage one application provider’s built-in capability (effectively bolting on the other applications)?

 Having multiple cloud providers presents integration challenges, both at the API, or operational, level, and in the data reporting architecture 

Multiple cloud providers across the application-to-infrastructure stack similarly challenges the organization as we try to provide common identity management, business continuity, or strategic planning when new services come and old ones are retired over time. Supporting technologies often still have to be developed by the University and remain criteria for any provider, for items like identity management and access, business continuity, etc. As an example, we use a common Active Directory on premises, synced with Azure AD to provide IdM into most cloud “properties.” Similarly, technologies like search or workflow (IFTTT), or chatbots often require integration across multiple cloud and on-prem services in order to provide a common experience to the users regardless of where any given application exists in the portfolio. As services are evaluated across lifecycles, the ability of moving from one provider to another is important – migrating even a simple service like DropBox to OneDrive or Microsoft Teams is an exercise our build team executes routinely.

Workload planning and conversations with decision trees are critical to a multi-cloud discussion: which application or service will end up where is probably the earliest, and one of the most difficult questions our teams face. An academic unit may ask initially where they should host the department web site – a simple question with many possible outcomes: we can co-locate a physical machine in the datacenter, we might recommend moving it to a SAAS offering like SharePoint in Office 365, or later move it to a custom IAAS solution. The integrations often dictate the options and, in order to have flexible or often more than just one possible environment choice, typically force the application to be portable between environments. An integration may require constraints such as when the application has ties into central (read: unmovable) ERP systems. Data restrictions on research grants also complicate the architectural choices – HIPAA data at the hospital may be operational and needs to be stored separately from NIST or federal agency controlled data for a simulation. Finally, the research environment is often located in collections of institutions – most academic research is now undertaken not only across 2 or more universities, but also across multiple countries as well depending on where the investigators are and where lab equipment may be located.

MSU has embarked on our journey to the cloud and is extending the standard reference architectures to appropriately meet the demands of secure research computing, healthcare, and the student learners on campus. This focus on mission, the engagement of both cloud and architecture teams, and string engagement with our cloud partners helps us navigate the complexity and simplify the experience for our campus faculty and students. Having on-premises resources and multiple cloud providers drives the need for migration of workloads between environments and including portability as a primary concern in the architecture.

Brian Loomis is the Chief Technology Officer for MSU, where he leads the infrastructure department, teaching and learning technologies, and advanced research technology support groups. He partners with key stakeholders across the University to improve technology design, acquisition and adoption processes aligned with the research, teaching, healthcare and outreach missions of the University. Recent projects include standing up the new MSU datacenter, negotiating unit move-in packages, broadening WiFi access to the campus and dorms, building a health care partnership with a new hospital, creating an innovative research technology support function, and advising on ERP modernization. He sits on several permanent boards and working groups for the President and Board including critical infrastructure and teaching finance. Outside of MSU, he represents the University on Big Ten boards and on national next-generation skills panels for high-tech.

Read Also

Roadmap to the Cloud

Roadmap to the Cloud

Sergio Gallegos, Associate CTO, UCLA Health
The New Economics of IT in a Cloud-First World

The New Economics of IT in a Cloud-First World

Kaytek Przybylski, SVP, Technology Services, Avanade
Preparing for the Remaining 93 Percent of Office 365 Adoption

Preparing for the Remaining 93 Percent of Office 365 Adoption

Kamal Shah, SVP of Products, Skyhigh Networks