Actions

Microservices

Definition of Microservices[1]

Microservices - also known as the microservice architecture - is an 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 a small team

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


Microservices
source: DZone


The microservice architecture is not a silver bullet. It has several drawbacks. Moreover, when using this architecture there are numerous issues that you must address. The microservice architecture pattern language is a collection of patterns for applying the microservice architecture. It has two goals:

  • The pattern language enables you to decide whether microservices are a good fit for your application.
  • The pattern language enables you to use the microservice architecture successfully.

A good starting point is the Monolithic Architecture pattern, which is the traditional architectural style that is still a good choice for many applications. It does, however, have numerous limitations and issues and so a better choice for large/complex applications is the Microservice architecture pattern.


What Microservices are Not[2]

Microservices might also be understood by what they are not. The two comparisons drawn most frequently with microservices architecture are monolithic architecture and service-oriented architecture (SOA).

The difference between microservices and monolithic architecture is that microservices compose a single application from many smaller, loosely coupled services as opposed to the monolithic approach of a large, tightly coupled application

The differences between microservices and SOA can be a bit less clear. While technical contrasts can be drawn between microservices and SOA, especially around the role of the enterprise service bus (ESB), it’s easier to consider the difference as one of scope. SOA was an enterprise-wide effort to standardize the way all web services in an organization talk to and integrate with each other, whereas microservices architecture is application-specific.



History of Microservices[3]

There are numerous claims as to the origin of Micro services. Whilst Vice President of ThoughtWorks in 2004, Fred George began working on Micro Service prototype architectures based on what he called the "Baysean Principals" named after Jeff Bay.

As early as 2005, Peter Rodgers introduced the term "Micro-Web-Services" during a presentation at the Web Services Edge conference. Against conventional thinking and at the height of the SOAP SOA architecture hype curve he argued for "REST-services" and on slide #4 of the conference presentation, he discusses "Software components are Micro-Web-Services". He goes on to say "Micro-Services are composed using Unix-like pipelines (the Web meets Unix = true loose-coupling). Services can call services (+multiple language run-times). Complex service-assemblies are abstracted behind simple URI interfaces. Any service, at any granularity, can be exposed." He described how a well-designed microservices platform "applies the underlying architectural principles of the Web and REST services together with Unix-like scheduling and pipelines to provide radical flexibility and improved simplicity in service-oriented architectures.

Rodgers' work originated in 1999 with the Dexter research project at Hewlett Packard Labs, whose aim was to make code less brittle and to make large-scale, complex software systems robust to change. Ultimately this path of research led to the development of resource-oriented computing (ROC), a generalized computation abstraction in which REST is a special subset.

In 2007, Juval Löwy in his writing and speaking called for building systems in which every class was a service. Löwy realized this required the use of a technology that can support such granular use of services, and he extended Windows Communication Foundation (WCF) to do just that, taking every class and treating it as a service while maintaining the conventional programming model of classes.

A workshop of software architects held near Venice in May 2011 used the term "microservice" to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on "microservices" as the most appropriate name. James Lewis presented some of those ideas as a case study in March 2012 at 33rd Degree in Kraków in Micro services - Java, the Unix Way, as did Fred George about the same time. Adrian Cockcroft, former director for the Cloud Systems at Netflix, described this approach as "fine grained SOA", pioneered the style at web scale, as did many of the others mentioned in this article - Joe Walnes, Dan North, Evan Bottcher, and Graham Tackley.

Microservices is a specialization of an implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems. The microservices approach is a first realization of SOA that followed the introduction of DevOps and is becoming more popular for building continuously deployed systems.

In February 2020, the Cloud Microservices Market Research Report predicted that the global microservice architecture market size will increase at a CAGR of 21.37% from 2019 to 2026 and reach $3.1 billion by 2026.


Microservices Use Cases[4]

