{"id":670,"date":"2018-10-21T20:06:36","date_gmt":"2018-10-21T20:06:36","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=670"},"modified":"2018-10-22T22:19:25","modified_gmt":"2018-10-22T22:19:25","slug":"welcome-to-the-era-of-immutable-infrastructure","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2018\/10\/21\/welcome-to-the-era-of-immutable-infrastructure\/","title":{"rendered":"Welcome to the Era of Immutable Infrastructure"},"content":{"rendered":"

With the recent \u201ccontainer revolution,\u201d a seemingly new idea became
\npopular: immutable infrastructure. In fact, it wasn\u2019t particularly new,
\nnor did it specifically require containers. However, it was through
\ncontainers that it became more practical, understandable, and got the
\nattention of many in the industry. So, what is immutable
\ninfrastructure? I\u2019ll attempt to define it as the practice of making
\ninfrastructure changes only in production by replacing components
\ninstead of modifying them. More specifically, it means once we deploy a
\ncomponent, we don\u2019t modify (mutate) it. This doesn\u2019t mean the component
\n(once deployed) is without any change in state; otherwise, it wouldn\u2019t
\nbe a very functional software component. But, it does mean that as the
\noperator we don\u2019t introduce any change outside of the program\u2019s
\noriginal API\/design. Take for example this not too uncommon scenario.
\nSay our application uses a configuration file that we want to change. In
\nthe dynamic infrastructure world, we might have used some scripting or a
\nconfiguration management tool to make this change. It would make a
\nnetwork call to the server in question (or more likely many of them),
\nand execute some code to modify the file. It might also have some way of
\nknowing about the dependencies of that file that might need to be
\naltered as a result of this change (say a program needing a restart).
\nThese relationships could become complex over time, which is why many CM
\ntools came up with a resource dependency model that helps to manage
\nthem. The trade-offs between the two approaches are pretty simple.
\nDynamic infrastructure is a lot more efficient with resources such as
\nnetwork and disk IO. Because of this efficiency, it\u2019s traditionally
\nfaster than immutable because it doesn\u2019t require pushing as many bits
\nor storing as many versions of a component. Back to our example of
\nchanging a file. You could traditionally change a single file much
\nfaster than you could replace the entire server. Immutable
\ninfrastructure, on the other hand, offers stronger guarantees about the
\noutcome. Immutable components can be prebuilt before deploy, and build
\nonce and then reused, unlike dynamic infrastructure which has logic that
\nneeds to be evaluated in each instance. This leaves opportunity for
\nsurprises about the outcome, as some of your environment might be in a
\ndifferent state that you expect, causing errors in your deployment.
\nIt\u2019s also possible that you simply make a mistake in your configuration
\nmanagement code, but you aren\u2019t able to sufficiently replicate
\nproduction locally to test that outcome and catch the mistake. After
\nall, these configuration management languages themselves are complex. In
\nan article from ACM Queue<\/em><\/a>, an Association for
\nComputing Machinery (ACM) magazine, engineers at Google articulated this
\nchallenge well:<\/p>\n

\u201cThe result is the kind of inscrutable \u2018configuration is code\u2019 that
\npeople were trying to avoid by eliminating hard-coded parameters in
\nthe application\u2019s source code. It doesn\u2019t reduce operational
\ncomplexity or make the configurations easier to debug or change; it
\njust moves the computations from a real programming language to a
\ndomain-specific one, which typically has weaker development tools
\n(e.g., debuggers, unit test frameworks, etc).\u201d<\/p><\/blockquote>\n

Trade-offs of efficiency have long been central to computer engineering.
\nHowever, the economics (both technological and financial) of these
\ndecisions change over time. In the early days of programming, for
\ninstance, developers were taught to use short variable names to save a
\nfew bytes of precious memory at the expense of readability. Dynamic
\nlinking libraries were developed to solve the space limitation of early
\nhard disk drives so that programs could share common C libraries instead
\nof each requiring their own copies. Both these things changed in the
\nlast decade due to changes in the power of computer systems where now a
\ndeveloper\u2019s time is far more expensive than the bytes we save from
\nshortening our variables. New languages like Golang and Rust have even
\nbrought back the statically compiled binary because it\u2019s not worth the
\nheadache of dealing with platform compatibility because of the wrong
\nDLL. Infrastructure management is at a similar crossroad. Not only has
\nthe public cloud and virtualization made replacing a server (virtual
\nmachine) orders of magnitude faster, but tools like Docker have created
\neasy to use tooling to work with pre-built server runtimes and efficient
\nresource usage with layer caching and compression. These features have
\nmade immutable infrastructure practical because they are so lightweight
\nand frictionless. Kuberentes arrived on the scene not long after Docker
\nand took the torch further towards this goal, creating an API of \u201ccloud
\nnative\u201d primitives that assume and encourage an immutable philosophy.
\nFor instance, the ReplicaSet assumes that at any time in the lifecycle
\nof our application we can (and might need to) redeploy our application.
\nAnd, to balance this out, Pod Disruption Budgets tell Kubernetes how the
\napplication will tolerate being redeployed. This confluence of
\nadvancement has brought us to the era of immutable infrastructure. And
\nit\u2019s only going to increase as more companies participate. Today\u2019s
\ntools<\/a> have made it easier than ever to
\nembrace these patterns. So, what are you waiting for?<\/p>\n

About the Author<\/h3>\n

\"\"William Jimenez
\nis a curious solutions architect at Rancher Labs in Cupertino, CA, who
\nenjoys solving problems with computers, software, and just about any
\ncomplex system he can get his hands on. He enjoys helping others make
\nsense of difficult problems. In his free time, he likes to tinker with
\namateur radio, cycle on the open road, and spend time with his family
\n(so they don\u2019t think he forgot about them).<\/p>\n

Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

With the recent \u201ccontainer revolution,\u201d a seemingly new idea became popular: immutable infrastructure. In fact, it wasn\u2019t particularly new, nor did it specifically require containers. However, it was through containers that it became more practical, understandable, and got the attention of many in the industry. So, what is immutable infrastructure? I\u2019ll attempt to define it … <\/p>\n

Continue reading “Welcome to the Era of Immutable Infrastructure”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-670","post","type-post","status-publish","format-standard","hentry","category-kubernetes"],"_links":{"self":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/670","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/comments?post=670"}],"version-history":[{"count":1,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/670\/revisions"}],"predecessor-version":[{"id":677,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/670\/revisions\/677"}],"wp:attachment":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/media?parent=670"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/categories?post=670"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/tags?post=670"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}