David R. Heffelfinger

  Ensode Technology, LLC


Mitigating Risks of a Microservices Architecture

In the “Demystifying Microservices for Java EE Developers” guide I wrote for Payara, I list several advantages and disadvantages of a microservices architecture. In the guide I list the disadvantages, but don’t really go into how to mitigate or even eliminate the risks. In this post I’ll go over these disadvantages and how to reduce the risks that they present.

Additional operational overhead

When developing an application as a series of microservices, there will be some operational overhead since, instead of deploying one application into production, several small applications (i.e. your microservices) will need to be deployed. To decrease the costs of the operational overhead, a few approaches can be taken.

Deploy to the cloud

When deploying to the cloud, the cloud vendor can provide some of their resources to help with operation tasks for your application, freeing your team from having to perform these tasks. Additionally, most cloud vendors provide elasticity, meaning that your applications can be scaled up or down on demand, as their load increases or decreases, this helps with the scalability of your application as a whole.

Implement a DevOps approach

Your development team assists with operational task such as deployment and monitoring

Use an automated deployment tool

There are several tools in the market that can automate deployments, some free and open source, some commercial. Bamboo and Jenkins are two examples that are popular in the Java world. Puppet is another example, popular with languages typically used with Linux, such as Python or Ruby.

Use an Automated Performance Management (APM) Tool

Monitoring performance becomes a lot harder if you deploy your application as a series of independent modules (microservices). An automated performance management tool can help with this. Some examples include AppDynamics, New Relic, Vector and Prometheus.

Use a log aggregation tool

When deploying an application as a series of microservices, instead of having a single log file to monitor, we typically have several, maybe hundreds of log files to monitor. Doing this by hand is not practical. To mitigate this risk a log aggregation tool such as Splunk, GrayLog or Loggly should be used.

Increased Debugging Complexity

When debugging an application following a microservices architecture, it isn’t always obvious which of your microservices is causing the problem. Some user action (i.e. saving data on an HTML form) could trigger invocations to several microservices, making it harder to pinpoint the cause of the issue.

Additional Tooling

Tools such as log aggregation tools and performance management tools may help.

Implement a policy of collective code ownership

“Collective code ownership” means that nobody owns code, ownership is shared across all teams and all developers in your organization. If a user reports a problem to your team, but it turns out that the problem is not with your code, but with another service that your code depends on, then if there is a policy of collective code ownership your team can fix the problem themselves, instead of waiting for the other team to get around to it.

Correlation Identifiers

When invoking your microservices, generate a correlation id, and pass it around as you invoke your microservices, then have your microservices log the correlation id as they are invoked. This will make it easier to trace microservices invocations when going through log files.

Distributed Transactions

Distributed transactions happen when we start a transaction, and while that transaction is in progress, an invocation to a microservice over the network takes place. Typically we want to avoid distributed transactions as there is a high probability they will timeout and rollback.

Implement your microservices as atomic units

Commit all your transactions before making invocations across the network.

Use compensating transactions

If you commit a transaction that depends on a call to a microservices, and the call fails, then initiate a compensating transaction to revert the changes made by the original transaction.

Susceptibility to the fallacies of distributed computing

L Peter Deutsch came up with the Fallacies of Distributed computing, microservices being inherently distributed, are susceptible to these fallacies.

Implement the circuit breaker design pattern

Modeled after an electrical circuit, the way the circuit breaker design pattern works is that your code attempts to make an invocation over the network, if the call fails, your code retries for a predetermined number of times, if the invocation does not succeed after repeated attempts, then the circuit breaker trips, and your code can handle the failure gracefully (how to do this depends on your specific application requirements).

Use a load balancer

A load balancer such as nginx or F5 can distribute the load across several instances of your services. Most load balancers provide failover capabilities as well.

Deploy to the cloud

The elasticity feature of most cloud providers will help mitigate susceptibility to the fallacies of distributed computing.


5 Perks You can offer to attract good Software Developers

Software developers are in high demand nowadays. We get contacted on a daily basis by companies requesting we go work for them. We frequently get emails with the words "Great Opportunity!" and "Urgent Requirement". The thing is, not many of the projects we get contacted for offer compelling reasons for us to make the change. I decided to make a list of things that would make us as software developers consider the possibility of moving on to another project.

1. Working on a brand new project

Most of the projects out there are maintenance of an existing application, brand new projects built from the ground up are few and far in between. If you have a brand new project, then you have a leg up over all the other companies looking to hire software development talent.

2. Quiet working spaces

