microservices

What are microservices, and what is a microservices architecture?

Microservices, or microservices architecture, is an approach to application development in which a large application is built from modular components or services. Each module supports a specific task or business goal and uses a simple, well-defined interface, such as an application programming interface (API), to communicate with other sets of services.

Software developer and author Martin Fowler is credited with promoting the idea of breaking down services in a service-oriented architecture (SOA) into microservices.

How microservices work

In a microservices architecture, an application is divided into services. Each service runs a unique process and usually manages its own database. A service can generate alerts, log data, support user interfaces (UIs), handle user identification or authentication and perform various other tasks.

The microservices paradigm provides development teams with a more decentralized approach to building software. Each service can be isolated, rebuilt, redeployed and managed independently. For example, if a program isn't properly generating reports, IT staff can trace the problem to a specific service and then test, restart, patch and redeploy that service as needed, independent of other services.

Benefits of a microservices architecture

Microservices designs and deployments have grown thanks to the cloud, containerization and hyperconnected systems. However, microservices pose a series of tradeoffs for software developers.

In terms of advantages, microservices:

• can be developed and deployed using different languages and tools;
• require less development time;
• can scale quickly;
• can be reused in different projects;
• contain better fault isolation;
• are faster and far less resource-intensive to deploy and load balance;
• can be deployed in relatively small teams; and
• work well with Containers.

Challenges of a microservices architecture

However, there are also drawbacks with microservices, such as:

• potentially too much granularity;
• extra effort designing for communication between services;
• complex testing;
• latency during heavy use;
• additional management and control; and
• comprehensive security.

Characteristics of a microservices architecture and design

Microservices architecture consists of discrete components and services; their intercommunication and data exchanges create the functions of a complete application. Typical characteristics of a microservices design and architecture include the following:

• Unique. Design and deploy services to accomplish a specific function or address a specific requirement.
• Decentralized. Ideally services have few if any dependencies, although loose coupling requires frequent and  extensive communication.
• Resilient. Design services for maximum fault tolerance. A single service failure shouldn't disable an entire application.
• Use APIs. A microservices architecture relies heavily on APIs and API gateways to facilitate communication.
• Data separation. Ideally, each service accesses its own database or storage volume.

Microservices vs. monolithic architecture

In a monolithic architecture, all of the code is in one principal executable file. This can be tougher to troubleshoot, test and update, because a problem in a code base could be located anywhere within the software. More and longer testing is required due to the amount of monolithic code involved. Also, any small change or update in a monolithic application requires an organization to build and deploy an entirely new version of the application. Altogether, monolithic application development entails significant planning, preparation, time and expense.

Microservices architectures offer faster software development and deployment compared to monolithic software architecture, which enhances business agility. Microservices can make it easier to test and deploy changes. Separation of services improves fault isolation -- if a problem occurs in the software, the faulty service can be isolated, remediated, tested and redeployed without the need to regression test the entire application as with traditional monolithic application architectures.

Monolithic applications can be difficult to scale. When a monolithic application reaches a capacity limitation, such as data throughput or some other bottleneck, the only practical option is to deploy another complete iteration of the entire monolithic application, and manage traffic between the instances using load balancers.

By comparison, one can scale an individual microservices application by adding container instances of only those services. This makes microservices scaling far more resource-efficient than scaling applications using a monolithic architecture.

Microservices aren't management-free, however. A microservices architecture separates each service from the others, and it can be difficult to manage all the parts of the whole. For example, careful monitoring and management are needed to track the availability and performance of all the component services operating within a microservices application.

Microservices and DevOps

DevOps combines tasks between application and system operations teams. Increased communications between developers and operations staff enables an IT team to better create and manage infrastructure. IT operations budgets for capacities, operational tasks, upgrades and more. Developers and application teams can manage databases, servers, software and hardware used in production.

Microservices lifecycle support requires teamwork and collaboration between development and operations teams, which lends itself to how DevOps teams operate. Experienced DevOps teams are well-equipped to employ microservices-type architectures in software development projects.