Many use cases are applicable for microservices, especially those that involve an extensive data pipeline. For example, a microservices-based system would be ideal for a reporting system on a company’s retail store sales. Each step in the data preparation process would be handled by a microservice: data collection, [[Data Cleansing}cleansing]], normalization, enrichment, aggregation, reporting, etc. The workflow naturally creates a trackable lineage so if any problems are encountered in the data, it is relatively easy to trace back which microservice might need to be updated.

Another use case entails machine learning (ML). A microservices-based ML environment collects, aggregates, and analyzes a data flow so that the ML framework can determine an outcome. In such an environment, the data runs through a workflow that has many steps, and each step is handled by a microservice. One advantage of using a microservices architecture for machine learning is that multiple machine learning frameworks can be included in the workflow so that multiple models can be created on the same data flow. This is useful when the machine learning frameworks are targeting a predicted outcome, and having multiple frameworks running simultaneously provides a comparison around which model is providing the best results.


Characteristics Of Microservices[5]

  • Multiple Components: Software built as microservices can, by definition, be broken down into multiple component services. Why? So that each of these services can be deployed, tweaked, and then redeployed independently without compromising the integrity of an application. As a result, you might only need to change one or more distinct services instead of having to redeploy entire applications. But this approach does have its downsides, including expensive remote calls (instead of in-process calls), coarser-grained remote APIs, and increased complexity when redistributing responsibilities between components.
  • Built For Business: The microservices style is usually organized around business capabilities and priorities. Unlike a traditional monolithic development approach—where different teams each have a specific focus on, say, UIs, databases, technology layers, or server-side logic—microservice architecture utilizes cross-functional teams. The responsibilities of each team are to make specific products based on one or more individual services communicating via message bus. In microservices, a team owns the product for its lifetime, as in Amazon’s oft-quoted maxim “You build it, you run it.
  • Simple Routing: Microservices act somewhat like the classical UNIX system: they receive requests, process them, and generate a response accordingly. This is opposite to how many other products such as ESBs (Enterprise Service Buses) work, where high-tech systems for message routing, choreography, and applying business rules are utilized. You could say that microservices have smart endpoints that process info and apply logic, and dumb pipes through which the info flows.
  • Decentralized: Since microservices involve a variety of technologies and platforms, old-school methods of centralized governance aren’t optimal. 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. Just like decentralized governance, microservice architecture also favors decentralized data management. Monolithic systems use a single logical database across different applications. In a microservice application, each service usually manages its unique database.
  • Failure Resistant: Like a well-rounded child, microservices are designed to cope with failure. Since several unique and diverse services are communicating together, it’s quite possible that a service could fail, for one reason or another (e.g., when the supplier isn’t available). In these instances, the client should allow its neighboring services to function while it bows out in as graceful a manner as possible. However, monitoring microservices can help prevent the risk of a failure. For obvious reasons, this requirement adds more complexity to microservices as compared to monolithic systems architecture.
  • Evolutionary: Microservices architecture is an evolutionary design and, again, is ideal for evolutionary systems where you can’t fully anticipate the types of devices that may one day be accessing your application.. Many applications start based on monolithic architecture, but as several unforeseen requirements surfaced, can be slowly revamped to microservices that interact over an older monolithic architecture through APIs.


Examples of Microservices Frameworks for Java[6]

There are several microservices frameworks that you can use for developing for Java. Some of these are:

  • Spring Boot. This is probably the best Java microservices framework that works on top of languages for Inversion of Control, Aspect-Oriented Programming, and others.
  • Jersey. This open-source framework supports JAX-RS APIs in Java is very easy to use.
  • Swagger. Helps you in documenting API as well as gives you a development portal, which allows users to test your APIs.

Others that can be considered include: Dropwizard, Ninja Web Framework, Play Framework, RestExpress, Restlet, Restx, and Spark Framework.