Software development requires concentration, this concentration is hard to obtain in the modern cubicle farm, with all the interruptions around (conversations, phones ringing etc). Offer your developers quiet working spaces and you have a perk that most employers around can't offer. Ideally, give each developer their own private office, now you really have a perk that puts you head and shoulders above the competition. If you can offer private offices, at least offer cubicles with doors, which provide a bit more privacy than the usual open cubicles.

3. The ability to work remotely

Nowadays high speed internet is so common, that there really is no reason for most people to actually drive to an office. A lot of companies want to see "butts in chairs", this is really not necessary, you should know if the work is getting done, your development team does not have to physically be at your location. This is one very rare perk, offering this will certainly make your company an attractive place to work for software developers. This also has the side effect of increasing the available talent pool, since members of the development team does not have to live in the same geographical area as your company.

4. Allow the development team to use their own equipment

To this day, many companies are shy about allowing non-company laptops into their network. The development team has to use company approved hardware. Many software developers would prefer to work using their own laptops, it shouldn't be a big deal to allow them to do so. As a bonus, when working with a programming language that is platform independent, such as Java, it doesn't matter if the developer is using a Mac, Windows or Linux, therefore developers can work with their preferred platform, as opposed to being tied to whatever the company standard is.

5. Keep meetings to a minimum

In my experience, in most cases, most people attending a meeting have no real business being there. They could be doing productive work instead. Meetings interrupt the workflow of software developers and in most cases are a massive waste of time. I'd recommend not more than a 1 hour meeting a week. If you need daily status reports, an email works better than a daily meeting, that way the developers can do it at their leisure, not at a set time, and they don't have to sit through and listen to the status of all the other team members, which more than likely has no impact whatsoever in whatever they may be working on.


Things I would tell recruiters if I wasn't afraid to sound arrogant

I am fortunate enough to work in a field for which there is a lot of demand out there. I get multiple emails every day from companies asking for help with their server side Java projects. Java developers such as myself

1. Don't call your position "an opportunity"
Like I mentined in the intro, I get tons of "opportunities" every day via email or LinkedIn messages. Java projects are a dime a dozen, chances are your project is not a "great opportunity" for me. You know and I know that Java developers are hard to find, if anything, me agreeing to work on your project is an opportunity for you, and not for me.

2. Don't say you have an "urgent requirement"
You may urgently need a Java developer, and I'm here drowning in emails from recruiters that also need Java developers. It may be urgent for you to fill that position, but it is not urgent for me to accept it. While we are on the topic, don't say the requirement is urgent if you are not willing to be flexible. One perk that would certainly catch my attention would be the ability to work remotely, but very few customers are open to the possiblity. If your requirement is so urgent, shouldn't you be a bit more flexible? Oh, and by the way, no, I am not willing to relocate just so that I can work on a 6 month project.

