To Cloud or Not to Cloud? Project Setup and System Administration
So you've got your project management methodology and you've had a kickoff, now it's time for the team to get to work. What does a developer do on their first day of a new client project?
Decisions made here will affect how your team collaborates, how you get feedback from your client, do QA, and eventually launch the site. You’ll need to determine the development infrastructure for the project, which can be simple or complex. You can have a generic LAMP server for every project or project-specific environments that perfectly mirror the production site. Similarly, your controls over who is able access those environments can be rough or fine-grained. And, with any of these combinations, you’ll need to decide on who is ultimately responsible for making sure that things work now and in the future. Finally, you’ll need to have a way to securely manage sensitive information related to your work, such as access credentials and API keys.
There are a few common patterns we see in terms of how agencies handle managing their environments:
Laissez Faire: You’ve already agreed what CMS to use, the stack of contributed code, and what frontend framework to use for the theme; what else is there to do? Everybody already has their own favorite tools, and at this point the client has no idea where the site is launching, so let’s just everybody get to work already. This is the default for most newer agencies, which often form as a small group of people who’ve all developed their own best practices from their career to date. Some will be running Linux on their desktop (or maybe MAMP), others will have a cloud server or two they use for development purposes. It’s great to have everyone bring their own expertise to the table, and this approach avoids early overhead, but it often creates downstream chaos if multiple team members need to collaborate. This approach is only good if projects can be handled by a single team member, and client input along the way is minimal. Otherwise this can quickly turn into a Wild West stampede to Cowboy Coding, and just isn’t sustainable.
Shared Development Server(s): Agencies will often create a shared/canonical development environment for a project. This has the benefit of living online, which is key for collaboration and coordination, and for sharing work in progress with a client. With an online shared development environment comes responsibility for upkeep and maintenance. Someone’s going to have to start playing sysadmin, which has a cost in terms of time for project setup and can pull senior technical resources off client projects. Additionally, developers might find themselves getting “blocked” by missing features or the stability of the shared development infrastructure—which often suffers from “the cobbler's children have no shoes” problem—or running into hangups or bugs if they are running their own local development and trying to synchronize with the shared online resources.
Local and Cloud Virtual Servers: It’s possible to use consistent virtual machine images for both local development, and in the cloud using tools like Docker, VirtualBox and VMWare. Agencies will often use another layer of tooling, like Vagrant, along with a modern configuration management system like Chef, Ansible, or Puppet. The goal here is to get each developer their own environment and avoid the “works on my machine” problems common in the Laissez Faire approach. That goal is much easier to meet when a dedicated and experienced sysadmin (or team of them) can maintain the virtual machines and scripts for everyone. Local and Cloud virtualization can fail when developers expert in web languages find themselves in over their heads on server config and have to debug a machine inside a machine. Or even a container suite inside a VM inside their native machine in the case of some setups.
Platform as a Service (PaaS): A Platform as a Service solution provides the same benefits of VM-based development but without the internal cost of maintenance and management. PaaS solutions also provide greater clarity and peace-of-mind around responsibilities. Well-established vendors in this category will have a single instance, multi-tenant platform controlled by software instead of individual sysadmins configuring different environments for each customer. As an added bonus, you can usually launch the production site on your PaaS as well, which means there’s no need to stress about transitioning to client infrastructure, or worry about the higher-risk sysadmin burden of maintaining and defending servers that run live websites.
Andrew Mallis, Co-founder, Kalamuna
Standardized development workflows across our client projects allows us to provide more value to more clients—by significant orders of magnitude. Hours otherwise wasted solving the same infrastructure problems in unique ways can be better spent on quality code and design to support the important missions our client partners are undertaking.
Once you have chosen your infrastructure you’ll need to control access to the code, files and data for each of those projects. These systems can range from simple scripts to deep integrations with a GUI management layer. In addition to securing the necessary resources it’s wise to also consider how much time and effort it takes to grant access.
Chris Teitzel, Founder & CEO, Cellar Door Media & Lockr
Every project is a microcosm within our company, and just like any community there are a wide variety of individuals inside, each with their distinct roles and functions. Clients have key personnel which need to be involved in the site management and content, developers need to be able to have the freedom to work in isolation without the fear of disrupting a production site, and project leads sit as gatekeepers when features and updates are ready to roll out. And like any community, things can get complicated in a hurry and even the smallest of details can get out of hand in no time without the right controls and processes in place. What keeps us all working together and driving the project to our goals are clear roles, responsibilities and, most importantly, access controls that prevent someone from causing issues, intentionally or not.
Technologies to consider include:
Single Sign On (SSO): When people have to manage dozens of usernames and passwords, the passwords tend to get simpler and more repetitive. SSO replaces the mess with a single set of credentials for multiple systems. Solutions like SAML, OAuth, Kerberos and OneLogin are a good place to start for SSO.
Two Factor Authentication (TFA): TFA adds an extra layer of security beyond passwords. It adds knowledge (something they know); possession (something they have), and/or inherence (something they are). For example, TFA allows you to use services such as Google Authenticator or OneLogin, where the possession of a mobile device registered to you is required to login.
You and your clients both expect to have secure websites. There are many layers to security.
Start by choosing a rock-solid host to deploy your projects.
Have procedures to rapidly deploy CMS security updates.
Use HTTPS and SFTP for all your projects.
Every project will deal with at least some sensitive information. You’ll need a policy to store and manage sensitive information such as access credentials and API keys. For password management, KeePass, LastPass, and 1Password are all great options. For API keys, a key management service like Lockr is a good idea.