{"id":2785,"date":"2019-09-03T10:05:19","date_gmt":"2019-09-03T14:05:19","guid":{"rendered":"http:\/\/www.soul-repairs.com\/blog\/?p=2785"},"modified":"2019-09-02T00:50:11","modified_gmt":"2019-09-02T04:50:11","slug":"applications-are-gold","status":"publish","type":"post","link":"https:\/\/soul-repairs.com\/blog\/2019\/09\/03\/applications-are-gold\/","title":{"rendered":"Applications are Gold"},"content":{"rendered":"<p>We&#8217;ve talked previously about how <a href=\"https:\/\/soul-repairs.com\/blog\/2019\/05\/16\/developers-drive-organizational-success\/\">developers drive organizational success<\/a>: they deliver the applications by which companies deliver their competitive advantages. <em>Because<\/em> they are a way for companies to deliver products to customers, those delivered applications are critically valuable. Application development is a lot like <a href=\"https:\/\/en.wikipedia.org\/wiki\/Gold_extraction\">extracting gold<\/a> &#8211; it creates <em>value<\/em> out of <em>raw resources<\/em>.<\/p>\n<blockquote><p>Application development is a lot like extracting gold &#8211; it creates <strong>value<\/strong> out of <strong>raw resources<\/strong>.<\/p><\/blockquote>\n<p>Gold,\u00a0<em>wealth<\/em>, needs to have some amount of protection.<\/p>\n<p><!--more--><\/p>\n<h2>Protection<\/h2>\n<p>Applications are made up of two kinds of assets: the <strong>code<\/strong> and the <strong>architecture<\/strong>.<\/p>\n<h3>The Code<\/h3>\n<p>Protecting the value inherent in <strong>code<\/strong>, or <em>what<\/em> the application does, is pretty simple (&#8230;but not always easy!). You want to house it in a standardized source control management (SCM) tool, with versioning, and you want to regularly make sure that it can <em>build<\/em> (be turned from raw source code into something that can actually\u00a0<em>run<\/em>\u00a0on a platform). SCM with versioning matters so that a) you don&#8217;t <em>lose<\/em> your source code (a horrible alternative to this would be the source code just hanging out on someone&#8217;s computer&#8230;) and b) if you make a change you didn&#8217;t mean to make, you can go back to an older version. SCM means that the code gets to continue to\u00a0<em>exist<\/em> &#8211; it&#8217;s the most fundamental of protections. The ability to build matters in part because it&#8217;s the only way to resolve a code vulnerability in an included library &#8211; basically, if you <em>need<\/em> to release a change to an application for some reason, building it is the first step after the code is changed, and the technical debt behind not building for a long time means that this can be a major bottleneck.<\/p>\n<p>Open source-based products are the best plan for vital enterprise tools, for reasons we&#8217;ll explain in another post &#8211; but for a SCM, that means using something <a href=\"https:\/\/git-scm.com\/\">Git-based<\/a>. The ability to build whenever you need to &#8211; or, said another way,<strong> releasing regularly and frequently &#8211;<\/strong> is solved via <a href=\"https:\/\/soul-repairs.com\/blog\/tag\/continuous-delivery\/\">continuous delivery<\/a>. Or&#8230;continuous delivery\u00a0<em>ish<\/em>. Just&#8230;release more than never, okay?<\/p>\n<h3>The Architecture<\/h3>\n<p>Protecting the value of <strong>architecture<\/strong>, or <em>how<\/em> the application does what it does, both now and in the future, is&#8230;less simple. The best thing to keep in mind is to make sure that the application can run <em>where<\/em> you want it to run, <em>how<\/em> you want it to run. Scalability (how well it responds to growth, usually referring to the number of users, the amount of data it interacts with, or the processing it has to do), cost (how much the platform costs to run the application), portability (the ability to run on more than one platform), and performance (how well it responds) are all important here. The best choice we (IT as a whole) know of today for scalability, portability, <em>and<\/em> performance (&#8230;and usually cost) is <a href=\"https:\/\/soul-repairs.com\/blog\/2019\/03\/05\/why-containers\/\">container technology<\/a>\u00a0 <a href=\"https:\/\/soul-repairs.com\/blog\/2019\/04\/25\/knative-what-is-it-and-why-do-i-care\/\">Serverless technology<\/a> is more scalable, and may be cheaper, but it&#8217;s still in its infancy and isn&#8217;t something most enterprises can support.<\/p>\n<blockquote><p>The best thing to keep in mind is to make sure the application can run <strong>where<\/strong> you want it to run, <strong>how<\/strong> you want it to run. The best choice we (IT as a whole) know of today to accomplish this is <a href=\"https:\/\/soul-repairs.com\/blog\/2019\/03\/05\/why-containers\/\">container technology<\/a>.<\/p><\/blockquote>\n<h3>Platforms<\/h3>\n<p>If applications are gold, then platforms, or where you <em>run<\/em> those applications, end up a lot like banks&#8230;if banks took gold directly. You need somewhere to store your gold, ideally where it&#8217;s still accessible and <em>usable<\/em> &#8211; because running around with bars of gold in your pocket isn&#8217;t entirely practical. <em>Those suckers are heavy<\/em>. Ideally, though, if at any point you need or want to move your gold to a different bank, you&#8217;d be able to do that without paying a hefty penalty. In IT, that penalty is usually\u00a0<em>time<\/em> &#8211; time to refactor an application to successfully run on a <strong>different<\/strong> platform.<\/p>\n<p>Imagine if the bank only allowed you to spend $50 worth of gold every day, despite having several thousand dollars&#8217; worth of gold in there. If your gold is stuck in that one bank, with hefty penalties to move it, then it&#8217;s <em>really<\/em> only as usable as the features and rules of that bank.<\/p>\n<h2>Containers<\/h2>\n<p>Containers deliver on scalability and portability, better than anything else currently out there. You can run a container built on standardized, open technology (<a href=\"https:\/\/www.docker.com\/\">Docker<\/a>, <a href=\"https:\/\/cri-o.io\/\">CRI-O<\/a>) on almost any container platform these days &#8211; a cloud built to run on-premise (within a company&#8217;s hardware), or in any of the various public clouds. Then you need to be able to connect and orchestrate the containers (and deliver on that actual scalability), and <a href=\"https:\/\/kubernetes.io\/\">Kubernetes<\/a> is the standard for that. If you&#8217;re not building containers, and containers for Kubernetes, you&#8217;re risking a lot of lock-in: getting stuck using technology that doesn&#8217;t scale, isn&#8217;t flexible, or isn&#8217;t portable in the ways you&#8217;re going to want.<\/p>\n<h2>The Question<\/h2>\n<p>The question then becomes, <em>which bank do you use?<\/em> Where do you store your gold &#8211; the implementation of your competitive advantage &#8211; where you can have usability, but also portability and the right to find a different platform if you want to? And, for bonus points, since <a href=\"https:\/\/soul-repairs.com\/blog\/2019\/05\/16\/developers-drive-organizational-success\/\">developers and the teams that surround them are the linchpin<\/a> in all of this, how do you do all of that in a way that makes those developers and those teams super happy?<\/p>\n<h2>OpenShift!<\/h2>\n<p>We <em>could<\/em> be accused of being biased at this point, we <em>do<\/em> both work for Red Hat. But even before we worked for Red Hat, we loved OpenShift &#8211; and loving it as much as we do is how we ended up <em>at<\/em> Red Hat. The more we work with a variety of customers, the more we see that the beauty of a platform like OpenShift, and the ecosystem and partnerships that surround it, is that you can build a container <em>stupid easy<\/em> (using Red Hat&#8217;s source-to-image (s2i) technology), using implementations and frameworks you know and love (JEE, Spring Boot, NodeJS, etc&#8230;) or even architectures that give you even more power and scalability (Quarkus, Camel-K), and you can deploy that container <em>anywhere you&#8217;d want to run it<\/em>: AWS, GCS, IBM or Microsoft&#8217;s cloud, or on-premise in your own private cloud.<\/p>\n<p>You end up locked into OpenShift &#8211; but <em>only<\/em> OpenShift. You have to choose\u00a0<em>some<\/em> bank. And OpenShift is built to allow you to move your&#8230;well, your gold, wherever you want it to be.<\/p>\n<h2>TL;DR<\/h2>\n<p>A company&#8217;s applications are very much like gold &#8211; they&#8217;re wealth realized from raw materials. <strong>Protect your gold.<\/strong> Protect your rights to access and use your gold in the ways that will realize the most inherent value &#8211; and give you room to find\u00a0<em>more<\/em> value than you even guessed was there. In the world of application development, that translates to open standards, source control, releasing frequently, and containers &#8211; Kubernetes and OpenShift, specifically. All of this works to help make sure that your applications, the execution of your competitive advantage, are as protected and valuable as they can be.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>We&#8217;ve talked previously about how developers drive organizational success: they deliver the applications by which companies deliver their competitive advantages. Because they are a way for companies to deliver products to customers, those delivered applications are critically valuable. Application development is a lot like extracting gold &#8211; it creates value out of raw resources. Application &hellip; <\/p>\n<p class=\"read-more\"><a class=\"btn btn-default\" href=\"https:\/\/soul-repairs.com\/blog\/2019\/09\/03\/applications-are-gold\/\"> Read More<span class=\"screen-reader-text\">  Read More<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"nf_dc_page":"","_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[28,4],"tags":[132,154,45,88,82,129,87,155,57,44,153],"wf_post_folders":[],"coauthors":[26,11],"class_list":["post-2785","post","type-post","status-publish","format-standard","hentry","category-organizations","category-technology","tag-architecture","tag-containers","tag-continuous-delivery","tag-cri-o","tag-docker","tag-git","tag-kubernetes","tag-lock-in","tag-only-one-safe","tag-openshift","tag-scaling"],"_links":{"self":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts\/2785","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/comments?post=2785"}],"version-history":[{"count":7,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts\/2785\/revisions"}],"predecessor-version":[{"id":3028,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts\/2785\/revisions\/3028"}],"wp:attachment":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/media?parent=2785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/categories?post=2785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/tags?post=2785"},{"taxonomy":"wf_post_folders","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/wf_post_folders?post=2785"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/coauthors?post=2785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}