Frictionless Microservices

Things move fast. Things change. Requirements. Business needs. Customer demand. Technology. Reacting to these changes requires agility and the ability to execute quickly and efficiently.

Today, developing software becomes an exercise in designing distributed systems, asynchronous messaging, eventually correct data stores — and the list goes on and on. Complexity is inherit and inevitable when building software solutions that scale to meet the evolving business needs of a company. But even in these complex systems, the simplicity of the Unix Philosophy holds true.

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Doug McIlroy

This is why modern systems have landed on the notion of microservices. They should do one thing and do it well. They should work well with other microservices and should handle text streams, i.e. HTTP.

The idea is not new nor innovative. It has long been discussed as a logical methodology when composing a system of software components to address the needs of a business. However, recent technological innovations have greatly reduced the effort necessary to develop and maintain a microservices architecture.

Frictionless Microservices is a series of articles is an effort to collect and combine the experiences of many microservice implementations and to provide a pragmatic approach to designing and implementing your own microservices architecture. The goal is to help reduce the friction around successfully developing, testing, and deploying microservices.

Have experience developing microservices? Have pragmatic practices that have helped in the process of developing and maintaining microservices?

I’d love to learn from your experience. Let’s start a discussion.