Microservices enhance the digital journey of an organisation in so many ways. They optimise costs, make software agile and scalable, and are of immense help when designing digital decoupling architecture for IT migration.
Digital adoption over the cloud by an enterprise can entail digital migration (which comprises re-hosting, re-configuration or re-platforming applications) or digital transformation (which is either refactoring or re-architecting native cloud solutions, or replacing native cloud components). But there is another way, called digital decoupling architecture, that organisations can also use for digitalisation.
Features of digital decoupling architecture
Decoupling data and application architecture: A strategy is adopted to decouple data architecture into reference data and transactional data. Reference databases remain on-premises in legacy IT systems, and applications with transactional data are moved to the cloud.
DevTest adoption in the cloud: On an average, development and test (DevTest) environment usage is 40%-60% every year. Moving these environments to the cloud optimises DevTest infrastructure and monitoring costs, because you pay for only what you use.
Data lake adoption: Data lakes in the cloud are used for reconciliation, regulatory reports, and batch job processing (e.g., using AWS Glue Job).
Agile DevOps: This helps to automate the toolchain process.
These features of digital decoupling enable easier and quicker digital adoption as compared to costly solutions used in the digital transformation path.
Anatomy of microservices architecture
Microservices is a distinctive method of developing software systems that is extremely popular nowadays. Due to its scalability, this method is ideal for the web, mobile, and Internet of Things—or when you’re not sure what kind of devices you’ll need to support in an increasingly cloud-based future.
To understand microservices architecture, one needs to understand its legacy rival — monolithic architecture. Unlike a microservice, a monolith application is always built as a single, autonomous unit. In a two-tier architecture model with client and server components running, the server-side application handles web requests and executes programming logic to handle the data fetching and updating in the underlying database.
Though monolithic architecture is simple in style, the key problem is that all modules are tied up together and hence a change in one module can potentially affect the other. For example, a load in the backend service can affect the response time of GUI. Any small modification made to a piece of code in the application requires building and deploying the complete application. This is where creating a microservice helps.
Microservices architecture optimises resource usage and enables agility in development, where individual teams develop their own microservice which is integrated through API calls or asynchronous messages for inter-process communication. Most importantly, build and deployment is independent of each microservice, which makes it most suitable for continuous delivery.
Netflix, eBay, Amazon, Twitter, PayPal, Gilt, Bluemix, Soundcloud and many other large-scale websites and applications have all evolved from monolithic to microservices architecture.
API pattern development with microservices
Endpoint protection and load balancing requests are very important in the design of a microservices architecture during cloud adoption. There are two ways to handle this efficiently – direct-client-to-microservices pattern and API gateway pattern.
Direct-client-to-microservices pattern is a lightweight solution generally used for small- to medium-sized microservices architecture where server-side web applications can connect to microservices directly without any broker or bridge interface. The performance of such requests is superfast. However, in a production environment where clustered microservice instances are deployed, we need to manually introduce an application gateway to handle the load balancer and manually handle SSL termination in the endpoint instance itself (which can be resource intensive when there are more requests). When a secured request is transmitted through SSL/HTTPS, SSL termination is the process of offloading the data traffic to decrypt and send to the endpoint.
An API gateway pattern is adaptive and flexible, and introduces an API gateway between consumers and microservices. This avoids coupling of microservices requests with multiple microservices, round trips in requests, security issues like request filtering and role-based access and authorisation, and SSL offloading. This pattern is also called ‘backend to frontend pattern’ as it acts as a reverse-proxy in handling requests from clients to services. It can also be used to cache requests and serve future requests quickly for better response handling.
For large enterprise solutions, multiple API gateway facilities are optimal. For example, one API gateway to handle web consumers (single page applications) and one for mobile consumers to transform requests as HTML or JSON objects. An API gateway can also act as a request aggregator, handling multiple requests by collecting them and transmitting to single client requests. API gateway is available in Azure, AWS and GCP, and facilitates service discovery, IP filtering requests and logging/tracking requests or API service management, among other things.
A platform for microservices assessment
If you want to assess APIs and microservices for architectural flexibility, pattern-based microservices design, and understand their risks, there is an easy to use online assessment platform available at https://microservices.io/platform/microservice-architecture-assessment.html. This was designed by Chris Richardson, the author of the book ‘Microservices Patterns’.
This survey-based qualitative assessment platform collects data about your microservices such as base architecture, development velocity if we have fully utilised the microservice construct in design, development infrastructure, organisational process in handling these services with respect to deployment/outage, and individual service design to understand the design principles and guidelines followed in the architecture.
Figure 3 shows an assessment which is based on a survey of questions about key software delivery outcomes, general architecture, inter-service communication, deployment and reliability, observability, externalised configuration, supporting infrastructure, libraries and frameworks, documentation, and organisation and process. Based on the responses for these questionnaires, the platform prepares a score for an application.
We can also view the impact on the score matrix to understand which section can have a high impact (e.g., general architecture or deployment) and which one can have a low impact (e.g., inter-service communication). Using this, we can decide if we must re-architect a solution for an improved microservices design.
We can double tap on each section to get details on the score to re-validate our response to the survey. This platform is a great tool to understand the agility of our microservices architecture.
Advantages of using microservices architecture
Scalability: Microservices allow individual components of an application to be scaled independently based on demand. This means that if one service experiences high traffic, it can be scaled without affecting the entire system.
Example: Netflix uses microservices to handle millions of users simultaneously, and can scale specific services like video streaming independently to manage varying loads.
Maintainability: Smaller, focused services are easier to understand, develop, and maintain. Changes can be made to one service without impacting others, reducing the risk of introducing bugs.
Example: Amazon employs microservices to manage its vast e-commerce platform, allowing teams to update services like payment processing or inventory management independently.
Deployment: Microservices enable continuous deployment and integration practices. Teams can deploy updates to individual services without needing to redeploy the entire application, leading to faster release cycles.
Example: Spotify uses microservices to deploy new features and updates frequently, allowing them to iterate quickly based on user feedback.
Tech diversity: Different microservices can be built using different technologies and programming languages, allowing teams to choose the best tools for each specific task.
Example: At eBay, various microservices are developed using different technologies, such as Java for backend services and Node.js for real-time applications, optimising performance and development efficiency.
Fault isolation: If one microservice fails, it does not necessarily bring down the entire system. This isolation helps in maintaining overall system stability and reliability.
Example: In a banking application, if the payment processing service fails, other services like account management can continue to function, ensuring that users can still access their accounts
Team autonomy: Microservices allow teams to work independently on different services, fostering a culture of ownership and accountability. This autonomy can lead to increased productivity and innovation.
Example: At Google, teams are organised around microservices, enabling them to make decisions and implement changes without waiting for cross-team coordination.
Performance optimisation: Microservices can be optimised individually for performance, allowing for tailored solutions that meet specific service requirements. This can lead to improved response times and resource utilisation.
Example: LinkedIn uses microservices to optimise their messaging service, allowing them to handle millions of messages with minimal latency.
Overall system resilience: The distributed nature of microservices enhances system resilience. If one service encounters issues, the system can reroute requests or use fallback mechanisms to maintain functionality.
Example: During peak shopping seasons, companies like Walmart utilise microservices to ensure that their systems remain operational even under heavy load, employing strategies like circuit breakers to manage service failures.
Different ways to design microservices architecture
Developing microservices involves several design approaches that focus on creating independently deployable, scalable, and maintainable services. Here are the important ones.
Domain-driven design (DDD): This approach emphasises alignment between the software architecture and business domains. DDD involves identifying distinct domains within the business and developing microservices around them, ensuring that each service corresponds to a specific business context or sub-domain.
Decomposition by business capability: Instead of decomposing services by technical layers (e.g., MVC layers), microservices are decomposed based on business capabilities. Each microservice is responsible for a discrete piece of business functionality and includes everything necessary to execute that functionality.
Database per service: Each microservice owns its database schema or even a full database. This approach avoids database integration issues and ensures that microservices are loosely coupled. However, it introduces challenges related to data consistency and integration across services.
API gateway: A single entry point that handles requests and directs them to the appropriate microservices, the API gateway can handle cross-cutting concerns such as authentication, logging, SSL termination, and rate limiting.
Event-driven architecture: In this model, microservices communicate through asynchronous events. This approach reduces coupling between services, enabling them to evolve independently. It also supports better scalability and responsiveness.
CQRS (command query responsibility segregation): This pattern separates the models for reading and writing data. It allows the system to scale better by optimising the read model for performance and the write model for data integrity and transactional safety.
Service discovery: In a microservices architecture, services need to dynamically discover and communicate with each other. Service discovery tools and mechanisms allow services to query for the network locations of other services.
Configuration management: Externalising configuration and managing it centrally is essential for microservices. This approach helps manage different configurations for development, testing, and production environments, and simplifies the management of environment-specific settings.
Resilience and fault tolerance: Microservices must be designed to be resilient to failures of other services or infrastructure components. Implementing patterns like circuit breaker, bulkhead, and retry can help manage partial failures without affecting the entire system.
Continuous deployment/delivery: Microservices should be designed to be independently deployable via automated deployments. This approach supports frequent updates and improvements to individual microservices without impacting others.
Security: Each microservice can implement its own security, tailored to the specific needs and risks associated with its business functionality. Common practices include using OAuth for distributed security and ensuring sensitive data is encrypted both at rest and in transit.
Monitoring and logging: Due to the distributed nature of microservices, centralised logging and monitoring are crucial. They provide insights into the health of individual services and the system as a whole, aiding in troubleshooting and performance tuning.
These design approaches provide the foundation for developing a robust, scalable, and maintainable microservices architecture, tailored to the specific needs and goals of a project or organisation.
Popular microservices in cloud platforms
Compute microservices: These include AWS Lambda, Google Cloud Functions and Azure Functions, which are serverless compute services that run code in response to events. Another such microservice is Kubernetes, a container orchestration platform that automates the deployment, scaling, and management of containers.
Storage microservices: Amazon S3, Google Cloud Storage, and Azure Blob Storage are object storage services that store and retrieve large amounts of data. Amazon Elastic Block Store (EBS) is a block-level storage service that provides persistent storage for EC2 instances.
Database microservices: Amazon RDS, Google Cloud SQL, and Azure SQL Database are relational database services that provide a managed database instance. Amazon DynamoDB and Google Cloud Firestore are NoSQL database services that provide a fast and flexible database. Azure Cosmos DB is a globally distributed, multi-model database service.
Security microservices: AWS IAM is a security service that provides identity and access management for AWS resources. Google Cloud IAM is a security service that provides identity and access management for Google Cloud resources. Azure Active Directory (AAD) provides identity and access management for Azure resources, and AWS Cognito is a security service that provides user identity and access management for web and mobile applications.
Networking microservices: AWS VPC, Google Cloud Virtual Network, and Azure Virtual Network are virtual networking services that provide a secure and isolated network environment. AWS Route 53 is a domain name system (DNS) service that provides routing and traffic management.
Analytics microservices: Amazon Redshift, Google Cloud BigQuery, Azure Synapse Analytics, and AWS Lake Formation are data warehousing services that provide fast and efficient data analysis.
Machine learning microservices: AWS SageMaker, Google Cloud AI Platform and Azure Machine Learning are machine learning services that provide a platform for building, training, and deploying machine learning models.
IoT microservices: AWS IoT Core, Google Cloud IoT Core, and Azure IoT Hub are IoT services that provide a platform for connecting, monitoring, and managing IoT devices.
These are just a few examples of the many microservices available in cloud platforms. Each microservice provides a specific functionality that can be used to build, deploy, and manage applications in the cloud.
