What are Microservices

Over the past few years there certainly has been a lot of hype and discussions regarding Microservices.

What originally was nothing more than a side note in a discussion on Service Oriented Architecture (SOA) has resulted in the whole software development industry up the ante and really start peddling Microservices as the cure for mostly any software development ailment!

One of the issues surrounding Microservices is that nobody really has a clear definition of what they are and really why they are useful.  Martin Fowler, has attempted to provide a definition, which serves as a great piece when talking engineer to engineer, However in my opinion and experience it doesn't really provide a definitive description when attempting to explain microservices to members of the wider business teams. I have also found several explanations on Microservices, that all too often get lost in the weeds on the technical implementations and software engineering jargon.

I faced one of those unenviable tasks of explaining  Microservices  and why they would be particularly useful in addressing a particular challenge for a customer.  My target audience were  mostly Marketing,  Sales, Accountants and other business focused areas.

One of my favourite books on this subject Building Microservices : Designing fine grained systems, which is a great read for anyone who works in IT and wants to get a handle on microservices, provides all the relevant information you'll need.

However, I had to provide a presentation to explain why the businesses current e-commerce and content management systems were starting to impact performance and why a gradual migration to a Microservice and SOA architecture would enable the business to respond and adapt to change.

I needed to time to think and hopped on my Bicycle for a long ride into the Wiltshire countryside. When It suddenly dawned on me that a Bicycle is a perfect example to illustrate and explain the concept of Microservices in action!

Monolith to Microservice

At first glance a bicycle may at first appear to be a Monolith application, but a little closer look, we can see it's actually an entire application that is composed of small components, all with  individual tasks. Each smaller component is really good at one particular thing and nothing else.

In fact an average bicycle can consist of over 893 individual components.

Photograph by Tod Mclellan 

Understanding the Microservice architecture

Ask any number of cyclists what makes a good bicycle and you'll more than likely never get a definitive answer. The same applies when you ask any number of software architect what defines a good microservice architecture, you may get a number of different opinions.

There is no formal definition of the term microservices, there is no standard model that you'll see represented in every system based on this architectural style.  However, you can expect most microservice systems to share a few notable characteristics.

Software Solutions should be broken down into multiple component services

The key concept here is that each component can be enhanced, edited, tweaked, and then redeployed independently without compromising the integrity of an application.

Just as on a bicycle you can change any number of the components. i.e. Change the handle bars, chain or even wheels. Just as long as they conform to the predefined contracts i.e. Bolt or nut sizes etc. It won't compromise the integrity of the system , the bicycle can still function as a bicycle, however the performance of the bicycle can be improved by replacing or using other components.

Determining the proper size for microservices seems a pervasive problem - too small services create transactional and orchestration issues, and too-large services create scale and distribution issues.

Software Architecture: The hard parts

Microservices focus on business capabilities and priorities

Microservice focused teams are generally cross-functional teams. The responsibilities of each team are to make specific products based on one or more individual services communicating via message bus.

Microservices are technology agnostic

Decentralized governance is favored by the microservices community because its developers strive to produce useful tools that can then be used by others to solve the same problems regardless of technology implementation. microservice architecture also favors decentralized data management, whereby each service manages its own unique service database.

Microservices are designed to cope with failure.

Each service is designed without any external dependency on any other service. It is designed to only operate on any inputs and outputs as desired. Therefore if any service in the chain fails or dies, it does not necessarily bring down any of the services, the services are free to service any other requests which are directed to them.

What is a MicroService ?

The name microservice can be a little misleading. The name implies microservices are either small little entities desgined to execute tasks on behalf of a big application or a vast swarm of little bugs that self-replicate through the consumption of energy and are able to disintegrate any software they come into contact with! The truth is they are neither!

The micro in services refers to the scope of the functionality that the service provides i.e. business or platform capability through a well defined API, data contract and configuration. It provides the function and only that function. It is really good at doing one thing and one thing only.

The simplest definition of Microservices defines them as a software architectural style that structures an application as a collection of services that are;

• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by small teams

The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.

Properties of Microservices

Microservices have a number of distinct properties which provide tangible benefits to software development teams

