Microservices is one of the increasingly popular architecture patterns next to Service Oriented Architecture (SOA), complemented by DevOps and Cloud. Its evolution has been greatly influenced by the disruptive digital innovation trends in modern business and the evolution of technology in the last few years. We will examine these two catalysts--business demands and technology--in this section.

In this era of digital transformation, enterprises are increasingly adopting technologies as one of the key enablers for radically increasing their revenue and customer base. Enterprises are primarily using social media, mobile, cloud, big data, and Internet of Things (IoT) as vehicles for achieving the disruptive innovations. Using these technologies, enterprises are finding new ways to quickly penetrate the market, which severely pose challenges to the traditional IT delivery mechanisms.   

The following graph shows the state of traditional development and microservices against the new enterprise challenges, such as agility, speed of delivery, and scale:

Gone are the days where businesses invested in large application developments with turnaround times of a few years. Enterprises are no longer interested in developing consolidated applications for managing their end-to-end business functions as they did a few years ago.

The following graph shows the state of traditional monolithic application and microservices in comparison with the turnaround time and cost:

Today, for instance, airlines are not investing in rebuilding their core mainframe reservation systems as another monolithic monster. Financial institutions are not rebuilding their core banking systems. Retailers and other industries are not rebuilding heavyweight supply chain management applications, such as their traditional ERP's. Focus has been shifted from building large applications to building quick win, point solutions that cater to the specific needs of the business in the most agile way possible.

Let's take an example of an online retailer running with a legacy monolithic application. If the retailer wants to innovate their sales by offering their products personalized to a customer based on the customer's past shopping preferences and much more, or they want to enlighten customers by offering products to customer based on propensity to buy a product.

In such cases, enterprises want to quickly develop a personalization engine or an offer engine based on their immediate needs, and plug them into their legacy application, as shown here:

As shown in the preceding diagram, rather than investing on rebuilding the Core Legacy System, this will either be done by passing the responses through the new functions, as shown in the diagram marked A, or modifying the Core Legacy System to call out these functions as part of the processing, as shown in the diagram marked B. These functions are typically written as microservices.

This approach gives organizations a plethora of opportunities to quickly try out new functions with lesser cost in an experimental mode. Business can later validate key performance indicators change or replace these implementations if required.

Emerging technologies have made us rethink the way we build software systems. For example, a few decades ago, we couldn't even imagine a distributed application without a two-phase commit. Later, NoSQL databases made us think differently.

Similarly, these kinds of paradigm shifts in technology have reshaped all layers of software architecture.

The emergence of HTML 5, CSS3, and the advancement of mobile applications repositioned user interfaces. Client-side JavaScript frameworks, such as Angular, Ember, React, Backbone, and more, are immensely popular due to their capabilities around responsive and adaptive designs.

With cloud adoptions steamed into the mainstream, Platform as a Services (PaaS) providers, such as Pivotal CF, AWS, Sales Force, IBM Bluemix, Redhat OpenShift, and more, made us rethink the way we build middleware components. The container revolution created by Docker radically influenced the infrastructure space. Container orchestration tools, such as Mesosphere DCOS, made infrastructure management much easier. Serverless added further easiness in application managements.

Integration landscape has also changed with the emerging Integration Platform as a Services (iPaaS), such as Dell Boomi, Informatica, MuleSoft, and more. These tools helped organizations stretch integration boundaries beyond the traditional enterprise.

NoSQL and NewSQL have revolutionized the space of the database. A few years ago, we had only a few popular databases, all based on relational data modeling principles. Today, we have a long list of databases: Hadoop, Cassandra, CouchDB, Neo 4j, and NuoDB, to name a few. Each of these databases addresses certain specific architectural problems.

Application architecture has always been evolving alongside with demanding business requirements and evolution of technologies.

Different architecture approaches and styles, such as mainframes, client server, n-tier, and service oriented were popular at different times. Irrespective of the choice of architecture styles, we always used to build one or the other forms of monolithic architectures. Microservices architecture evolved as a result of modern business demands, such as agility, speed of delivery, emerging technologies, and learning from previous generations of architectures:

Microservices help us break the boundaries of the monolithic application and build a logically independent smaller system of systems, as shown in the preceding diagram.

Microservices are an architectural style used by many organizations today as a game changer to achieve high degrees of agility, speed of delivery, and scale. Microservices gives us a way to develop physically separated modular applications.