Microservices architecture vs. SOA

SOA is a software architecture where each of its services utilizes protocols. This enables users to combine functionalities and form applications built from previous services. SOA has been a standard development practice for nearly two decades. However, the resourcefulness of SOA runs into challenges with cloud computing, where it lacks scalability and slows down with work request changes, which limits application development.

Many developers find microservices to be a more granular approach to SOA. Proponents of the SOA model believe that the microservices architecture is the natural evolution of SOA to accommodate cloud computing and meet increasing demands for faster software development cycles.

Others believe microservices is a more platform-agnostic approach to application development and, therefore, should have a unique name. This group could argue SOA lives on in the layers of microservices management.

Microservices and containers

A container is an individual and executable package of software, including all of the dependencies required to function independently. Containers are separated from the rest of the software surrounding them, and many containers can be employed in the same environment. In a microservices architecture, each service is individually containerized under the same environment, such as the same or related servers.

A virtual machine (VM) can be used as an alternative to containers to create microservices. A VM simulates computer systems to produce functionalities of a physical computer. Each service could potentially utilize a VM to host an intended feature. However, VMs typically are not ideal for microservices because each requires an individual operating system and other overhead. Containers are much more resource-efficient because they require only the underlying code and related dependencies to operate the service.

Microservices security

A microservices architecture can alleviate some security issues that arise with monolithic applications. Microservices simplify security monitoring because the various parts of an application are isolated. A security breach could happen in one section without affecting other areas of the project. Microservices provide resistance against distributed denial-of-service attacks when used with containers by minimizing an infrastructure takeover with too many server requests.

However, there are still challenges when securing microservices applications, including the following:

• More network areas are open to vulnerabilities.
• Less overall consistency between app updates allows for more security breaches.
• There's a greater area of attack, through multiple ports and APIs.
• There's a lack of control of third-party software.
• Security must be maintained for each service.

Microservices developers have come up with proactive strategies to alleviate security issues. Use a security scanner, utilize access control limitations, secure internal networks including Docker environments and operate outside of silos to communicate with all parts of the operation.

Deploying microservices applications

Three main factors make microservices a viable software architecture.

Containers enable a consistent and resource-efficient means of packaging individual services. Docker is a popular tool to use containers on premises or on a public or private cloud. This offers a wide variety of deployment alternatives for microservices developers and businesses.

Orchestration tools, such as Kubernetes, help with automating scaling, deployment and container management.

Service mesh is a layer of infrastructure dedicated for communication between individual services. When hundreds of services communicate with each other, it becomes complicated to determine what services are interacting with each other. Service mesh makes those communications faster, more secure, visible and reliable by capturing behaviors such as latency-aware load balancing or service discovery.

Improvements in these technologies, and others such as intricate monitoring and logging, have steadily reduced microservices complexity and spurred continued adoption by organizations and development teams.

Tools to deploy microservices applications

Thanks to synergy with APIs, containers and continuous development processes, microservices can leverage many of the same tools for design, test, deployment and management.

Kubernetes is the de facto standard for container-based orchestration, whether an enterprise uses this in its own local environments or through a cloud-based service. Other orchestration tools include Docker Swarm and Compose, and HashiCorp Nomad. Service meshes such as Linkerd and Istio also are commonly used alongside microservices. Major cloud providers offer ancillary services to help manage microservices.

Organizations can choose from a wide range of other tools that span testing, deployment, monitoring and management of microservices environments. Examples of tools that span areas of testing include Gatling, Hoverfly, Jaeger, Pact, Vagrant, VCR and WireMock.

Microservices monitoring and management can be particularly challenging, given the need to track and maintain each service component of an application and their interactions. These functions include observability, failure detection and gathering metrics from logs to identify performance and stability issues. Examples of monitoring tools include Sentry, Sensu and Sumo Logic. Some examples of log aggregation tools include Fluentd, Logstash, Ryslog and Loggly. For log visualization, tools include Scalyr, Graylog, Kibana and Sematext.