What are Microservices? Framework and Architecture Guide

Microservices are an architecture style used by many organisations for software development. There are a number of different ways to define microservices, but a common definition comes from Martin Fowler: "The microservice architectural style is an approach to developing a single application as a suite of small services. These services are built around business capabilities and are independently deployable." Fowler’s definition continues: "There is a bare minimum of centralised management of these services, which may be written in different programming languages."

How Microservices Relate to APIs

Microservices and APIs have been getting a lot of publicity, and there is some confusion about how they are related, and no — they are not the same thing. A microservice is an architecture that separates parts of a application into small, self-containing services (these are the APIs) The API is an interface; as one commentator states: APIs “are focused on self-service consumption of the asset, simplicity, security, analytics, and speed to deliver.”

In the past, the IT industry used monolithic or Service Oriented Architecture(SOA)-based solutions as the standard, but considering the growing complexity of today’s infrastructures, SOAs are not able to satisfy the consistently dynamic and growing demands. Microservices are designed to achieve a high degree of agility, fast delivery, and to scale.

Misconceptions About Microservices

Before we dive into the microservices architecture, there are some misconceptions about the services that we should clear up. First, the "micro"-part of the name might lead people to think this is a tiny service, and therefore shouldn't be doing complex functions, but that is not so. It’s true that a microservice is a small component, but it can represent a range of business capabilities, from large and complex to the very small; an example might be a login system or a payment engine.

Also, many people assume that microservices are a new kind of a protocol. But microservices is not new, nor is it a protocol. As touched on above, microservices architectures do use existing APIs like REST and SOAP services, AMQP, and JMS.

Microservices 101

The basic concept of microservice is this: it is a small application that does one thing only, but it does that one thing very well. A microservice is:

• Easily replaceable
• Independently developed
• Independently deployable

While they are independently developed and deployable, a microservice isn’t an island onto itself. Normally there are many microservices in an architecture or in a solution that need to interact with each other. One microservice is a part of a larger ecosystem, running and working alongside other microservices to accomplish what would normally be handled by one large, standalone application.

How Microservices Overcome Processing Challenges

Challenges with the old way of doing things, notably SOA, have led us to rely more on a microservice architecture. Splitting a monolithic application up into many small independent applications through concurrency or partitioning results in the application not being as efficient as we need it to be. If an application needs to process tasks, we usually assume the more efficient the process the better. With time, the application will grow along with business capabilities, and as features get added, and traffic increases. This leads to decreased speed and efficiency, and eventually the time will come when it needs to scale up, and in the pre-microservices days, concurrency and partitioning were the primary methods for breaking up tasks.

Ultimately though, concurrency and partitioning are difficult to support when you have one large application that needs to be deployed to every server, which needs to be processing any type of task. Vertical scaling had often been the remedy when applications got complicated. This is achieved by either increasing the hardware side and adding more servers, (deploying a copy of your applications to the other servers) or vertical scaling the application. This method increases efficiencies but makes the application more complex.

Best Practises for a Microservice Ecosystem

A microservice requires a large infrastructure and should be built from the ground up. Microservices are not isolated — they are built to run and interact in a unique environment — the microservices ecosystem.

Microservices must be built with sustainability in mind; with the ability to know how to stabilise the environment, how to scale, and be reliable and fault-tolerant. A best-practise microservices ecosystem can be split into four layers:

• Hardware: This layer includes the physical host servers, databases, and operating systems. It is ideal to standardise on an operating system. Whether it’s Linux or Solaris or Windows, it must be configured with configuration management tools such as Ansible, Chef, or Puppet, and it should be used to install all the applications and set all the necessary configurations. Otherwise, you will have scalability issues; if you need to scale, everything will need to be configured again. You will also require host-level monitoring to quickly resolve issues.
• Communications: This layer in the microservices infrastructure affects all the other layers; without proper communication, none of the other parts of the architecture can work. For data, microservices can use HTTP plus RAF, or a TIFF communication channel. For messaging, the microservice will send messages over the network via HTTP, or the chosen protocol. It is also very important to include discovery, registry, and load balancing in the communication layer to facilitate dynamic communication across the microservice infrastructure.
• Development: This is where the applications are being developed, so this layer should house all the self-service development tools that enable new databases, tables, message brokers, schemas, and ports to be created. Incorporating logging and monitoring tools are a vital step in the development layer. If everything has been successfully built and tested, then deployment should be automatic.
• Microservice: The final layer is the simplest one; it’s where the microservice lives and runs. This is where the configuration file lives, and where self-service tools from the other layers should be placed if changes need to be made.

Microservices are an increasingly popular architecture for software and application development. Their modular style enables continuous delivery practises. businesses are increasingly turning to microservices for their development and cloud application architectures. We invite you to explore how to build microservices using Talend Open Studio for ESB.