Microservices are not invented. Many organizations, such as Netflix, Amazon, and eBay had successfully used the divide and conquer technique for functionally partitioning their monolithic applications into smaller atomic units, each performing a single function. These organizations solved a number of prevailing issues they were experiencing with their monolithic application. Following the success of these organizations, many other organizations started adopting this as a common pattern for refactoring their monolithic applications. Later, evangelists termed this pattern microservices architecture.

Microservices originated from the idea of Hexagonal Architecture, which was coined by Alister Cockburn back in 2005. Hexagonal Architecture, or Hexagonal pattern, is also known as the Ports and Adapters pattern.

In simple terms, Hexagonal architecture advocates to encapsulate business functions from the rest of the world. These encapsulated business functions are unaware of their surroundings. For example, these business functions are not even aware of input devices or channels and message formats used by those devices. Ports and adapters at the edge of these business functions convert messages coming from different input devices and channels to a format that is known to the business function. When new devices are introduced, developers can keep adding more and more ports and adapters to support those channels without touching business functions. One may have as many ports and adapters to support their needs. Similarly, external entities are not aware of business functions behind these ports and adapters. They will always interface with these ports and adapters. By doing so, developers enjoy the flexibility to change channels and business functions without worrying too much about future proofing interface designs.

The following diagram shows the conceptual view of Hexagonal Architecture:

In the preceding diagram, the application is completely isolated and exposed through a set of frontend adapters, as well as a set of backend adapters. Frontend adaptors are generally used for integrating UI and other APIs, whereas backend adapters are used for connecting to various data sources. Ports and adapters on both sides are responsible for converting messages coming in and going out to appropriate formats expected by external entities. Hexagonal architecture was the inspiration for microservices.

When we look for a definition for microservices, there is no single standard way of describing them. Martin Fowler defines microservices as follows:

The definition used in this book is as follows:

The preceding diagram depicts a traditional n-tier application architecture, having a Presentation Layer, Business Layer, and Database Layer. Modules A, B, and C represent three different business capabilities. The layers in the diagram represent separation of architecture concerns. Each layer holds all three business capabilities pertaining to that layer. The presentation layer has web components of all three modules, the business layer has business components of all three modules, and the database host tables of all three modules. In most cases, layers are physically spreadable, whereas modules within a layer are hardwired.

Let's now examine a microservices-based architecture:

As we can see in the preceding diagram, the boundaries are inversed in the microservices architecture. Each vertical slice represents a microservice. Each microservice will have its own presentation layer, business layer, and database layer. Microservices are aligned towards business capabilities. By doing so, changes to one microservice does not impact others.

There is no standard for communication or transport mechanisms for microservices. In general, microservices communicate with each other using widely adopted lightweight protocols, such as HTTP and REST, or messaging protocols, such as JMS or AMQP. In specific cases, one might choose more optimized communication protocols, such as Thrift, ZeroMQ, Protocol Buffers, or Avro.

Since microservices are more aligned to business capabilities and have independently manageable life cycles, they are the ideal choice for enterprises embarking on DevOps and cloud. DevOps and cloud are two facets of microservices.

A honeycomb is an ideal analogy for representing the evolutionary microservices architecture:

In the real world, bees build a honeycomb by aligning hexagonal wax cells. They start small, using different materials to build the cells. Construction is based on what is available at the time of building. Repetitive cells form a pattern, and result in a strong fabric structure. Each cell in the honeycomb is independent, but also integrated with other cells. By adding new cells, the honeycomb grows organically to a big, solid structure. The content inside the cell is abstracted and is not visible outside. Damage to one cell does not damage other cells, and bees can reconstruct those cells without impacting the overall honeycomb.

In this section, we will examine some of the principles of the microservices architecture. These principles are a must have when designing and developing microservices. The two key principles are single responsibility and autonomous. 

The single responsibility principle is one of the principles defined as part of the SOLID design pattern. It states that a unit should only have one responsibility.

It implies that a unit, either a class, a function, or a service, should have only one responsibility. At no point do two units share one responsibility, or one unit perform more than one responsibility. A unit with more than one responsibility indicates tight coupling:

As shown in the preceding diagram, Customer, Product, and Order are different functions of an e-commerce application. Rather than building all of them into one application, it is better to have three different services, each responsible for exactly one business function, so that changes to one responsibility will not impair the others. In the preceding scenario, Customer, Product, and Order were treated as three independent microservices.

Microservices are self-contained, independently deployable, and autonomous services that take full responsibility of a business capability and its execution. They bundle all dependencies including the library dependencies; execution environments, such as web servers and containers; or virtual machines that abstract the physical resources.