3. I don't stay on the market too long.
I work as a consultant on a C2C basis, therefore I switch projects every few months. Every time I post my resume on one of the job boards, I get bombarded with calls and emails from recruiters (even more so than when I'm not actively looking).
If you are interested in my services, you have to move fast, chances are that in a week or less I won't be in the market anymore.

4. Don't make me jump through hoops
I've written several books on Java, taught Java classes and been a speaker at Java conferences, as well as having about 18 years of experience. I think my experience speaks for itself. Please don't make me go through several rounds of interviews or take a silly test just so that I can work on your project. Just by talking to one of your developers he or she will be able to tell that I know what I'm talking about.

5. If I accept/am about to accept another project, don't ask me to "wait a few days"
As much as I get contacted by recruiters for several different positions, it is mentally exhausting and draining to talk to several potential clients, send resumes, etc. I just want to get it over with, so as soon as I get an offer, I'm taking it.


So you want to become a technical author?

Last month at the JavaOne conference I had the opportunity to participate in a birds of a feather session titled "So you want to be a published technical author?". I was glad to share my experiences as a published book author, unfortunately the session was only 45 minutes and we had  5 people plus the moderator in the panel, so we didn't have time to cover everything we wanted to. Here are some things we covered during the session, plus a few more things that were left unsaid.

How do I get noticed?

The easiest way to get noticed is to blog about the topic you are interested in writing. Personally, the way I got discovered was when one of the articles I wrote for my own web site was linked to from The Server Side. My advice to aspiring authors would be to blog about your topic of choice then submit your own blog posts to Reddit, Hacker News and other popular technology sites.

Is it profitable?

Not directly. Yes, you'll get some extra cash, but not enough to live on. However, the fact that you are a published author will increase your demand as a programmer a lot, allowing you to charge higher rates. Also, being published opens the door to other opportunities that further increase your exposure, such as speaking engagements and invitations to write articles for high profile publications. A quote I read somewhere that deeply resonates with me: "You don't write books for the royalties, you write books for the consulting fees".

How do you find the time to write?

Very few technical authors write books for a living, for most of us that is something we do on the side. Since we have a full time job we have to write on nights and weekends. Personally, I have a home office in my basement where I go on the evenings to work on my books.

What topics should I write about?

Something you are passionate about. Personally, I tend to pick open source projects such as NetBeans and GlassFish and write about versions that are still in development and have not been officially released yet. I try to time the book publication to match the official release of the project in question. This approach has the risk that things I write about may change in the final version of the product, however the trade off is that your book will cover the latest version of the technology in question.


Thoughts on Distributed Version Control

Nowadays, distributed version control systems such as Mercurial, Git and Bazaar are all the rage. Lately, for a couple of my projects I have been using Mercurial.

Some frequently mentioned advantages of distributed version control are that it is not necessary to be connected to the network to commit your changes, and that all repositories are "equal".

Now that I've been using Mercurial for a while, I don't care that much about these advantages, however, there is one thing in Mercurial that I really, really like and that I miss very much when using other, centralized version control systems. What I love about Mercurial is that branching and merging is very simple and trivial (other distributed version control systems like Git and Bazaar probably share this advantage, however I don't have any experience with them).

When using traditional, centralized version control systems such as Subversion or CVS (or, $DEITY forbid, Harvest), many times I have found myself making some changes that will potentially introduce major breakage to the project. In cases like this I am "forced" to work without version control until all the kinks are ironed out, since committing my changes would prevent my coworkers from having a buildable source tree to work from.

The ideal solution for these cases is to create a branch in which I would make my changes safely, without affecting other developers, then when my changes are done merge my branch into the trunk. The problem with this is that for some reason branching and merging are not something "mere mortals" can do with centralized version control system. In order to do this, I would have to talk to a "CM" person to create the branch for me, which would probably take at least a few hours (if not days), then when I'm done the procedure to merge my changes would be just as painful.

When using Mercurial (and, I assume, other distributed version control systems as well), I can create a branch with ease, in Mercurial, all I have to do is use the hg clone command, passing the path of the repository to clone as a parameter. After doing this I would have my own, private branch that I can work with, without fear of breaking the build and preventing anyone else from making progress.

When I am done, all I have to do is an hg push to merge my changes back into the "trunk" (or my main branch).

If it turns out that I don't want to make the changes after all, all I need to do is delete my cloned repository using standard operating system commands (rm -rf in Linux/Unix), and the branch "never existed". This capability of easily making branches for experimental features and simply "nuking" them if it turns out to be a bad idea is what really makes Mercurial great for me. It is a very liberating feeling that I don't think can be expressed in words, you need to experience it to know what I mean.


Yet another "My Favorite Firefox Extensions" Post

It seems like every other day there is a link on DZone about someone listing their own favorite Firefox extensions.

Well, I didn't want to be left out, so here are mine:

  1. Web Developer, provides a lot of functionality useful when developing web applications. One of my favorite features is the ability to outline elements on the page, very useful.

  2. Firebug, I can't live without the ability to edit Javascript in real time, and see the results on the page immediately. Also, the Firebug console is invaluable when debugging Javascript, freeing us from the awful alerts(); we used to have to use all the time in the past. Working with Javascript without firebug is like working with a hand tied behind your back.
  3. iMacros, when developing web applications, we often have to go through tedious, repetitive steps to get to the page we are developing. iMacro allows us to record macros to go through the repetitive boring stuff for us, a real time saver and sanity preserver.
There you have it. If you develop web applications for a living, the above Firefox addons will make your life a lot easier, and will also make you a lot more productive.


PDF Unlock Utility

A while back I purchased an ebook in PDF format. When I tried to open it under my Linux laptop I got an unpleasant surprise, the ebook's author had used a font that wasn't available on my Linux box, therefore the ebook was unreadable.

I figured I can simply copy the text and paste it into a text editor or word processor, but to my dismay I found out it wasn't possible to copy text from the PDF.

I had heard about iText, a Java library used to create and manipulate PDF's. I studied the iText API and found out how to make a copy of the PDF with the copy/paste restrictions removed. I wrote some code to try it out, and lo and behold, I was able to copy and paste from my custom copy of the ebook.

I figured that just like I needed to remove those restrictions, many others out there probably had the same problem. I turned my home grown utility into a web application and posted it on my site: http://www.ensode.net/pdf-crack.jsf. It has been helping people remove those annoying restrictions for a while now.,


« April 2018

© David R. Heffelfinger