Infrastructure as Code offers a trifecta of advantages: consistency, faster deployment, and improved security – three things all of us working in healthcare in 2020 are trying to get a stronger grip on.
For any organization making the cloud transformation journey, consistent automated deployments are an important foundational element. In highly regulated verticals like healthcare and life sciences, adopting a pattern like Infrastructure as Code can also have significant benefits in terms of change control, environmental/workload drift detection, and separation of duties.
With Infrastructure as Code, the code is written into a repeatable template and can be read by machines and humans alike. So, rather than some well-intentioned member of an IT team walking over and making some configuration tweaks that may or may not get accurately documented in all of the right places – an action that can have profound downstream effects on your security – Infrastructure as Code provides consistency because the same code is repeated each time you deploy, without human error.
When we are talking about change control, organizations have the ability to use the templates themselves as part of the change control documentation and perform code-like peer review before a change is proposed. The Infrastructure as Code tools become the backbone of the Method of Procedure for the change, the rollback strategy, and verification process. Infrastructure as Code tools almost always capture their template files in an explicit declarative manner, which can provide an advantage to folks supporting the change control process because it provides an important “snapshot” into the desired state of the infrastructure. Often these tools can even tell you exactly what changes they would make to the target environment as it exists today to achieve the desired state in the template – making catching nuanced mistakes in complex environments easier when reviewing the automated action plan.
The idea of capturing infrastructure configuration in a template and allowing repeated deployments of approved templates is a well-worn pattern in the enterprise space. For a lot of organizations, this process is contained in a Service Catalog and the move to Infrastructure as Code will change the delivery of those deployments – but the value to the end users and organization is much the same.
For many healthcare organizations, the more significant benefits are seen through building more consistency into the processes.The other advantage requires a major mindset shift that might not be obvious, and that is that Infrastructure as Code can support both reproducible, repeated build and entirely unique one offs with an almost identical process. Very few organizations capture one off customized deployment in Service Catalogs but capturing them in Infrastructure as Code is natural, whether the workload will be deployed once or thousands of times.
In the traditional IT world, silos and differing toolsets can slow progress and efficiency. We frequently split the responsibility of expressing desired state in one tool (such as a Service Catalog) and evaluating the current state in another with CMDBs (Configuration Management Databases). In many ways the Infrastructure as Code tool can unify a large segment of these responsibilities into a single workflow. Different humans can perform the same task with minor variability resulting in minor differences in the deployment.
For healthcare, inconsistent deployment and human variability can have a huge impact on security and compliance of the application, and Infrastructure as Code helps provide consistency which in turn helps ensure better security and protection of sensitive healthcare data.
And as far as divisions of duties or permissions, many of us operate with regulations or policies that require different teams to perform different segments of the deployment process. This can be because of restrictions with developers interacting with live or sensitive data and production, or to mitigate some of the risk presented by a single bad actor. In an Infrastructure as Code world, the development team can make a change request including an appropriate infrastructure as code template – and that change can be reviewed, processed and executed by a separate operational team with minimal risk that something is misunderstood or lost in translation.
As healthcare continues its journey to maturity in the cloud, integrating Infrastructure as Code is a very natural step.
The need to manage more workloads with less cost and move quickly to keep up with the needs of the “core business” is an almost universal truth among the IT executives in healthcare. The Infrastructure as Code path provides real benefits to organizations that make the investments, not just in term of a technical workflow but in terms of the organizational culture. Talking about, considering and deploying infrastructure changes the same way software engineers do for application code changes is a powerful experience. It allows the team to involve stakeholders, preform reviews, and drive consensus earlier in the process of planning infrastructure. This is all part of building a robust DevOps practice in your IT organization, and in the next couple years, those who are not practicing Infrastructure as Code are going to be at a considerable disadvantage.
One of the critical initial decisions you make with Infrastructure as Code is choosing the template language you want to use. Each of the public commercial clouds that ClearDATA supports has an Infrastructure as Code templating format that is specific to that cloud – AWS, Azure and Google Cloud Platform. We increasingly see organizations wanting to go multi-cloud, and many are opting to leverage tools like Terraform which can be used universally across all three clouds. ClearDATA is assisting our customers with Terraform templates and pre-built modules as one of many services we offer as they learn to take advantage of the speed and agility the cloud offers.