One of the major differences between microservices and SOA is in its level of autonomy. While most of the SOA implementations provide the service-level abstraction, microservices go further and abstract the realization and the execution environment.

In traditional application developments, we build a war or a ear, then deploy it into a JEE application server, such as JBoss, Weblogic, WebSphere, and more. We may deploy multiple applications into the same JEE container. In the microservices approach, each microservice will be built as a fat jar embedding all dependencies and run as a standalone Java process:

Microservices may also get their own containers for execution, as shown in the preceding diagram. Containers are portable, independently manageable, and lightweight runtime environments. Container technologies, such as Docker, are an ideal choice for microservices deployments.

The microservices definition discussed earlier in this chapter is arbitrary. Evangelists and practitioners have strong, but sometimes, different opinions on microservices. There is no single, concrete, and universally accepted definition for microservices. However, all successful microservices implementations exhibit a number of common characteristics. Therefore, it is important to understand these characteristics rather than sticking to theoretical definitions. Some of the common characteristics are detailed in this section.

In the microservices world, services are first class citizens. Microservices expose service endpoints as APIs and abstract all their realization details. The internal implementation logic, architecture, and technologies, including programming language, database, quality of services mechanisms, and more, are completely hidden behind the service API.

Moreover, in the microservices architecture, there is no more application development, instead organizations will focus on service development. In most enterprises, this requires a major cultural shift in the way applications are built.

In a customer profile microservice, the internals, such as data structure, technologies, business logic, and so on, will be hidden. It wont be exposed or visible to any external entities. Access will be restricted through the service endpoints or APIs. For instance, customer profile microservices may expose register customer and get customers as two APIs for others to interact.

Since microservices are more or less like a flavor of SOA, many of the service characteristics defined in the SOA are applicable to microservices as well.

The following are some of the characteristics of services that are applicable to microservices as well:

• Service contract: Similar to SOA, microservices are described through well-defined service contracts.  In the microservices world, JSON and REST are universally accepted for service communication. In case of JSON/REST, there are many techniques used to define service contracts. JSON Schema, WADL, Swagger, and RAML are a few examples. 
• Loose coupling: Microservices are independent and loosely coupled. In most cases, microservices accept an event as input and respond with another event.  Messaging, HTTP, and REST are commonly used for interaction between microservices. Message-based endpoints provide higher levels of decoupling.  
• Service abstraction: In microservices, service abstraction is not just abstraction of service realization, but also provides complete abstraction of all libraries and environment details, as discussed earlier.
• Service reuse: Microservices are course grained reusable business services. These are accessed by mobile devices and desktop channels, other microservices, or even other systems.
• Statelessness: Well-designed microservices are a stateless, shared nothing with no shared state, or conversational state maintained by the services. In case there is a requirement to maintain state, they will be maintained in a database, perhaps in-memory.
• Services are discoverable: Microservices are discoverable. In a typical microservices environment, microservices self-advertise their existence and make themselves available for discovery. When services die, they automatically take themselves out from the microservices ecosystem.
• Service interoperability: Services are interoperable as they use standard protocols and message exchange standards. Messaging, HTTP, and more are used as the transport mechanism. REST/JSON is the most popular method to develop interoperable services in the microservices world. In cases where further optimization is required on communications, then other protocols such as Protocol Buffers, Thrift, Avro, or Zero MQ could be used. However, use of these protocols may limit the overall interoperability of the services.
• Service Composeability: Microservices are composeable. Service composeability is achieved either through service orchestration or service choreography.

Well-designed microservices are aligned to a single business capability; therefore, they perform only one function. As a result, one of the common characteristics we see in most of the implementations are microservices with smaller footprints.

When selecting supporting technologies, such as web containers, we will have to ensure that they are also lightweight so that the overall footprint remains manageable. For example, Jetty or Tomcat are better choices as application containers for microservices as compared to more complex traditional application servers, such as Weblogic or WebSphere.

Container technologies such as Docker also helps us keep the infrastructure footprint as minimal as possible compared to hypervisors such as VMware or Hyper-V.

As shown in the preceding diagram, microservices are typically deployed in Docker containers, which encapsulate the business logic and needed libraries. This helps us quickly replicate the entire setup on a new machine, a completely different hosting environment, or even move across different cloud providers. Since there is no physical infrastructure dependency, containerized microservices are easily portable.

Since microservices are autonomous and abstract everything behind the service APIs, it is possible to have different architectures for different microservices. A few common characteristics that we see in microservices implementations are as follows:

