<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Mocking on Brave New Geek</title><link>https://bravenewgeek.com/tag/mocking/</link><description>Recent content in Mocking on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 17 Apr 2018 12:46:22 -0500</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/mocking/index.xml" rel="self" type="application/rss+xml"/><item><title>More Environments Will Not Make Things Easier</title><link>https://bravenewgeek.com/more-environments-will-not-make-things-easier/</link><pubDate>Wed, 11 Apr 2018 15:49:47 -0500</pubDate><guid>https://bravenewgeek.com/more-environments-will-not-make-things-easier/</guid><description>&lt;p&gt;Microservices are &lt;a href="https://bravenewgeek.com/service-disoriented-architecture/"&gt;hard&lt;/a&gt;. They require extreme discipline. They require a lot more upfront thinking. They introduce integration challenges and complexity that you otherwise wouldn’t have with a monolith, but service-oriented design is an important part of scaling organization structure. Hundreds of engineers all working on the same codebase will only lead to angst and the inability to be nimble.&lt;/p&gt;
&lt;p&gt;This requires a pretty significant change in the way we think about things. We’re creatures of habit, so if we’re not careful, we’ll just keep on applying the same practices we used before we did services. And that will end in frustration.&lt;/p&gt;</description></item></channel></rss>