Achieving Big Results With Microservices
These days, enterprises of all shapes and sizes need to respond to client needs at faster speeds. At the same time, business capabilities increasingly depend on software and technology stacks. The end result is the need for software that can be quickly (and reliably) built and implemented. Businesses can choose to speed up this development by focusing on the unification of software development via Microservices. Microservices are on the cutting edge of enterprise application architecture. Microservices architecture brings a new kind of flexibility to application development. The dynamic approach increases business capabilities by breaking down an application into its smaller parts.
"Driven by the increased priorities of deployability and modifiability and the concomitantly increased degree of requirements on these quality attributes, we moved from a monolithic architecture to a Microservices architecture. Rather than building large monolithic applications, we organize systems into small, self-contained, single-responsibility units that can be independently developed, tested, and deployed."
- LIANGPING CHEN (HUAWEI TECHNOLOGIES) Microservices: Architecting for Continuous Delivery and DevOps
In a phrase, microservices develop software applications by connecting small, modular services. These connected modules are used to create a lightweight application for a specific business goal. Using a microservices platform allows quicker deployment, more flexibility modification, and a more manageable scaling process. In this post, we dive into all of your most relevant questions about microservices architecture. You’ll find answers to all of these questions:
What are microservices?
How is microservice architecture used?
What are the benefits of microservices?
What are the core components and services of a microservice architecture?
How do microservices fit within the application infrastructure?
The Evolution of Application Infrastructure
Microservices did not evolve in a vacuum. The new architecture was a direct result of the limitations the traditional, tiered approach to software development. Within this framework there are three approaches to software architecture: monolithic, service oriented and microservice. To give you an idea of how microservice architecture is used and the benefits of the architecture, we breakdown the three here.
The Basics of Monolithic Architecture
A monolithic software architecture takes a tiered approach to design, creating a single application. It quite literally means that the software is constructed as one self-contained piece. All components are interconnected - and dependent on each other! Some of the key features (and potential drawbacks) of monolithic architecture include:
Tightly coupled components
Normalized data models
Single technology stack
Large development teams
Expensive to scale infrastructure
Long release cycles
Difficult to change
Highly sensitive to errors
With monolithic architecture, users, managers, products and inventory are all interconnected - as are their respective managers. The usual approach is to make in-process calls using application logic on a single application platform.
The Basics of Service Oriented Architecture
In contrast to the monolithic architecture, service oriented architecture takes a client approach to development. The architecture type has all of these features and potential benefits:
Tightly coupled services
Shorter release cycles
Normalized data models
Single technology stack
Several smaller development teams
Cheaper to scale infrastructure
Less sensitive to errors
The Basics of MicroserviceS Architecture
Microservices architecture is an even more dynamic development approach than service oriented architecture. The architecture turns development on its head, focusing in on the purpose and function of each individual part of an application. It is the near opposite of waterfall design. The features and benefits of microservices include:
Loosely coupled services
Small codebase per service
Built for change
Short release cycles
Denormalized data model
Multiple technology stacks
Several small development teams
Cheaper to scale infrastructure
Resilient to errors
There are generally four levels to how microservices architecture is used:
API Based Architecture: The use of generalized APIs for all use cases and roles.
User-optimized APIs: Specific APIs for users, generalized APIs for managers, with an API gateway in the middle.
Event Driven Architecture: Which pathway is used depends on the purpose of the end user.
Shared Platform Services: Applications are broken down by user applications, application services, platform services and infrastructure services.
Let's get more into the specifics of microservices architecture what microservices look like in practice below.
What do Microservices Look Like in Practice?
So far there is not much of an industry standard for what constitutes a microservices architecture approach. That said, there are a few common elements for any development project utilizing microservices. The microservices that make up the architecture have a few key elements to watch for:
1. They Are Small Services
Microservices provide one or more API endpoints. At the same time, all APIs are related to a single functional domain. APIs are generalized to cover as many use cases as possible. Microservices have a code size small enough for a single Scrum Team to own and manage.
2. They Are Independent Services
Microservices are functionally independent, which means they are not dependent on any other microservice. They also keep their data independent, which means that each microservice has its own data entity to function (i.e. the users manager has a users database). Microservices use the tech stack that is best suited for their use, which translates into technology independence.
3. They Are Event Aware Services
A microseverice publishes and subscribes to all significant events that occur in or affect its domain. The microservice is able to regenerate all of its data simply by replaying past events.
4. They Are Extensible, Expendable Services
With an iterative development approach, multiple instances of the same microservice can coexist. The new version of a service can be tested along with an old version. At the same time, other services are not affected by the changes in one service.
Phases of a MicroserviceS Platform Development
Even for the lean approach in microservices, development cannot be achieved overnight. In general, developing a microservice platform can be broken down into four phases:
Phase 1: Planning. Specifications, contracts, customization and reference implementations
Phase 2: Development and Testing. UI components can be implemented for testing.
Phase 3: Cloud Implementation. The implementation of platform services on AWS and Azure.
Phase 4: On Premise Implementation. The implementation of platform services on Linux/Open Source and Microsoft.
Platform Components & Services of Microservices
Most microservice architecture platforms will have the following platform components in common:
UI layouts & components
Search forms & Document manager
Conversational User Interface
Reporting & Analytics
Additionally, microservices typically have the following associated services:
UI components that can be used to accelerate UI app development.
API services that are shared by multiple application services.
The ability to leverage the capabilities of frequently used infrastructure providers (examples include Amazon Web Services and Microsoft Azure).
Application services can be ported from one infrastructure provider to another.
Language binding for frequently used application development platforms (such as Java/Spring, Microsoft .Net, NodeJS, and Python).
Putting it all together- Using Microservices for a Patent Research Platform
Here we present a brief case study to give you a practical idea of what microservices look like. In creating microservice applications for our clients, we are dedicated to finding a solution that directly meets the needs of their business goals. In most cases, this means creating applications that are quickly deployable, flexible and scalable. In this case, our client was looking for a more streamlined architecture for their patent research application. The legacy architecture of the application took on the traditional monolithic form: a single tier following from a database to the application services to the frontend. The design was relatively simple, but the deployment was less than ideal.
Legacy Architecture Presented Several Challenges for the Client
In the image below, you can see the breakdown for the legacy architecture for this patent research application.
The architecture appears simple enough: database at the bottom, providing a foundation of individual services of the application, opening up to the endpoints for patent research application. But the monolithic architecture presented several challenges for the client:
The monolithic approach made for a large and complex application. This made changes to the application slow and cumbersome.
Needing to constantly update the entire application was too much of a burden on the client.
A single database for all application uses put too much strain on the application, lowering the search tool’s performance.
This last issue in particular was a sticking point. With the legacy, monolithic architecture a single search took five seconds. Batch searching a hundred documents took four seconds. Combining the two took a full 15 seconds. This was largely because of the use of a single database routing through a monolithic application. It was also prohibitively slow for many users. On top of the performance issue, the adaptability of the application was a severe drawback. For the legacy architecture, the estimated time to add a new data source to the application was 3 months. In other words, updating the key service of the application took months, rather than days.
But these drawbacks to the patent research application were not without hope of an overhaul. Using the microservices architecture approach, we made the application more nimble and the performance better by leaps and bounds.
Reengineered Architecture Created Faster & More Nimble Application
Revamping this business application meant completely reengineering its architecture. This is where our dedication to microservices comes in. In this image, you can see the reengineered version of the platform for the patent research application. We made a few important changes for our client.
First, we connected the end users and specific uses to specific modules within the application. This meant connecting both the people and the coding pieces involved in the application. It also meant creating individual, functional databases for each module. As you can see in the illustration, the connection breaks down like this:
Users Manager is connected to the users database
Customers Manager is connected to the customers database
Projects Manager connected to projects database
Documents Manager connected to the documents database
Workflows Managers connected to the Workflows database
Collaboration engine connected to the discussions database
Full text search engine connected directly to the search database
Analytics engine connected to the analytics database
This change translates into a simpler interface for all end users, from administration and management to individual search queries.
The second change was the introduction of an API gateway between all modules and user applications. This means that, even with the microservice platform, the patent research application is presented as a single unit on the front-end. Which module is accessed is determined by the user application: the dashboards, intranet, customer portal or admin panel.
The final change was updating the technology stack for the application. Using Amazon Web Services (AWS), we introduced the right language/platform for the right application module. Databases were built using differentiated languages, as were the dashboards, panels and portals of the application. You can see the breakdown of the technology stack here:
Customer Portal: AngularJS
Admin Portal: D3JS
Databases: MariaDB, MongoDB, Elastic Search, Cassandra
Events Queue: Apache Kafka
The End Result: Major Differences in Performance Metrics
Remember the metrics from the legacy architecture of this patent research application? Searches took 5 seconds, and adding a new data source took up to 3 months. In contrast, microservices transformed these performance metrics. With the current architecture, our client sees less than 1 second searches and 1.5 second batch searches. This is about 10X improvement over legacy architecture. At the same time, the microservices architecture has allowed a much more nimble approach to making important changes to the application.
Using microservices, our client can now add a new data source to the application in the matter of one day. The case study highlights just how much of a difference microservices can make in the performance of business applications.
Microservices directly address the business goal of addressing client needs as quickly and efficiently as possible. Much like lean construction, the architecture makes software development efficient without sacrificing reliability and security.
This case study should give you a clear idea of the kind of flexibility microservices architecture can offer your business. If you are interested in reengineering your current business application or looking for a new microservices application, don’t hesitate to reach out today!