• Different services use different versions of the same technologies. One microservice may be written on Java 1.7 and another one could be on Java 1.8.
• Different languages for developing different microservices, such as one microservice in Java and another one in Scala.
• Different architectures such as one microservice using Redis cache to serve data while another microservice could use MySQL as a persistent data store.

A polyglot language scenario is depicted in the following diagram: 

In the preceding example, since Hotel Search is expected to have high transaction volumes with stringent performance requirements, it is implemented using Erlang. In order to support predictive search, Elastic Search is used as the data store. At the same time, Hotel Booking needs more ACID transactional characteristics. Therefore, it is implemented using MySQL and Java. The internal implementations are hidden behind service endpoints defined as REST/JSON over HTTP.

Most of the microservices implementations are automated to a maximum, ranging from development to production.

Since microservices break monolithic applications into a number of smaller services, large enterprises may see a proliferation of microservices. Large numbers of microservices are hard to manage until and unless automation is in place. The smaller footprint of microservices also helps us automate the microservices development to deployment life cycle. In general, microservices are automated end to end, for example, automated builds, automated testing, automated deployment, and elastic scaling:

As indicated in the diagram, automations are typically applied during the development, test, release, and deployment phases. 

Different blocks in the preceding diagram are explained as follows:

• The development phase will be automated using version control tools, such as Git, together with continuous integration (CI) tools, such as Jenkins, Travis CI, and more. This may also include code quality checks and automation of unit testing. Automation of a full build on every code check-in is also achievable with microservices.
• The testing phase will be automated using testing tools such as Selenium, Cucumber, and other AB testing strategies. Since microservices are aligned to business capabilities, the number of test cases to automate will be fewer compared to the monolithic applications; hence, regression testing on every build also becomes possible.
• Infrastructure provisioning will be done through container technologies, such as Docker, together with release management tools, such as Chef or Puppet, and configuration management tools, such as Ansible. Automated deployments are handled using tools such as Spring Cloud, Kubernetes, Mesos, and Marathon.

Most of the large scale microservices implementations have a supporting ecosystem in place. The ecosystem capabilities include DevOps processes, centralized log management, service registry, API gateways, extensive monitoring, service routing, and flow control mechanisms:

Microservices work well when supporting capabilities are in place, as represented in the preceding diagram.

Successful microservices implementations encapsulate logic and data within the service. This results in two unconventional situations: 

• Distributed data and logic
• Decentralized governance

Compared to traditional applications, which consolidate all logic and data into one application boundary, microservices decentralize data and logic. Each service, aligned to a specific business capability, owns its own data and logic: 

The dotted line in the preceding diagram implies the logical monolithic application boundary. When we migrate this to microservices, each microservice, A, B, and C, creates its own physical boundaries.

Microservices don't typically use centralized governance mechanisms the way they are used in SOA. One of the common characteristics of microservices implementations are that they are not relaying on heavyweight enterprise-level products, such as an Enterprise Service Bus (ESB). Instead, the business logic and intelligence are embedded as a part of the services themselves.

A retail example with ESB is shown as follows: 

A typical SOA implementation is shown in the preceding diagram. Shopping Logic is fully implemented in the ESB by orchestrating different services exposed by Customer, Order, and Product. In the microservices approach, on the other hand, shopping itself will run as a separate microservice, which interacts with Customer, Product, and Order in a fairly decoupled way.

SOA implementations are heavily relaying on static registry and repository configurations to manage services and other artifacts. Microservices bring a more dynamic nature into this. Hence, a static governance approach is seen as an overhead in maintaining up-to-date information. This is why most of the microservices implementations use automated mechanisms to build registry information dynamically from the runtime topologies.

Antifragility is a technique successfully experimented with at Netflix. It is one of the most powerful approaches to build fail-safe systems in modern software development.

In the antifragility practice, software systems are consistently challenged. Software systems evolve through these challenges, and, over a period of time, get better and better to withstand these challenges. Amazon's Game Day exercise and Netflix's Simian Army are good examples of such antifragility experiments. 

Fail Fast is another concept used to build fault-tolerant, resilient systems. This philosophy advocates systems that expect failures versus building systems that never fail. Importance has to be given to how quickly the system can fail, and, if it fails, how quickly it can recover from that failure. With this approach, the focus is shifted from Mean Time Between Failures (MTBF) to Mean Time To Recover (MTTR). A key advantage of this approach is that if something goes wrong, it kills itself, and the downstream functions won’t be stressed.

