RackN was founded by leading cloud innovators to solve the complexities and challenges in orchestration, automation and scale for enterprise Hybrid IT infrastructure.

Feel Free To contact Us


Hours of Operations: M-F 8am-6pm Central Time US

+1 (484) 272-2562

info@RackN.com

Support: support@RackN.com

Top

Making Server Deployment 10x Faster – the ROI on Immutable Infrastructure

Making Server Deployment 10x Faster – the ROI on Immutable Infrastructure

Author’s note: We’re looking for RackN Beta participants who want to help refine next generation deployment capabilities like the one described below.  We have these processes working today – our goal is to make them broadly reusable and standardized.

We’ve been posting [Go CI/CD and Immutable Infrastructure for Edge Computing Management] and podcasting [Discoposse: The Death of Configuration Management, Immutable Deployment Challenges for DevOps] about the concept of immutable infrastructure because it offers simpler and more repeatable operations processes. Delivering a pre-built image with software that’s already installed and mostly configured can greatly simplify deployment (see cloud-init).  It is simpler because all of the “moving parts” of the image can be pre-wired together and tested as a unit.  This model is default for containers, but it’s also widely used in cloud deployments where it’s easy to push an AMI or VHD to the cloud as a master image.

It takes work and expertise to automate building these immutable images, so it’s important to understand the benefits of simplicity, repeatability and speed.

  • Simplicity: Traditional configuration approaches start from an operating system base and then run configuration scripts to install the application and its prerequisites.  This configuration process requires many steps that are sequence dependent and have external dependencies.  Even small changes will break the entire system and prevent deployments.  By doing this as an image, deploy time integration or configuration issues fare eliminated.
  • Repeatability: Since the deliverable is an image, all environments are using the exact same artifact from dev, test and production.  That consistency reduces error rates and encourages cross-team collaboration because all parties are invested in the providence of the images.  In fact, immutable images are a great way to ensure that development and operations are at the table because neither team can create a custom environment.
  • Speed: Post-deployment configuration is slow.  If your installation has to pull patches, libraries and other components every time you install it then you’ll spend a lot of time waiting for downloads.  Believe it or not, the overhead of downloading a full image is small compared to the incremental delays of configuring an application stack.  Even the compromise of pre-staging items and then running local only configuration still take a surprisingly long time.

These benefits have been relatively easy to realize with Docker containers (it’s built in!) or VM images; however, they are much harder to realize with physical systems.  Containers and VMs provide a consistent abstraction that is missing in hardware.  Variations in networking, storage or even memory can cause images deployments to fail.

But… if we could do image based deployments to metal then we’d be able to gain these significant advantages.  We’d also be able to create portability of images between cloud and physical infrastructure.  Between the pure speed of direct images to disk (compared to kickstart or pre-seed) and the elimination of post-provision configuration, immutable metal deploys can be 5x to 10x faster.  

Deployment going from 30 minutes down to 6 or even 3.  That’s a very big deal.

That’s exactly why RackN has been working to create a standardized, repeatable process for immutable deployments.  We have this process working today with some expert steps required in image creation.  

If this type of process would help your operations team then please contact us and join the RackN Beta Program with advanced extensions for Digital Rebar Provision.

Note: There are risks to this approach as well.  There is no system wide patch or update mechanism except creating a new image and redeploying.  That means it takes more time to generate and roll an emergency patch to all systems.  Also, even small changes require replacing whole images.  These are both practical concerns; however, they are mitigated by maintaining a robust continuous deployment process where images are being constantly refreshed.

No Comments

Post a Comment