MicroServices: Do One Thing & Do It Well

Continuing with our recent theme of Flux7’s DevOps approach and best practices, today we will discuss the Flux7 microservices philosophy. While we’ve previously defined microservices and their benefits, we are taking a step back today to look at the bigger picture and how one might view and approach microservices for best results.


At their most essential, microservices are based on the famous Unix philosophy: Do One Thing and Do It Well! This in turn translates into minimalist and modular software with each component of your software/application responsible for its one and only duty. Indeed, this approach is in lock step with common instruction you’ll often find on good and effective programming.

Monolithic Code Bases

New programmers tend to write their code in a huge monolithic block, which is generally recognized as a poor approach for achieving quality code. Their functions are usually too long and do too many things, which can introduce several key problems.

• The first — and biggest problem in our opinion — is readability. An unnecessarily long function is a mess to read. And, if you can’t read it, you can’t understand it. If you don’t understand it, it will in turn be difficult to test, debug and improve when necessary.
• Second, when you want to add a new feature, it will be difficult.
• Long functions also make for fragile code as even a small change can break the whole application.
• Lastly, long and messy functions creates a problem for testability. While testing code can be boring and sometimes painful, it is necessary. To make testing as straight-forward as possible, small and short functions make all the difference, helping you test your code much more easily.  

Microservices Downsides

While we can keep counting the similarities between best practices of better coding and microservices for developing software/applications, let’s move on to the potential downsides. Microservices don’t help get rid of complexity but rather move it to another layer: the network. This brings its own potential issues such as latency, load balancing, fault tolerance and deployment problems. Decoupling your application into too many microservices (nano services in this case) will bring its own problems such as runtime overhead. So our philosophy is that there should be a balance between monolithic and micro, like anything in life.

Case in Point

Organizations interested in a move to a microservices architecture generally fall into one of two camps: those looking to transform a monolithic application and those who want to start a new project on the best foot possible.

Transform a Monolith
An ounce of prevention is worth a pound of cure, and, that’s exactly what this SaaS sales application provider asked for the AWS experts at Flux7 to come in and provide. Specifically, this organization was moving from what it called a SaaS 1.0 to SaaS 2.0 model and was thinking about microservices as an approach to breaking its monolithic application into smaller services. We educated the team throughout the assessment and design phases as to the proper use of microservices, S3, security, and more to ensure they were able to build, manage and extend the architecture themselves. The second actionable output of the Flux7 engagement was to create a contextual roadmap view of the AWS microservices migration, building in DevOps best practices and continuous integration/continuous delivery processes. With Flux7’s guidance, this organization is well-positioned to leverage automation within a new microservices infrastructure to automate the build, integration, and testing of code under development to implement a CI/CD pipeline.

Greenfield Opportunity
We also recently worked with a provider of cloud-based CRM solutions who was clearly among the latter, wanting to use a microservices architecture for a greenfield opportunity. It was agreed that a microservices architecture based on AWS and Docker would provide the utmost advantage. And it did just that allowing the Development team to create, test and deploy the application on a per service basis, moving each service to completion independent of any other service. The organization achieved agility and innovation as individual teams focused on their own autonomous services, which meant that multiple services within the project could be worked on at the same time, accomplishing the end goal much more quickly.

This approach also enabled agility, with developers able to respond to market needs for their own services without concern for the implication of change on other services. At the end of the day, the microservices architecture resulted in a faster time to market for the new application, and the ability to quickly and easily update individual services, maintaining a critical edge over the competition.

For more reading on how Microservices can help your organization, or how the Flux7  Microservices SmartStart architecture offering can help increase your developer efficiency and efficacy, speed time to market, and grow customer satisfaction, please refer to our Microservices solutions page. For additional tips, AWS best practices and commentary delivered regularly to your inbox, click the button below to sign up for our blog.