Self-Healing is commonly used in microservices deployments, where the system automatically learns from failures and adjusts itself. These systems also prevent future failures.

There is no one size fits all approach when implementing microservices. In this section, different examples are analyzed to crystalize the microservices concept.

In the first example, we will review a holiday portal--Fly By Points. Fly By Points collects points that are accumulated when a customer books a hotel, flight, or car through their online website. When a customer logs in to the Fly By Points website, they will be able to see the points accumulated, personalized offers that can be availed by redeeming the points, and upcoming trips, if any:

Let's assume that the preceding page is the home page after login. There are 2 upcoming trips for Jeo, 4 personalized offers, and 21123 points. When the user clicks on each of the boxes, details will be queried and displayed.

Holiday portal has a Java, Spring-based traditional monolithic application architecture, as follows:

As shown in the preceding diagram, Holiday portal's architecture is web-based and modular with clear separation between layers. Following the usual practice, Holiday portal is also deployed as a single war file deployed on a web server such as Tomcat. Data is stored in an all encompassing backing relational database. This is a good fit for the purposes of architecture when the complexities are less. As the business grows, the user base expands and the complexity also increases.

This results in a proportional increase in the transaction volumes. At this point, enterprises should look for rearchitecting the monolithic application to microservices for better speed of delivery, agility, and manageability:

Upon examining the simple microservices version of this application, we will immediately see a few things in this architecture:

• Each subsystem has now become an independent system by itself--a microservice. There are three microservices representing three business functions--Trips, Offers, and Points. Each one has its internal data store and middle layer. The internal structure of each service remains the same.
• Each service encapsulates its own database as well as its own HTTP listener. As opposed to the previous model, there is no web server and there is no war. Instead, each service has its own embedded HTTP listener, such as Jetty, Tomcat, and more.
• Each microservice exposes a rest service to manipulate the resources/entities that belong to that service.

It is assumed that the presentation layer is developed using a client-side JavaScript MVC framework, such as Angular JS. These client-side frameworks are capable of invoking REST calls directly.

When the web page is loaded, all three boxes, Trips, Offers, and Points, will be displayed with details such as points, number of offers, and number of trips. This will be done by each box independently making asynchronous calls to the respective backend microservices using REST. There is no dependency between the services at the service layer. When the user clicks on any of the boxes, the screen will be transitioned and will load the details of the clicked item. This will be done by making another call to the respective microservice.    

This third example is a simple travel agent portal application. In this example, we will see both synchronous REST calls as well as asynchronous events.

In this case, portal is just a container application with multiple menu items or links in the portal. When specific pages are requested, for example, when the menu is clicked or a link is clicked, they will be loaded from the specific microservices:

The architecture of the Travel Agent Portal backed with multiple microservices is shown as follows: 

When a customer requests a booking, the following events will take place internally:

• The travel agent opens the flight UI, searches for a flight, and identifies the right flight for the customer. Behind the scenes, the flight UI will be loaded from the Flight microservice. The flight UI only interacts with its own backend APIs within the Flight microservice. In this case, it makes a REST call to the Flight microservice to load the flights to be displayed.
• The travel agent then queries the customer details by accessing the customer UI. Similar to the flight UI, the customer UI will be loaded from the Customer microservices. Actions in the customer UI will invoke REST calls on the Customer microservice. In this case, the customer details will be loaded by invoking appropriate APIs on the Customer microservice.
• Then the travel agent checks the visa details to see the eligibility to travel to the selected country. This will also follow the same pattern as mentioned in the previous two points.
• Then the travel agent makes a booking using the booking UI from the Booking microservices, which again follows the same pattern.
• The payment pages will be loaded from the Payment microservice. In general, the payment service will have additional constraints, including the Payment Card Industry Data Security Standard (PCIDSS) compliance, such as protecting and encrypting data in motion and data at rest. The advantage of the microservices approach is that none of the other microservices need to be considered under the purview of PCIDSS as opposed to the monolithic application, where the complete application comes under the governing rules of PCIDSS. Payment also follows the same pattern described earlier.
• Once the booking is submitted, the Booking Service calls the flight service to validate and update the flight booking. This orchestration is defined as a part of the Booking microservices. Intelligence to make a booking is also held within the Booking microservices. As a part of the booking process, it also validates, retrieves, and updates the Customer microservice.
• Finally, the Booking microservice sends a booking event, which the Notification Services picks up, and sends a notification to the customer.

