<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <id>https://adaptjs.org/blog</id>
    <title>Adapt Blog</title>
    <updated>2020-03-16T06:00:00Z</updated>
    <generator>Feed for Node.js</generator>
    <link rel="alternate" href="https://adaptjs.org/blog"/>
    <subtitle>The best place to stay up-to-date with the latest Adapt news and events.</subtitle>
    <logo>https://adaptjs.org/img/logo_color.svg</logo>
    <rights>Copyright © 2019-2024 Unbounded Systems</rights>
    <entry>
        <title type="html"><![CDATA[Announcing Adapt 0.2.0]]></title>
        <id>https://adaptjs.org/blog/2020/03/16/adapt-release-0-2-0.html</id>
        <link href="https://adaptjs.org/blog/2020/03/16/adapt-release-0-2-0.html">
        </link>
        <updated>2020-03-16T06:00:00Z</updated>
        <summary type="html"><![CDATA[<p><img src="/blog/assets/adapt-release-0.2.0.png" alt="Adapt 0.2.0"></p>
<p>Adapt version 0.2.0 adds support for additional Node.js versions, adds configuration options for the CLI, simplifies the installation process, lays the foundation for easier upgrades, and fixes a few bugs.</p>
]]></summary>
        <author>
            <name>Mark Terrel</name>
            <uri>https://twitter.com/mterrel</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[What DevOps Can Learn from Web Developers]]></title>
        <id>https://adaptjs.org/blog/2020/01/27/what-react-devs-know.html</id>
        <link href="https://adaptjs.org/blog/2020/01/27/what-react-devs-know.html">
        </link>
        <updated>2020-01-27T06:00:00Z</updated>
        <summary type="html"><![CDATA[<p><img src="/blog/assets/annie-spratt-9VpI3gQ1iUo-unsplash-1280.jpg" alt="Helping Up"></p>
<p>Declarative specifications are all the rage in infrastructure today, the more declarative the better.
In <a href="/blog/2020/01/27/limits-of-declarative-infrastructure">the article linked here</a>, I talk about why this approach falls short.
In a nutshell, declarative approaches are really good when we don't care about the details of how something happens, just that it does.
For many DevOps operations, this is true.
We don't really care about how a container makes it to a particular server and starts accepting traffic.
We only care that it does.
But in many other cases, we care a great deal about how things happen.
Consider some examples:</p>
<ul>
<li>Deploy this new code.
Check that it’s running successfully first.
Then stop running the old code.</li>
<li>Deploy a single instance of this new code and wait for manual approval to go further (<a href="https://octopus.com/docs/deployment-patterns/canary-deployments">Canary deploy</a>)</li>
<li>Deploy the new code to some of the instances, and slowly age out old ones.
Automatically roll back if problems are detected.
(<a href="https://www.martinfowler.com/bliki/BlueGreenDeployment.html">blue/green deploy</a>)</li>
<li>Bring up a new version of the database, sync the data, then tear down the old version.</li>
<li>Start the new availability zone.
Once all services in the zone are up, then update DNS.</li>
</ul>
<p>It turns out that the web development community has been dealing with many of the problems that modern declarative infrastructure systems face, and they've been doing it for 25 years.
In this article, I want to talk a bit about how web developers have addressed these problems, and how we can apply these lessons to infrastructure.
As it turns out, many of the lessons and solutions apply quite directly.</p>
]]></summary>
        <author>
            <name>Manish Vachharajani</name>
            <uri>https://twitter.com/mvachhar</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Declarative Infrastructure is Broken]]></title>
        <id>https://adaptjs.org/blog/2020/01/27/limits-of-declarative-infrastructure.html</id>
        <link href="https://adaptjs.org/blog/2020/01/27/limits-of-declarative-infrastructure.html">
        </link>
        <updated>2020-01-27T06:00:00Z</updated>
        <summary type="html"><![CDATA[<p><img src="/blog/assets/broken-window-960188.jpg" alt="Broken Window"></p>
<p>Right now declarative infrastructure specifications are all the rage.
<a href="https://kubernetes.io">Kubernetes</a> and its vast array of YAML is the poster child of the declarative movement.
All of the other popular, recent tools in this space, like <a href="https://terraform.io">Terraform</a> and AWS <a href="https://aws.amazon.com/cloudformation/">CloudFormation</a> are also on trend.</p>
<p>Yet, in practice, these declarative specifications aren’t sufficient.</p>
]]></summary>
        <author>
            <name>Manish Vachharajani</name>
            <uri>https://twitter.com/mvachhar</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Deploying and Hosting a React App and its Back-end on Google Cloud with Adapt.js]]></title>
        <id>https://adaptjs.org/blog/2020/01/10/simple-hosting-react-app-on-google-cloud.html</id>
        <link href="https://adaptjs.org/blog/2020/01/10/simple-hosting-react-app-on-google-cloud.html">
        </link>
        <updated>2020-01-10T06:00:00Z</updated>
        <summary type="html"><![CDATA[<p><img src="/blog/assets/react-node-gcp-gke.png" alt="React Node.js GKE GCP"></p>
<p><em>Co-authored with <a href="https://twitter.com/mvachhar">Manish Vachharajani</a></em></p>
<p>With all the different cloud service offerings, hosting solutions, and automation tools, figuring out how to get your app up and running in the cloud can be quite a challenge.
In this article, I'll show you how to host your React front-end, Node.js back-end, and database on Google Cloud Platform (GCP) using a single command from an open source tool called <a href="https://adaptjs.org">Adapt</a>.</p>
]]></summary>
        <author>
            <name>Mark Terrel</name>
            <uri>https://twitter.com/mterrel</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Announcing Adapt 0.1.0]]></title>
        <id>https://adaptjs.org/blog/2020/01/09/adapt-release-0-1-0.html</id>
        <link href="https://adaptjs.org/blog/2020/01/09/adapt-release-0-1-0.html">
        </link>
        <updated>2020-01-09T06:00:00Z</updated>
        <summary type="html"><![CDATA[<p><img src="/blog/assets/adapt-release-0.1.0.png" alt="Adapt 0.1.0, GKE and Docker"></p>
<p>After what feels like more work than it should have been (isn't that always the way), we are excited to announce the release of <a href="https://adaptjs.org">Adapt.js</a> 0.1.0.  There have been a whole raft of bug fixes and usability improvements in this release, but the 3 major new features are improved Kubernetes support, including Google Kubernetes Engine (GKE), support for making a local <a href="https://docker.com">Docker</a> deployment for testing and development, and support for remote Docker registries.  We've also automated the release process which will make it easier to deliver regular releases for those of you that like to stay on the bleeding edge of development.</p>
]]></summary>
        <author>
            <name>Manish Vachharajani</name>
            <uri>https://twitter.com/mvachhar</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Fixing DNS timeouts in Docker]]></title>
        <id>https://adaptjs.org/blog/2019/10/14/fixing-dns-timeouts-in-docker.html</id>
        <link href="https://adaptjs.org/blog/2019/10/14/fixing-dns-timeouts-in-docker.html">
        </link>
        <updated>2019-10-14T06:00:00Z</updated>
        <summary type="html"><![CDATA[<p><img src="/blog/assets/lukas-blazek-UAvYasdkzq8-unsplash.jpg" alt="Alarm clock"></p>
<p class="photocredit">Photo by <a href="https://unsplash.com/@goumbik">Lukas Blazek</a> on <a href="https://unsplash.com/">Unsplash</a></p>
<p>Having flaky tests in in your CI is a nightmare.
You can't tell whether your new code broke something or if it's just those tests being flaky again.
So anytime we see strange, random failures in CI for our open source project, Adapt, we try to track down the culprit ASAP.
This is the story of how we discovered we were (accidentally) flooding our DNS server with traffic and how we used a DNS cache in Docker to solve the problem.</p>
]]></summary>
        <author>
            <name>Mark Terrel</name>
            <uri>https://twitter.com/mterrel</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[React for Infrastructure?]]></title>
        <id>https://adaptjs.org/blog/2019/09/25/react-for-infrastructure.html</id>
        <link href="https://adaptjs.org/blog/2019/09/25/react-for-infrastructure.html">
        </link>
        <updated>2019-09-25T06:00:00Z</updated>
        <summary type="html"><![CDATA[<p><img src="/blog/assets/reactplus.png" alt="React Plus Logos"></p>
<p>What is &quot;Infrastructure as Code&quot;?
If someone checks a bunch of YAML files into a Git repository, do they suddenly become code?
That seems more like &quot;Infrastructure as Files&quot; to me.
I suppose that's better than infrastructure as a gaggle of shell scripts and some commands run by hand in the middle of the night in a coffee-fueled haze, but it is a far cry from code.
How about a system to define infrastructure that really is like code?</p>
]]></summary>
        <author>
            <name>Manish Vachharajani</name>
            <uri>https://twitter.com/mvachhar</uri>
        </author>
    </entry>
</feed>