Transitioning from a public PaaS involves more than just setting up a server. It involves two key functions: provisioning the infrastructure and implementing the deployment process. It may seem easy, especially with the abundance of DevOps tools that exist today. But what we fail to realize is building a complete deployment solution requires a long process of scripting and server automation to reach the customized environment your product needs. In order to better understand the steps involved, let's look at the components required for automating the deployment process:
Step 1: Provisioning infrastructure
Before you can automate the deployment process, your infrastructure needs to be provisioned. Provisioning involves the full lifetime of the infrastructure, from initial setup to scaling up and down the resources required to support the current application load. It includes the following components:
Server provisioning and management : Provisioning servers to meet the application under current load is essential. This generally involves creating and monitoring auto scale groups that are connected to load balancers (below). This also includes operating system configuration and update management when security patches are released.
Container management : For those choosing to deploy their applications via containers, container instances must be managed and services deployed must be registered. This adds a layer of complexity on top of server management, especially when some servers offer specific capabilities that others don't (e.g. servers offering GPU processing) resulting in specialized container deployment requirements.
SQL and NoSQL database support : Your infrastructure must support launching new database instances for your applications and services, including vendors such as MySQL, PostgreSQL, MongoDB, Redis and ElasticSearch. These services may involve just a single instance, or may require high availability and failover that's managed internally or by the infrastructure provider.
Traffic load balancing : Web and inter-container traffic must be balanced across infrastructure through load balancers native to your cloud provider, or by using a solution such as HAProxy. They must be automatically configured and managed, as servers and containers are created and destroyed.
Networking and firewall configuration : For increased security, product infrastructure must provision and manage network security with fine grained access control (ACL) at the service level to prevent unauthorized access.
Network storage services : Managed storage (NAS) and block storage for shared filesystems offer distributed file storage to servers and containers and will need to be provisioned at the same time.
Step 2: Implementing the deployment process
Once you have automated your infrastructure provisioning and management, the deployment process can then be customized through automation:
Deploy image creation : This includes building container images with your code, tarballs, .yum, and .deb packaging.
Multi-cloud support : To avoid vendor lock-in, multiple cloud vendor support will be required. You'll need to be able to choose from two or more providers, including Amazon Web Services, Google, Azure, Rackspace, Digital Ocean, and Linode to name a few.
Continuous release support : To support a public PaaS-style deployment, it's common to build scripts that initiate deployment processes based on a git commit hook. You'll also need to determine if you want to support blue-green deployments, rolling deployments, or opt for scheduled downtime to deploy updates. Be sure to provide full visibility on every step, to help with troubleshooting failed deployments.
Multi-datacenter networking with service registry : From internal applications to container-based service discovery, your application will need a private DNS service with all registered resources. This often requires automation from the continuous release process to keep things in sync and to properly configure applications during deployment.
Backup and replication : Ensure your databases are backed up on-site and off-site or across cloud vendors. Automated restoration is necessary to prevent mistakes during crisis situations, such as a cloud provider outage.
Failover groups : What happens when a cloud vendor or zone goes down? You'll need to automate failover to a new zone, region, or cloud provider. This will depend on infrastructure provisioning to rebuild the necessary resources, and a proper restoration process for data recovery.
Network, server, OS, and container monitoring : Implement resource monitoring to notify you about any security issues or outages. This will keep your team informed and ensure that problems are addressed before your customers have a chance to report the issue to you.
Centralized logging for troubleshooting : Adding centralized logging is necessary to view behavior across servers and containers that may be created and destroyed at any time. By centralizing the logging across all resources, troubleshooting becomes easier.
Step 3: Profit
As you've probably realized, implementing a deployment process with continuous release support requires coordinating a large number of processes. Each step in the process requires automation scripting and oversight. According to a recent report, downtime can cost a company $100,000 or more during an outage. DevOps can help to avoid this loss through automated failover.
The hidden cost of DevOps in the deployment process
Automating the deployment process to support continuous releases can be very beneficial, with DevOps a key part of it. It's important to note however the cost of implementing DevOps, particularly for smaller product teams who are just getting started. Depending on the needs of the company, it could result in an investment of $100-400k+ in expenses to fully automate the process as described above.
As a result, many teams are considering the move away from in-house DevOps to a DevOps-as-a-Service model. This is an approach, which allows companies to outsource much of the infrastructure and deployment automation, freeing them to focus on what really matters: developing the product offering.