Defining our Practices: Everything as Code


Everything as code

At MedStack, we run a lot of infrastructure.

With an engineering team of currently four, plus a part-time contractor, we have > 100 managed database instances, > 200 virtual networks, and > 300 VMs. The only way we can manage all of this is via our prime directive of software development and operations: “Everything shall be code.” Specifically, our policy says: “Implement all operations activities as software development.” 

The goal is simple. Everything that is running in our systems should be created, updated, and destroyed with this process:

  1. Develop source code
  2. Mark the code as ready to deploy (e.g., merge to master)
  3. Everything else happens automatically (e.g., CI/CD)

It seems like a simple prescription. Unfortunately, with the current trend to “automate all the things,” there is a lot of jargon floating around in the cloud ecosystem, causing confusion and chaos. Many of the hot topic terms in tech right now have multiple definitions, often based on the specific tools being used.

For example, a collection of shell scripts could be called automation; DevOps could be a job title or a philosophy; using Terraform and Ansible could be Configuration as Code; Kubernetes might be required for GitOps; and maybe you need to be at Google to be an SRE. 

As a platform, MedStack Control goes beyond automation and GitOps. It uses Docker as the basis and provides a set of interfaces to manipulate Docker clusters. In fact, the vast majority of the VMs, networks, and databases that we run aren’t defined in configuration files — they are created by our customers through UI or API, are defined in a database, and are created, updated, and destroyed not through a CI/CD pipeline but through our platform code using the Docker codebase.

Then there is the gap between goals and reality. We still have a lot of work to do; which for the right people, is an interesting opportunity with challenges and rewards. We want to do more self-hosting — “running MedStack Control on MedStack Control”. We may introduce Kubernetes into our internal tech stack, not because it’s the hot tool right now, but because we need certain features it excels at providing. We are scaling rapidly, which means we need to continue to invest in pragmatic long term thinking. Last year we were running 100 VMs; this year 300, next year it could be 600 or 1000. So, we can’t afford to be distracted by fads. We need to build systems and tools that work, and to do that, we study the classics, attend the conferences, do the research to get to the core behind so-called best practices. And then, we make our own informed decisions about what tools we need, what to do, how to do it – now and over the coming years.

Of equal or perhaps greater importance, we are deliberately evolving the architecture of our systems to let us grow the engineering team in an intelligent way. We know we need more builders, more designers, more innovators to take us to the next level and the one beyond that. We are looking for collaborators who want to use the right technology to build exciting, resilient, scalable systems, where everything is code. 

Our team is growing, and we’re hiring for multiple roles including an Intermediate Software Engineer and Senior Backend Developer. If you want to join our dedicated team and use your skills to help better the healthcare industry – visit our careers page or follow us on LinkedIn to learn more about us and our opportunities.