The interesting factor here is that we can change the user interface, logic, and data of a microservice without impacting any other microservices.

This is a clean and neat approach. A number of portal applications could be built by composing different screens from different microservices, especially for different user communities. The over all behavior and navigation will be controlled by the portal application.

The approach has a number of challenges unless the pages are designed with this approach in mind. Note that the site layouts and static contents will be loaded from the Content Management System (CMS) as layout templates. Alternately, this could be stored in a web server. The site layout may have fragments of User Interfaces, which will be loaded from the microservices at runtime.

Microservice offers a number of benefits over the traditional multi-tier monolithic architectures. This section explains some of the key benefits of the microservices architecture approach.

With microservices, architects and developers get flexibility in choosing the most suitable technology and architecture for a given scenario. This gives the flexibility to design better fit solutions in a more cost-effective way.

Since microservices are autonomous and independent, each service can run with its own architecture or technology, or different versions of technologies.

The following image shows a simple, practical example of polyglot architecture with microservices:

There is a requirement to audit all system transactions and record transaction details such as request and response data, users who initiated the transaction, the service invoked, and so on.

As shown in the preceding diagram, while core services like Order microservice and Product microservice use a relational data store, the Audit microservice persists data in a Hadoop File System (HDFS). A relational data store is neither ideal nor cost effective to store large data volumes, like in the case of audit data. In the monolithic approach, the application generally uses a shared, single database that stores the Order, Product, and Audit data.

In this example, audit service is a technical microservice using a different architecture. Similarly, different functional services could also use different architectures.

In another example, there could be a Reservation microservice running on Java 7, while a Search microservice could be running on Java 8. Similarly, an Order microservice could be written on Erlang, whereas a Delivery microservice could be on the Go language. None of these are possible with a monolithic architecture.

Modern enterprises are thriving toward quick wins. Microservices is one of the key enablers for enterprises to do disruptive innovation by offering the ability to experiment and Fail Fast.

Since services are fairly simple and smaller in size, enterprises can afford to experiment with new processes, algorithms, business logic, and more. With large monolithic applications, experimentation was not easy, straightforward, or cost effective. Businesses had to spend a large sum of money to build or change an application to try out something new. With microservices, it is possible to write a small microservice to achieve the targeted functionality, and plug it into the system in a reactive style. One can then experiment with the new function for a few months. Moreover, if the new microservice is not working as expected, change or replace it with another one. The cost of change will be considerably less compared to the monolithic approach:

In another example of an airline booking website, the airline wants to show personalized hotel recommendations in their booking page. The recommendations have to be displayed on the booking confirmation page.

As shown in the preceding diagram, it is convenient to write a microservice that can be plugged into the monolithic applications booking flow rather than incorporating this requirement in the monolithic application itself. The airline may choose to start with a simple recommendation service, and keep replacing it with newer versions until it meets the required accuracy.

Since microservices are smaller units of work, it enables us to implement selective scalability and other Quality of Services (QoS).

Scalability requirements may be different for different functions in an application. Monolithic applications are generally packaged as a single war or an ear. As a result, applications can only be scaled as a whole. There is no option to scale a module or a subsystem level. An I/O intensive function, when streamed with high velocity data, could easily bring down the service levels of the entire application.

In the case of microservices, each service could be independently scaled up or down. Since scalability can be selectively applied for each service, the cost of scaling is comparatively less with the microservices approach.

In practice, there are many different ways available to scale an application, and this is largely constraint to the architecture and behavior of the application. The Scale Cube defines primarily three approaches to scale an application:

• X-axis scaling, by horizontally cloning the application
• Y-axis scaling, by splitting different functionality
• Z-axis scaling, by partitioning or sharding the data.

When Y-axis scaling is applied to monolithic applications, it breaks the monolithic into smaller units aligned with business functions. Many organizations successfully applied this technique to move away from monolithic application. In principle, the resulting units of functions are inline with the microservices characteristics.

For instance, on a typical airline website, statistics indicates that the ratio of flight search versus flight booking could be as high as 500:1. This means one booking transaction for every 500 search transactions. In this scenario, search needs 500 times more scalability than the booking function. This is an ideal use case for selective scaling:

The solution is to treat search requests and booking requests differently. With a monolithic architecture, this is only possible with Z scaling in the scale cube. However, this approach is expensive, as, in Z scale, the entire codebase will be replicated.