• Autonomous - Exist, react and developed independently
• Isolated - Seperate from others, executing in different places and different times
• Elastic- Can be scaled depending on need
• Resilient - Minimize downtime if outages occur
• Responsive - Quick to respond or react
• Message-oriented - Connects separate systems in a network by distributed messages
• Programmable -  Tasks are done in order to achieve a specific result
• Configurable - Designed to adapt to form a specific configuration or for specific use cases.
• Automated - Controls that allow to operate without human intervention

Dividing a software project or solution into it microservice component and treating them as seperate development efforts increases the speed of development and reduces the cost of development.

The environment in which you deploy your microservices must provide dynamic scale and high availability configurations for both stateful and stateless services. This is achieved by leveraging a cloud pltform such as Azure , AWS, Heroku etc.

Microservices are reused across a number of different solutions and therefore must be able to scale appropriately depending on the use case. They must be fault tolerant and provide a reasonable timeframe for recovery if an issue arises.

Microservices rely on API's and data contracts to define how interaction with the service is achieved. The API defines a set of network-visible endpoints and the data contract defines the structure of the message that is either sent or returned.

Microsservices must however provide more than jsut an API and a Data contract. Each microservice will have different levels of configuration and the act of configuring may take different froms. For a microservice to be resuable and address the needs of each system employing its capabilities they must proivde a means by which it can be molded to suit the use case it needs to satisfy.

The life-cycle of a microservice should be fully automated, from design through to deployment.

Benefits of Microservices

• Evolutionary
  An organisaton can evolve to microservice architecture one service at a time
• Open
  Designed to expose thier functionality through industry standards for network-addressable API's and data contracts and hosted on highly scalable, elastic resilient cloud platforms
• High Velocity
  Microservices can be developed extremely quickly with one team focusing on every aspect of the service
• Reusable and Composable
  Microservices are not beholden to any one solution. Independent entities providing a business or platform capability and exposing that functionality through open internet standards.
• Flexible
  Deployment of microservices are defined by their automation
• Versionable and Replaceable
  It is possible to have multiple versions of a microservice running side by side, providing backward compatibility and easy migration.
• Owned by one team
  Cross-functional teams are formed with the purpose of owning the Microservice product lifecycle. Design through to support

When are Miroservices appropriate ?

Firstly, I think I should emphasise that adopting or transitioning to a Microservice Architecture is not easy, and personally I recommend organisations think very deeply about whether it is actually the right decision to do so. A Microservice Architecture, can provide many benefits, but this does come with additional complexity, and dare I say it a significant cost of resource and infrastrucutre.

Microservices and Distributed Architecture solutions can be great and can really help to scale your application but they are not always the most appropriate solution to a problem. Primarily, because implementing a Microservice or distributed application architectures can actually introduce more complexity to a business domain.

Not all business or application problems are complex or need dramatic scaling and therefore there is no need to over architect a solution to solve them.

Another key point to consider is that if you are developing Business Modules that need to be reused often then it could be likely that Microservices may not be the best solution. It is however, also likely that other alternatives may also be viable.

Other very vital points to consider are. Can your business or team handle microservices?

A successful Microservice requires a number of key skills technologies and disciplines that need to work together. This can actually take quite a bit of time to get right. This include aspects like efficient CI/CD (Continuous Integration/Continuous Deployment) operations and mastery of a number of skills. In my experience it does actually take software development teams between 18-24 months to efficiently transition to being effective microservice teams. There are entirely new mindsets and even new company cultures to foster.

A big primary driver for Microservice based solutions, and typically my bench mark is if your system needs to scale to over a Million requests a day, then investing in Microservice architecture could be a great decision, but if you're in the realms of doing less than 100K requests a day, then most likely the added complexity is not going to be of much use to you, and even though Microservices are sexy and cool, you're not going to get much value from them.

Conclusion

If we go back to the bicycle example, you'll notice that each component of the bicycle need not be manufactured by one particular manufacturer, but there may be very many different manufacturers supplying parts and components for a bicycle all agreeing to conform to specific standards and contracts - API's & Data Contracts. Any component may be replaced on a bicycle without losing the integrity of it use case, although some would argue that this cannot be done at runtime without issue.

It is possible to assemble your own custom bike, entirely from sourcing your own custom components. The options are endless from a Custom balance bike for your child right through a high end custom bike to win the tour de france.