Benefits of Microservices[7]

  • Agility: Microservices foster an organization of small, independent teams that take ownership of their services. Teams act within a small and well understood context, and are empowered to work more independently and more quickly. This shortens development cycle times. You benefit significantly from the aggregate throughput of the organization.
  • Flexible Scaling: Microservices allow each service to be independently scaled to meet demand for the application feature it supports. This enables teams to right-size infrastructure needs, accurately measure the cost of a feature, and maintain availability if a service experiences a spike in demand.
  • Easy Deployment: Microservices enable continuous integration and continuous delivery, making it easy to try out new ideas and to roll back if something doesn’t work. The low cost of failure enables experimentation, makes it easier to update code, and accelerates time-to-market for new features.
  • Technological Freedom: Microservices architectures don’t follow a “one size fits all” approach. Teams have the freedom to choose the best tool to solve their specific problems. As a consequence, teams building microservices can choose the best tool for each job.
  • Reusable Code: Dividing software into small, well-defined modules enables teams to use functions for multiple purposes. A service written for a certain function can be used as a building block for another feature. This allows an application to bootstrap off itself, as developers can create new capabilities without writing code from scratch.
  • Resilience: Service independence increases an application’s resistance to failure. In a monolithic architecture, if a single component fails, it can cause the entire application to fail. With microservices, applications handle total service failure by degrading functionality and not crashing the entire application.


Challenges of Microservices[8]

If your organization is thinking about shifting to a microservices architecture, expect to change the way people work, not just the apps. Organizational and cultural changes are identified as challenges in part because each team will have its own deployment cadence and will be responsible for a unique service with its own set of customers. Those may not be typical developer concerns, but they will be essential to a successful microservices architecture.

Beyond culture and process, complexity and efficiency are two major challenges of a microservice-based architecture. John Frizelle, platform architect for Red Hat Mobile, laid out these eight challenge categories in his 2017 talk at Red Hat Summit:

  • Building: You have to spend time identifying dependencies between your services. Be aware that completing one build might trigger several other builds, due to those dependencies. You also need to consider the effects that microservices have on your data.
  • Testing: Integration testing, as well as end-to-end testing, can become more difficult, and more important than ever. Know that a failure in one part of the architecture could cause something a few hops away to fail, depending on how you’ve architected your services to support one another.
  • Versioning: When you update to new versions, keep in mind that you might break backward compatibility. You can build in conditional logic to handle this, but that gets unwieldy and nasty, fast. Alternatively, you could stand up multiple live versions for different clients, but that can be more complex in maintenance and management.
  • Deployment: Yes, this is also a challenge, at least in initial set up. To make deployment easier, you must first invest in quite a lot of automation as the complexity of microservices becomes overwhelming for human deployment. Think about how you’re going to roll services out and in what order.
  • Logging: With distributed systems, you need centralized logs to bring everything together. Otherwise, the scale is impossible to manage.
  • Monitoring: It’s critical to have a centralized view of the system to pinpoint sources of problems.
  • Debugging: Remote debugging through your local integrated development environment (IDE) isn’t an option and it won’t work across dozens or hundreds of services. Unfortunately there’s no single answer to how to debug at this time.
  • Connectivity: Consider service discovery, whether centralized or integrated.


See Also

Client Server Architecture
Architecture
Architectural Principles
Architectural Pattern
Architectural Risk
Architectural Style
Enterprise Architecture
Service Oriented Architecture (SOA)
IT Governance
Distributed Computing
IT Operations (Information Technology Operations)
IT Sourcing (Information Technology Sourcing)
IT Strategy (Information Technology Strategy)


References

  1. What are Microservices? Microservices.io
  2. What Microservices are Not IBM
  3. History of Microservices Wikipedia
  4. Example Use Cases for Microservices Hazelcast
  5. The Six Characteristics Of Microservices Smart Bear
  6. Examples of Microservices Frameworks for Java Stackify
  7. Benefits of Microservices AWS
  8. Challenges of Microservices Red Hat