We often think of the software deployment process as a minor detail. Something we do to support developers as they move from idea, to code, to production. But the deployment process impacts more than just developers. Did you know that your deployment strategy can make or break the success of your product?
The difficulty of the deployment process
Product teams currently deploying to a public PaaS such as Heroku find they don't need to worry about how their cloud infrastructure and deployment process works. They build code, push to Heroku, and the magic happens. However once more customers onboard, this uncertainty becomes a risk. And then eventually, teams decide to move off of a public PaaS for reasons of risk, cost, and/or flexibility.
The problem is, moving away from a public PaaS can be challenging. Moving to an infrastructure provider, such as AWS or Azure takes time and expertise that isn't always available within the team. Even if the skills are available, the work is often left in the hands of a handful of people who know how to make it all work. Cloud infrastructure becomes a distraction to the day-to-day needs of product development. Worse, if these experts leave the team, then it requires considerable time to close knowledge gaps, resulting is lost time and revenues.
The impact of deployment across the team
Designing and building a robust deployment process can have a positive or negative impact on a variety of team members:
Developers : Developers just want to deploy code easily at the start of product development, while having the flexibility to grow as the solution grows. We discussed this in-depth in a previous article.
QA : For product teams with QA staff, they need to ensure the QA environment is the same as production, to prevent surprises once applications are deployed. If tests pass in QA but fail in production, their trust is reduced in the eyes of the team. If the team uses feature branches, being able to spin up a replica of production easily and confidently is important for properly testing upcoming releases.
Ops : Developers and operations must be able to cooperatively focus on monitoring, performance improvement, and simply keeping things running. Great operations teams are often security-minded and need to know how the infrastructure meets the security and regulatory requirements of the business. This requires deeper knowledge of how things go together than most public PaaS vendors can provide.
Business : Business teams - unless they have an operations background, typically don't understand operations and server configuration. They just want to see solutions pushed to production and the resulting happy customers. They may also prefer to see a multi-cloud failover strategy, based on articles they've seen regarding cloud infrastructure outages. This isn't easy for ops teams to build without considerable investment of time and resources.
Customers : Customers want products that are reliable. This translates internally as high uptime, failover, and meeting SLAs. Additionally, customers want features quickly. The longer it takes for teams to deliver new features, the more likely customer churn will become an issue.
The slippery slope of DevOps
DevOps can become a slippery slope, as many product teams and development agencies have found out. What starts off as a single checklist item to deploy the custom application, becomes much more complex. From managing servers to launching auto scale groups, load balancers, deploying code and migrating database schemas - there are a lot of steps to orchestrate a deployment.
Is this what you want your company to focus on: devops and cloud infrastructure orchestration? Or, would you prefer your team to skip this step and focus on product delivery?
No scripting required
What's required is something between IaaS and PaaS. Something that provides the flexiblity of an IaaS, but with the rapid deployment capabilities similar to a public PaaS. DevOps-as-a-Service may be the answer. It offers a blend of multi-cloud support, server and ops automation, and customization that can meet the needs of the team.
DevOps-as-a-Service solutions such as that offered by Cloud66, have both server-based and container-based deployment capabilities. This provides easy deployment for traditional Rails applications, as well as emerging microservice architectures. Failover capability to other cloud infrastructure providers reduces the risk of downtime, and with no additional scripting needed, you're free from distractions to focus on product development.