In the preceding diagram, Search and b are designed as different microservices so that Search can be scaled differently from Booking. In the diagram, Search has three instances and Booking has two instances. Selective scalability is not limited to the number of instances, as shown in the preceding diagram, but also in the way in which the microservices are architected. In the case of Search, an In-Memory Data Grid (IMDG) such as Hazelcast can be used as the data store. This will further increase the performance and scalability of Search. When a new Search microservice instance is instantiated, an additional IMDG node will be added to the IMDG cluster. Booking does not require the same level of scalability. In the case of Booking, both instances of the Booking microservices are connected to the same instance of the database.

Microservices are self-contained independent deployment modules, enabling us to substitute one microservice with another similar microservice.

Many large enterprises follow buy-versus-build policies for implementing software systems. A common scenario is to build most of the functions in-house and buy certain niche capabilities from specialists outside. This poses challenges in the traditional monolithic applications since these application components are highly cohesive. Attempting to plug in third-party solutions to the monolithic applications results in complex integrations. With microservices, this is not an afterthought. Architecturally, a microservice can be easily replaced by another microservice developed, either in-house or even extended by a microservice from a third party:

A pricing engine in the airline business is complex. Fares for different routes are calculated using complex mathematical formulas known as pricing logic. Airlines may choose to buy a pricing engine from the market instead of building the product in-house. In the monolithic architecture, Pricing is a function of Fares and Booking. In most cases, Pricing, Fares, and Bookings are hardwired, making it almost impossible to detach.

In a well-designed microservices system, Booking, Fares, and Pricing will be independent microservices. Replacing the Pricing microservice will have only a minimal impact on any other services, as they are all loosely coupled and independent. Today, it could be a third-party service, tomorrow, it could be easily substituted by another third-party service or another home grown service.

Microservices help us build systems that are organic in nature. This is significantly important when migrating monolithic systems gradually to microservices.

Organic systems are systems that grow laterally over a period of time by adding more and more functions to it. In practice, applications grow unimaginably large in its lifespan, and, in most cases, the manageability of the application reduces dramatically over that same period of time.

Microservices are all about independently manageable services. This enables us to keep adding more and more services as the need arises, with minimal impact on the existing services. Building such systems do not need huge capital investment. Hence, businesses can keep building as part of their operational expenditure.

A loyalty system in an airline was built years ago, targeting individual passengers. Everything was fine until the airline started offering loyalty benefits to their corporate customers. Corporate customers are individuals grouped under corporations. Since the current system's core data model is flat, targeting individuals, the corporate requirement needs a fundamental change in the core data model, and hence, a huge rework to incorporate this requirement.

As shown in the following diagram, in a microservices-based architecture, customer information would be managed by the Customer microservices, and loyalty by the Loyalty microservice:

In this situation, it is easy to add a new Corporate Customer microservice to manage corporate customers. When a corporation is registered, individual members will be pushed to the Customer microservices to manage them as usual. The Corporate Customer microservice provides a corporate view by aggregating data from the Customer microservice. It will also provide services to support corporate-specific business rules. With this approach, adding new services will have only a minimal impact on existing services.

Since microservices are smaller in size and have minimal dependencies, they allow the migration of services that are using end-of-life technologies with minimal cost.  

Technology changes are one of the barriers in software development. In many traditional monolithic applications, due to the fast changes in technology, today's next generation applications could easily become legacy, even before releasing to production. Architects and developers tend to add a lot of protection against technology changes by adding layers of abstractions. However, in reality, this approach doesn't solve the issue, but, instead, it results in over-engineered systems. Since technology upgrades are often risky and expensive, with no direct returns for the business, the business may not be happy to invest in reducing the technology debt of the applications.

With microservices, it is possible to change or upgrade technology for each service individually, rather than upgrading an entire application.

Upgrading an application with, for instance, five million lines written on EJB 1.1 and Hibernate to Spring, JPA, and REST services is almost like rewriting the entire application. In the microservices world, this could be done incrementally.

As shown in the preceding diagram, while older versions of the services are running on old versions of technologies, new service developments can leverage the latest technologies. The cost of migrating microservices with end-of-life technologies will be considerably less compared to enhancing monolithic applications.

Since microservices package the service runtime environment along with the service itself, it enables multiple versions of the service to coexist in the same environment.

There will be situations where we will have to run multiple versions of the same service at the same time. Zero downtime promote, where one has to gracefully switch over from one version to another, is one example of such a scenario, as there will be a time window where both services will have to be up and running simultaneously. With monolithic applications, this is a complex procedure, since upgrading new services in one node of the cluster is cumbersome as, for instance, this could lead to class loading issues. A Canary release, where a new version is only released to a few users to validate the new service, is another example where multiple versions of the services have to coexist.

