Overview

Microservice architecture is all the rage these days. With a plethora of blog posts, books, lectures, and conferences on the topic; exploding over the past few years. With that said, I'm going to jump on the bandwagon with a post of my own. Drawing from my experience as the product owner for the first microservice built at my current employer and information that I heard while attending Code Freeze 2018: Microservice Architectures.

Microservice architecture is often seen as the conceptual antithesis of the monolith architecture.

In a monolith, all of the code to support an application is shipped as a single package. One god executable that is capable of performing all aspects of the application. To archive scale with a monolithic application, one simply deploys multiple copies to production. Via configuration, some copies can handle more of one responsibly that another, but every single node is fully capable of performing any function in the system.

In contrast, a microservice application is composed of dozens or hundreds of "small" services. Each performing a single specialized task/ owning own area of responsibility. To archive scale, each microservice could consist of several redundant nodes. There might be three login microservices running and only a single tax calculator service. With the number of nodes controlled by the current level of demand.

The thing that makes a microservice, "micro", is not strictly the size of the application. But rather the number of responsibilities assigned to it. A microservice should be responsible for one thing, and do that one thing well.

Benefits

Any software developer can enumerate all of the benefits of building small testable software packages. Almost all of those arguments apply directly as reasons to build a microservice.

Simple A Microservice should be responsible for a single function. Therefore, it should be straight forward to reason about the different responsibilities that function entails, and about the different methods of failure that could be encountered. You do not have to reason about the entire software ecosystem, you only have to worry about your immediate dependencies, your datastore, and the code that runs the specific service. Any other service that is more than one hop away can be ignored.

Testable The microservice architecture demands a high degree of automated test coverage.

Isolation A microservice is self-contained. It depends on its datastore, and an API version for other microservices. When you need to deploy an update to one service, none of the rest of the services needs to be restarted, or in most cases, even notified. Simply stand up the new instances, and then cut over traffic from the old cluster to the new cluster. There is no need to coordinate releasing updates from one service with all the rest of the services in the network.

Scale Up Only What is Needed As demand increases, simply launch more nodes to maintain a seamless experience for your users or the other services. As demand wanes, the number of nodes can be decreased to save on costs. If demand is only high for one portion of your overall application, only that one part needs to grow. The order processing nodes can grow in number to support a flash sale, while the tax calculation service cluster can remain small to save on costs.

Drawbacks

As with any architecture or design pattern, there are drawbacks. The microservice architecture is no exception.

Networks of Services Often a deployed application is supported by dozens or even hundreds of microservices. Debugging the source of a problem can be challenging.

Failure Management Services need to be built with more attention to failure. As a monolith, if the application is running, one can be almost certain required dependent services are running an available. In the world of a microservice, any one dependency could be offline, making you unable to complete the requested task at hand. The possible failure of each call outside your boundary should be taken into consideration and accounted for.

Monitoring Each service needs to be monitored. To ensure the application is performing as expected and is healthy. To auto grow or shrink the cluster in response to demand. In the case of an application with 50 microservices, there needs to be 50 monitoring solutions, 50 dashboards, and 50 alerting services to get the attention of devops should something go wrong.

There are bunch of great resources for Markdown formatting. This post is primarily for my own benefit, as a quick reference on how to use the formatting for the handful that I use regularly.

Pelican Style Guide

Markdown Extensions

Basic Text Formatting

Headings

# Heading 1
## Heading 2
### Heading 3
#### Heading 4
##### Heading 5

Heading 1

Heading 2

Heading 3

Heading 4

Heading 5

Links

Raw Link: https://www.google.com

https://www.google.com

Text Link

