Page 45 - MSDN Magazine, October 2017

Developer
App Code
App Dependencies Base OS
App Code (Trunk)
App Code
Mounted Directory
Continuous Integration
App Dependencies Base OS
App Code App Dependencies Base OS
Production
Persistent Data
App Code App Dependencies Base OS
a persistent data layer and a routing layer. At Bitnami, we’ve spent a lot of time thinking about these lay- ers and how they affect each open source application, especially those that are usually used as open source building blocks for others, such as databases and language frameworks.
Layer 1: Volatile Deployments are now disposable images, which get thrown away at each deployment and replaced with a freshly built one. That makes the code and all the data it writes locally disposable. You should be prepared to delete and replace any of these instances at any point in time. These effectively become stateless servers.
Layer 2: Persistent Data This is where you’ll store your important databases, user files, session state and anything else that’s important to keep around. You’ll want to store service and system logs at this lay- er for compliance and debugging purposes, as well. It can be hard to ensure that no single point of fail-
App Code App Dependencies Base OS
Continuous Deployment
Bake an Image
App Code App Dependencies Base OS
Run Tests
App Code App Dependencies Base OS
Figure 2 The Optimized Production Cycle
The Immutable Ladder
ure exists in this layer, so cloud Software-as-a-Service solutions can come in handy to address these concerns. This layer should be robust, highly available and fully backed up.
Layer 3: Routing Once you have a volatile layer, you need a pre- dictable and addressable layer for external users and other services to access your services. You’ll need to have predictable public IP addresses and domain names, decoupled from the volatile servers running your code and able to forward requests to a flexible pool of servers.
Wrapping Up
The take-away for developers is clear: Building and running immutable services provides enormous benefits across the pipe- line from development and build to production. With each step you take on the immutable ladder, your existing services gain extra benefits and advantages.
Immutable infrastructure at its heart is about full automation of deployments and enforcing a process that guarantees—to the max- imum extent possible—what’s running on your servers. Step 0 is the place to start. Even if you only walk up that first step, your cloud work- loads will be in a much better situation than they were before. n
Martin albisetti is a senior architect for Bitnami and was previously director of engineering at Canonical (Ubuntu). Albisetti spends his free time working with his hands in rural Uruguay, where he lives with his family. You can find him on Twitter: @beuno.
thanks to the following Microsoft technical expert for reviewing this article: James McCaffrey
Now that your infrastructure is immutable, your development-to- production cycle will be optimized, seamless and much more fluid, as shown in Figure 2.
Public clouds are generally built to be less reliable than datacenters, because they share underlying resources with potential noisy neighbors. In exchange, you can automatically scale and shut down resources in response to changes in demand. This arrangement means you should optimize for instances to be shut down and replaced. The more your instance scales, the more the investment in automation pays off, because you’ll need to spin up instances more frequently. You’ll find that optimizing your instances becomes a much more seamless process, enabling you to focus on development rather than handholding deployments.
To quote Sylvester Stallone in the movie “Rocky Balboa”: “It hurts now ... but, one day, it’ll be your warm up.” As you start at step 0 of the immutable ladder, you may have to remind yourself that the pain is worth the gain. But the gain is considerable. An immutable approach allows you to make sure that things work well before they go to production, rather than discovering issues after OSes, frameworks, runtimes and application code have a chance to work against each other in a live fire deployment. Now more failures can be discovered and dealt with “on the ground” before deployment, rather than in the air when your environment is up and running.
The 3 Layers
Once you’re producing an image per deployment, you’ll want to think about your system architecture as having three layers: a volatile layer,
msdnmagazine.com
October 2017 41