With microservices, both these scenarios are easily manageable. Since each microservice uses independent environments, including the service listeners such as embedded Tomcat or Jetty, multiple versions can be released and gracefully transitioned without many issues. Consumers, when looking up services, look for specific versions of services. For example, in a canary release, a new user interface is released to user A. When user A sends a request to the microservice, it looks up the canary release version, whereas all other users will continue to look up the last production version.

Care needs to be taken at database level to ensure that the database design is always backward compatible to avoid breaking changes.

As shown in the following diagram, version V01 and V02 of the Customer service can coexist as they are not interfering with each other, given their respective deployment environment:

Routing rules can be set at the gateway to divert traffic to specific instances, as shown in the diagram. Alternatively, clients can request specific versions as a part of the request itself. In the diagram, the gateway selects the version based on the region from which the request originated.

Microservices help us build self-organizing systems. A self-organizing system supporting automated deployment will be resilient and exhibits self-healing and self-learning capabilities.

In a well-architected microservice system, services are unaware of other services. It accepts a message from a selected queue and processes the message. At the end of the process, it may send out another message that triggers other services. This allows us to drop any service into the ecosystem without analyzing the impact on the overall system. Based on the input and output, the service will self-organize into the ecosystem. No additional code changes or service orchestration is required. There is no central brain to control and coordinate the processes.

Imagine an existing notification service that listens to an INPUT queue and sends notifications to a Simple Mail Transfer Protocol (SMTP) server as follows:

If later, a personalization engine needs to be introduced to personalize messages before sending it to the customer, the personalization engine is responsible for changing the language of the message to the customer's native language.

The updated service linkage is shown as follows:

With microservices, a new personalization service will be created to do this job. The input queue will be configured as INPUT in an external configuration server. The personalization service will pick up the messages from the INPUT queue (earlier, this was used by the notification service), and send the messages to the OUTPUT queue after completing the process. The notification service's input queue will then send to OUTPUT. From the very next moment onward, the system automatically adopts this new message flow.

Microservices enable us to develop transparent software systems. Traditional systems communicate with each other through native protocols and hence behave like a black-box application. Business events and system events, unless published explicitly, are hard to understand and analyze. Modern applications require data for business analysis, to understand dynamic system behaviors, and analyze market trends, and they also need to respond to real-time events. Events are useful mechanisms for data extraction.

A well-architected microservice always works with events for both input and output. These events can be tapped by any services. Once extracted, events can be used for a variety of use cases.

For example, businesses want to see the velocity of orders categorized by the product type in real-time. In a monolithic system, we will need to think about how to extract these events, which may impose changes in the system.

The following diagram shows the addition of New Event Aggregation Service without impacting existing services:

In the microservices world, Order Event is already published whenever an order is created. This means that it is just a matter of adding a new service to subscribe to the same topic, extract the event, perform the requested aggregations, and push another event for the dashboard to consume.

Microservices are one of the key enablers of DevOps. DevOps is widely adopted as a practice in many enterprises, primarily to increase the speed of delivery and agility. Successful adoption of DevOps requires cultural changes and process changes, as well as architectural changes. It advocates to have agile development, high velocity release cycles, automatic testing, automatic infrastructure provisioning, and automated deployment. Automating all these processes is extremely hard to achieve with traditional monolithic applications. Microservices are not the ultimate answer, but microservices are at the center stage in many DevOps implementations. Many DevOps tools and techniques are also evolving around the use of microservices.

Considering a monolithic application takes hours to complete a full build and twenty to thirty minutes to start the application, one can see that this kind of application is not ideal for DevOps automation. It is hard to automate continuous integration on every commit. Since large monolithic applications are not automation friendly, continuous testing and deployments are also hard to achieve.

On the other hand, small footprint microservices are more automation-friendly, and, therefore, they can more easily support these requirements.

Microservices also enables smaller, focused agile teams for development. Teams will be organized based on the boundaries of microservices.

In this chapter, we learned about the fundamentals of microservices with the help of a few examples.

We explored the evolution of microservices from traditional monolithic applications. We examined some of the principles and mind shift required for modern application architectures. We also looked at some of the common characteristics repeatedly seen in most of the successful microservices implementations. Finally, we also learned the benefits of microservices. 

In the next chapter, we will analyze the link between microservices and a few other architecture styles. We will also examine common microservice use cases.