[Displayed Text](https://www.google.com)
Displayed Text

Text Link with Alt Text

[Displayed Text](https://www.google.com "alt text")
Displayed Text

Direct link

reference links Text [1]: https://www.google.com "google"

Tables

| Header Left | Header Right |
|---------------|--------------|
| Cell Left | Cell Right |

Code

Inline code is encased with back-ticks.

`in-line-code`

in-line-code

Code blocks are identified by three back-ticks, followed by the language for syntax formatting.

```java
public class Code {
public static void main(String[] args){
return;
}
}

```java
public class Code {
    public static void main(String[] args){
        return;
    }
}

No Formatting

  a <pre>  b </pre> c  

My blog has its genesis in 2010, almost 8 years ago. Early on, I was very active posting little tidbits of knowledge and interesting facts that I had learned. As time passed, I got wrapped up in other activities and posting to the blog fee by the wayside. Eventually, my most common action on the blog was logging in to reject spam comments and upgrade the Wordpress installation.

I had selected Wordpress early on because of the ease of management, and plefora of themes to choose from. As time passed, even that became neglected.

Recently, I received notice from my webhost that I had exceeded my storage allowance. I found this curious, as I had not made any changes in months. It turns out the problem was related to the size of the email boxes I didn’t know I had, and the auto-generated visitor status reports that were being made monthly. Clearing out all those unused stuff, I was surprised to learn I was still consuming over 30MB space simply with the Wordpress installation.

I decided it was about time I made a change on the blog. I wanted to eliminate the overhead of ensuring that Wordpress was up to date. Additionally, I wanted to shrink the installation size of the site on my host to further reduce the likelihood of running out of space against. Finally, I wanted to play with a new piece of technology.

I decided to move to a static content site, selecting Pelican as the generator of the content. Converting the data from Wordpress to Pelican was straightforward. A quick export from Wordpress, import into Pelican, and then massaging of the article metadata; everything was back up and running in a snap.

That being said, there are still a few activities I need to complete:

• fix broken image links in old posts
• find a theme that I like
• consolidate and simplify tags and "slugs"
• fix code links or host on GitHub (preferred)

For what values of x is the following equation true?   x = |x| (absolute value)

Most people would say, the above equation is value for x >= 0.

For what values of x is the following equation true?   |x| < 0

Most people would claim there are no such values of x, and they would be correct. Except when dealing with computers.

Numbers within a computer are confined to a limited range, dependent on the number of bits in memory that has been allocated. Integers typically get 32-bits and longs get 64-bits. This allows for 4294967296 (integer) and 1.84467440737096E19 (long) possible combination of values to store numbers in. The numbers are encoded with a format known as 2's complement for addition/ subtraction simplicity within the processor, but there is a subtle problem. 4294967296 is an even number. One pattern is used to represent zero, leaving 4294967295 patterns for storing both the positive and negative values. In other words there are 2147483648 patterns for one side and 2147483647 for the other. There is not an even pairing between positive and negative.

As a direct result of the 2's complement number encoding, it is clear to see there is one more possible negative value than positive value. A positive integer maxes at 2,147,483,647 and negative values bottom out at −2,147,483,648.

What happens when we want to take the absolute value of −2,147,483,648? The is not a positive pattern that can represent the number 2,147,483,648. In some programming languages, taking the absolute value of this smallest possible value, results in getting the smallest value back. This can cause problems if your application has logic that requires a positive value and assumes Math.abs() works as expected.

Good static analysis tools like Findbugs have rules to identify a class of errors that can result from Math.abs(), but they aren't fool proof.

I advocate abandoning sized numbers where ever possible. If an application isn't directly interfacing with a network, the file system, or some other hardware component, we should stick to number classes which do not impose an arbitrary limit (like BigInteger in Java).

If we must stick with what fits into a single RAM slot, then I would argue we should arbitrarily shrink the size of MIN_VALUE by one (disallowing 0x80000000). That way Math.abs(Int.MIN_VALUE) == Int.MAX_VALUE. Conveniently, we would then have a free pattern to natively represent the value, NOT_A_NUMBER.

Every few weeks I run across someone stating we should eliminate the dollar bill and transition over to the dollar coin. The stated claim is it will save the government (and tax payer) money. The counter argument always being the American public has consistently rejected the dollar coin in past attempts.

I must admit I sit on the side of the fence in favor of making the switch.

What is the life-time cost difference between the paper dollar and the coin dollar?

On the surface, dollar coins are cheaper, 0.84¢, over their lifetime when compared against dollar bills, 0.92¢. However, the apparent different is very minor. This difference grows if the life expectancy of the coin is increased. Some non-government estimates place the life expectancy between 30 years (0.70¢) all the way up to 50 years (0.42¢). I lean more towards the fifty year number as I routinely see (and spend) coins from the 60’s and 70’s which are still in usable shape (denomination and mint year are both clear).

In order to facilitate the shift from paper to coins, the government would need to stop printing paper dollars. As the old bills wear out and are removed from circulation, the use of the coins would begin to grown and would become common place. Otherwise, the “sock drawer effect” would prevent the high level of circulation desired resulting in yet another failure to move to the dollar coin (Susan B Anthony, Sacajawea, Presidential Dollars.

To support the end goal of moving towards dollar coins, I do my part by actively spending dollar coins when buying cheap items (coffee, lunch at work, ice-cream).