Page 43 - MSDN Magazine, October 2017

There’s also the benefit that comes with the “Everything”-as-a- Service model. Clouds offer most of the common services you’d want in modern Web software, including databases (SQL and NoSQL), HTTP front ends, load balancers, DNS, block storage, object storage, log analysis, monitoring, queues, AI and more. The list grows with each month. And clouds let you focus on your core business, by offloading common services to a provider.
Of course, everything comes at a cost. Adopting on-demand infrastructure means you forego reliability guarantees. An instance in the cloud could disappear or reboot at any time without warning. Likewise, failure modes can be impossible to reproduce. Erratic behavior can also occur. For example, a new instance might fail to boot or servers might experience slow disk IO or spiking CPU loads, with no clear cause.
Above the Clouds
Given the advantages and challenges of cloud deployments, immutable services are a perfect fit. Among the key benefits:
• Predictably deploy exactly the same bytes everywhere in the world.
• Launch dozens, hundreds or even thousands of new instances in response to demand, with little or no preparation.
• Build automatic error recovery into deployments. Misbehav- ing instances can be automatically shut down or removed from serving requests and left for later inspection and new ones brought up, that way debugging can happen whenever convenient instead of in the middle of an outage.
• Automate deployments by employing images that don’t have to be transformed after boot.
Beyond working well with clouds, there are many benefits to deploying your services immutably, from reduced complexity and speedier deployments to improved security and compliance.
Reduced Complexity If you have a basic set of three ser- vices, each with an average of four instances, you quickly end up with 12 pets. That’s a lot of pets to feed! You might argue that the four instances are all the same, and that’s probably how it started off, but you can see how over the period of six months each instance will have been upgraded, debugged and revived in different ways, no longer guaranteeing that they’re actually the same anymore.
By contrast, an immutable approach means that you have exactly one image. Each of the four instances will contain the exact same code at deployment time, configured
in the exact same way. Unless you change
Once images are built, deployments are as fast as you can bring up a server on a particular cloud, including rolling back a problem- atic change. Also, deployments become effectively atomic, letting you perform rolling or cluster-scale deployments while ensuring no half-state exists on any particular server.
Simpler Experimentation and Rollbacks A single image per deployment means you can create a short-lived experiment and destroy it once it’s complete. Experiments are also cheaper because you know you’re starting from the same base you have running in production, down to the last byte. This makes it easier to track the changes you’re trying to make.
Better Reproducibility Immutability ensures that the same code returns the same output in every laptop, every continuous integration (CI) and every server. There is no uncertainty as to what combination of code and configuration is being used. If you have to make changes to the environment or running images, you can easily redeploy from the same image to go back to a known-good state. This provides the closest thing to a “production-like envi- ronment,” given that the images themselves are produced every time you make a change.
Tighter Security and Compliance By baking an image each time, you know exactly what’s running on any server at any point in time, allowing you to audit a single artifact and ensure that’s what’s running everywhere. In extreme cases, you can use resources like the Docker read-only mode to ensure no subsequent changes were made to instances when they’re run.
Improved Disaster Recovery To create immutable infra- structure, you need to have a minimum level of automation in your deployments. When (not if) your infrastructure collapses, this improvement can allow you to recover in minutes instead of hours, days or weeks.
Climb the Immutable Ladder
Creating immutable services isn’t always easy, especially if your project was built on assumptions common to legacy datacenters— like being able to write anywhere on the file system or overwrite existing files for fast in-place upgrades. However, you can work toward an immutable service in just five steps, as depicted in Figure 1, with each step providing tangible benefits.
A climb all the way up the immutable ladder requires investment and patience, but you’ll see early benefits even with some small changes. Let’s explore the steps in an immutable services effort.
something afterward, you only have three different variations of the images to under- stand and worry about. Additionally, any drift that occurs while in production will be reset on each subsequent deployment.
Speedier Deployment Immutable deployments shift a lot of the heavy lifting (including downloading, compiling and validating) to the build stage, adding time to this phase of deployment but protecting against failures in production. msdnmagazine.com
Data App Code
Runtime (PHP) Base OS
Data App Code
Data Data App Code
Data
App Code Framework (Laravel) Runtime (PHP) Base OS
Framework (Laravel)
Framework (Laravel)
Framework (Laravel) Runtime (PHP) Base OS
App Code Framework (Laravel) Runtime (PHP) Base OS
Runtime (PHP) Base OS
Figure 1 5 Steps to Immutability
October 2017 39