In the world of software buzzwords, “microservices” began appearing regularly around 2012.
The simple definition of microservices is a software architecture pattern that creates small specialized, autonomous services that interact across the network and are built and managed independently.
The opposite of microservices is “monolithic” application architecture that is characterized by a single service or process that handles all application responsibilities – a software architecture commonly used to initially build information technology (IT) infrastructure for many, if not most organizations.
The difference in the way that the two architectures work is simple. A monolithic architecture puts all its functionality into a single unit, like a train – you can add more train cars, but it is a single train. A microservices architecture organizes its functionality into smaller units, like a fleet of cars and trucks – to make more things happen, you can add more independent cars and trucks.
Although microservices bears a similarity to service-oriented architecture (SOA) – both contain “service” and “architecture” in their name – SOA is like the way a customer sees your web site, and microservices is more like the wiring inside your web site. SOA is an approach for designing how you want the world to interact with your business, and microservices are the fractal engines that your customers don’t see (customer-facing services are implemented with smaller ones which rely on smaller ones – fractal). Not only cars and trucks, but drones and nanobots all working together. A microservices architecture enables scalable, adaptable, modular, and quickly accessible cloud-based applications and services and provides the dynamic, consistent experience that today’s global businesses require.
As companies grow and business processes change, more demands are placed on IT to handle an increasing volume and velocity of data to better manage business functions – everything from raw materials orders to production to sales to invoicing to distribution. The difficulty with a monolithic architecture is that frequent and continuous changes are difficult to implement while maintaining ongoing and optimal business operations. Increasing growth and the need for an IT approach that can change quickly has led to increased adoption of a microservices architecture due to the ease of scaling operations to meet new demands.
As with any technology, there are pros and cons associated with microservices. From a software developer’s perspective, these pros and cons include:
- Microservices offers the freedom to independently develop and deploy services (when you need a metaphorical “forklift,” you can add it to your fleet of “cars” and “trucks”)
- Easy integration and automatic deployment (for example, you can have a new microservice call the services offered by other microservices)
- Easy to understand and modify for developers, so a new team member can become productive quickly (you don’t need to learn a monolith before you can become productive)
- The developers can make use of the latest technologies (e.g. introducing “serverless” does not break your architecture, but instead provides you even more flexibility)
- The code is organized around business capabilities (anything from add_a_customer to read_from_a_database)
- Spins up and down more quickly (when you need another “car” you can have one in moments, no need to go to the “dealership” to get one)
- When change is required in a certain part of the application, only the related service is modified and redeployed (no need to modify and redeploy the entire application)
- Easy to scale and integrate with third-party services
- No long-term commitment to a technology stack
- Distributed deployment and process flows can create complicated testing
- Increasing number of services can result in information barriers
- The architecture brings additional complexity as the developers must implement fault tolerance, mitigate network latency, and deal with a variety of message formats as well as load balancing
- In addition to several complexities of an existing monolithic architecture, the developers have to deal with the additional complexity of a distributed system
- Handling use cases that span more than one service without using distributed transactions is not only tough but also requires communication and cooperation between different teams
- Partitioning the application into microservices is very much an art
Cloud providers become experts at addressing these problems to unleash the value to organizations, including:
- Because each microservice can be developed and deployed independently, applications can be up and running quickly
- A microservices platform offers an agility that monolithic systems do not, which enables businesses to add new functions or update existing features easily and in shorter timeframes
- Microservices architecture reduces infrastructure costs and mitigates the risk of capacity-related service outages
- Scheduled downtimes are reduced because microservices can be updated independently
- Services can grow or shrink as the business scope changes
As businesses struggle to meet the demand to automate data services to achieve efficiencies in business and to better handle the increasing complexity and communication requirements of a growing number of applications, wearables, and the Internet of Things into the overall picture, microservices will provide the flexibility, scalability and cost-efficiency needed to future-proof their IT infrastructure