<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>microservices on howarddierking.com</title>
    <link>https://www.howarddierking.com/tags/microservices/</link>
    <description>Recent content in microservices on howarddierking.com</description>
    <generator>Hugo -- gohugo.io</generator>
    <lastBuildDate>Mon, 02 Apr 2018 00:00:00 +0000</lastBuildDate><atom:link href="https://www.howarddierking.com/tags/microservices/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>A Question on Aggregate APIs and Microservices</title>
      <link>https://www.howarddierking.com/2018/04/02/a-question-on-aggregate-apis-and-microservices/</link>
      <pubDate>Mon, 02 Apr 2018 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2018/04/02/a-question-on-aggregate-apis-and-microservices/</guid>
      <description>I received the following question from one of our service teams last week and thought it was likely the type of issue that a lot of you are dealing with (or have solved) in our current world of &amp;ldquo;microservice all the thingz!&amp;rdquo; The question went something like this:
For a current (or future) transactional API endpoint (for example CREATE [entity]]), with the move to micro services do you think (or know) that the API will still be at the highest level as it is today and behind the scenes any data stored within a micro service would just be taken care of in the ‘aggregate’ API, OR Is it the case where each micro service supporting its data would provide their own endpoints (whereby the data points are exploded over a wider distance than previously) where a consumer of such end points to achieve something like a CREATE entry transaction would have to interact with as many endpoints as is necessary.</description>
    </item>
    
    <item>
      <title>The &#34;Must Haves&#34; for a Service-based Architecture</title>
      <link>https://www.howarddierking.com/2016/11/26/the-must-haves-for-a-service-based-architecture/</link>
      <pubDate>Sat, 26 Nov 2016 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2016/11/26/the-must-haves-for-a-service-based-architecture/</guid>
      <description>Over the past several years, I&amp;rsquo;ve seen lots of architecture-related efforts come and go when it comes to services. These efforts have typically involved introducing one more more technologies that, if everyone would just get onboard, would move the organization to a next-generation, 100% available, reliable, compliant, secure stack. A few examples include REST, Kubernetes (then Swarm, then back to Kubernetes, then&amp;hellip;), Consul.io, and Kafka.
Now, put my sarcasm aside for a moment, because I believe that none of these things are bad - in fact, I think that every single one of the technologies listed (and their associated architectural patterns) can be very good things.</description>
    </item>
    
    <item>
      <title>Untangling a Monolith</title>
      <link>https://www.howarddierking.com/2015/05/02/untangling-a-monolith/</link>
      <pubDate>Sat, 02 May 2015 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2015/05/02/untangling-a-monolith/</guid>
      <description>We all have see them; most of us have to deal with them; many of us contributed to writing at least one of them. Legacy code bases tend to evolve over decades and will with rare exception get messier and more entangled as a function of the number of people working on the project and the lines of code they produce (a phenomenon that seems pretty consistent with the rest of the known universe).</description>
    </item>
    
  </channel>
</rss>
